From: Elizabeth B. <sog...@ya...> - 2002-10-12 00:11:57
|
"Max Bowsher" <ma...@uk...> writes: > Don't worry about me! I think we are working towards broadly similar goals - > it shouldn't be much effort for me to merge the changes you are making into > my stuff. What I'm wondering is of there is a better variable to use with the import library, as opposed to ${lib}.a ? > > + mingw*) > > + # On msys 1.0 and win98, the maximum length was something like > > + # 200,000 and took around 45 minutes to get there... ouch! > > + lt_cv_sys_max_cmd_len=32768; > > + ;; > > One of my patches merges a change from Cygwin for this. Caution though. I > read there that the max length for NT systems is only 8192 - so this patch > needs adjusting to not break libtool on NT. I'd very much like to add this or something similar (8192) to the distribution because, on my machine at least, it took about 45 minutes. What is the MSYS-team's view on this? Thanks Max, Elizabeth |
From: Earnie B. <ear...@ya...> - 2002-10-13 01:39:37
|
Elizabeth Barham wrote: > Earnie Boyd <ear...@ya...> writes: > > >>I'm fine with it and will support the change [of the maximum command >>line length] to a constant. Should that constant be adjusted based >>on w9x vs NT? > > > I would not think so; rather, it seems to me that a 8192 character > command line maximum will work for most anyone. > I've seen some looooooong command lines, not that I've stopped to count the characters. The 8192 may not be enough for some packages. Is there a mehtod to use that doesn't check the command line length or is the point of the limit to break the command line into parts? > Do we have the option of switching between NT and w9x? > With Cygwin and MSYS, unmae tacks it on the system name. Earnie. |
From: Bob F. <bfr...@si...> - 2002-10-13 01:44:38
|
On Sat, 12 Oct 2002, Earnie Boyd wrote: > the characters. The 8192 may not be enough for some packages. Is there > a mehtod to use that doesn't check the command line length or is the > point of the limit to break the command line into parts? I believe that the limit is there to break the command line into parts. For the sake of efficiency, choose the largest length that works. Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
From: Elizabeth B. <sog...@ya...> - 2002-10-13 01:54:32
|
Earnie Boyd <ear...@ya...> writes: > I've seen some looooooong command lines, not that I've stopped to > count the characters. The 8192 may not be enough for some packages. > Is there a mehtod to use that doesn't check the command line length > or is the point of the limit to break the command line into parts? I do not know why it is used. It sets the variable `max_cmd_len' is all I can tell that it does in libtool.m4. > with Cygwin and MSYS, unmae tacks it on the system name. Ok. Elizabeth |
From: Tor L. <tm...@ik...> - 2002-10-13 14:41:51
|
Earnie Boyd writes: > I've seen some looooooong command lines, not that I've stopped to count > the characters. The 8192 may not be enough for some packages. I have experienced that the 8192 (umm, don't remember exactly, some pretty low limit anyhow) wasn't enough for GTK+, and libtool started to use some workaround, which then failed in a mysterious way. Manually changing the limit to 20000 (for instance) helped. This was on Win2k. If I remember correctly, CVS HEAD libtool earlier used to arrive at a pretty high limit, over 20000, but then at some point started to use the lower limit. --tml |
From: Kevin R. <us...@zi...> - 2002-10-14 00:32:24
|
Tor Lillqvist <tm...@ik...> writes: > > I have experienced that the 8192 (umm, don't remember exactly, some > pretty low limit anyhow) wasn't enough for GTK+, and libtool started > to use some workaround, which then failed in a mysterious > way. In GMP we had a problem with the "ar cru" used for piecewise linking since we've got multiple object files of the same name (coming from different directories). Using AR_FLAGS=cq got around it. |
From: Robert B. <rb...@gn...> - 2002-10-14 15:01:36
|
All, The max_cmd_len variable is used to determine how long a command can be executed. When Libtool generates a link command that is longer than this, it breaks the command into successive "ld -r" invocations that are just short enough to be executed. There are other parts of the commands that aren't included when testing, so the max_cmd_len variable can't be set to the actual limit, but must be smaller. Also, finding the actual limit would take much longer so we set max_cmd_len to something safe. It is true that the checking takes some time, ~three seconds on a newer Sun workstation (with large limit), but it isn't clear to me why it would take even longer under MinGW. It is reasonable to set this to a hard limit if the test takes a very long time, but the value to use is the same one that Libtool's configury will calculate. The problem with GTK+ is that they archive two (or more) object files with the same name, so successive ar commands replace the previous one with the new one. If a package needs the command line broken up, setting this value to the maximum possible will speed up compilation drastically, IMHO an important issue. my $0.02 Robert -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: rboehne AT ricardo-us DOT com |
From: Bob F. <bfr...@si...> - 2002-10-14 15:44:23
|
On Mon, 14 Oct 2002, Robert Boehne wrote: > It is true that the checking takes some time, ~three seconds on > a newer Sun workstation (with large limit), but it isn't clear > to me why it would take even longer under MinGW. Unfortunately MinGW must run under an inferior OS, particularly Windows '98 which has terrible performance with executing subprocesses. Libtool estimates a command line length of 8192 under Windows XP. Is there a version of Windows under which libtool estimates a smaller lt_cv_sys_max_cmd_len? Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
From: Earnie B. <ear...@ya...> - 2002-10-12 02:17:58
|
Elizabeth Barham wrote: > > What is the MSYS-team's view on this? > I'm fine with it and will support the change to a constant. Should that constant be adjusted based on w9x vs NT? Earnie. |
From: Elizabeth B. <sog...@ya...> - 2002-10-13 00:31:45
|
Earnie Boyd <ear...@ya...> writes: > I'm fine with it and will support the change [of the maximum command > line length] to a constant. Should that constant be adjusted based > on w9x vs NT? I would not think so; rather, it seems to me that a 8192 character command line maximum will work for most anyone. Do we have the option of switching between NT and w9x? Elizabeth |
From: Bob F. <bfr...@si...> - 2002-10-14 21:08:42
|
What directory should MinGW DLLs be installed in? Cygwin installs using the offset ../bin from the directory where the .dll.a file is installed. Should libtool behave the same way under MinGW? This seems to make sense as long as "Unixish" behavior is what is expected by MinGW users. However, the intended purpose of MinGW is somewhat different than Cygwin. Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
From: Earnie B. <ear...@ya...> - 2002-10-14 21:29:35
|
Well, shouldn't both use $(bindir) to install the dll into? Earnie. Bob Friesenhahn wrote: > What directory should MinGW DLLs be installed in? Cygwin installs > using the offset ../bin from the directory where the .dll.a file is > installed. Should libtool behave the same way under MinGW? > > This seems to make sense as long as "Unixish" behavior is what is > expected by MinGW users. However, the intended purpose of MinGW is > somewhat different than Cygwin. > > Bob > ====================================== > Bob Friesenhahn > bfr...@si... > http://www.simplesystems.org/users/bfriesen > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Mingw-msys mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-msys > |
From: Bob F. <bfr...@si...> - 2002-10-14 21:35:54
|
On Mon, 14 Oct 2002, Earnie Boyd wrote: > Well, shouldn't both use $(bindir) to install the dll into? What would be nice except that I don't believe libtool is provided with this information at run-time. It acts like a traditional install program. The Cygwin folks are using the ../bin trick to get around that. Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
From: Max B. <ma...@uk...> - 2002-10-14 22:30:10
|
Bob Friesenhahn wrote: > On Mon, 14 Oct 2002, Earnie Boyd wrote: > >> Well, shouldn't both use $(bindir) to install the dll into? > > What would be nice except that I don't believe libtool is provided > with this information at run-time. It acts like a traditional install > program. The Cygwin folks are using the ../bin trick to get around > that. I floated an idea on how to get around that: Adjust the libtool invocation command (as determined in libtool.m4) to be "libtool --bindir=$(bindir)" (or perhaps with appropriate quoting). The idea being that when used from an autoconf-based makefile (is it even possible to do otherwise, now there is no ltconfig?), the make variable bindir is passed on to libtool. Kludgy, yes, but better than ../bin. Of course, libtool would need to detect an invalid bindir and fall back on ../bin. I haven't fully worked this through yet, though, as I've just started university, so am a bit busy, and to top it off, my hard drive is making loud clicking noises and bluescreening my laptop from time to time. Max. |
From: Bob F. <bfr...@si...> - 2002-10-14 22:49:47
|
On Mon, 14 Oct 2002, Max Bowsher wrote: > I floated an idea on how to get around that: Adjust the libtool invocation > command (as determined in libtool.m4) to be "libtool --bindir=$(bindir)" (or > perhaps with appropriate quoting). The idea being that when used from an > autoconf-based makefile (is it even possible to do otherwise, now there is > no ltconfig?), the make variable bindir is passed on to libtool. Kludgy, > yes, but better than ../bin. Of course, libtool would need to detect an > invalid bindir and fall back on ../bin. I haven't fully worked this through > yet, though, as I've just started university, so am a bit busy, and to top > it off, my hard drive is making loud clicking noises and bluescreening my > laptop from time to time. Be very careful about your assumptions! Libtool is certainly usable all by itself and may be used to install packages into a different directory from the one it is installed in. Libtool only needs autoconf in order to be installed, and is delivered from the FSF as a configurable stand-alone package. In a perfect world, every system would come with a perfectly working libtool, and packages wouldn't need to worry about including it, or configuring it. The idea of supporting a --bindir option is tempting, but then 'libtool --mode=install' stops looking like a simple install program, and in fact, the --bindir option would need to be passed for several different phases of libtool operation since it would influence the content of the library.la file. Since Windows may be the only OS benefiting from this, we could have a case of the tail wagging the dog. Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
From: Earnie B. <ear...@ya...> - 2002-10-15 11:02:11
|
Bob Friesenhahn wrote: > On Mon, 14 Oct 2002, Max Bowsher wrote: > >>I floated an idea on how to get around that: Adjust the libtool invocation >>command (as determined in libtool.m4) to be "libtool --bindir=$(bindir)" (or >>perhaps with appropriate quoting). The idea being that when used from an >>autoconf-based makefile (is it even possible to do otherwise, now there is >>no ltconfig?), the make variable bindir is passed on to libtool. Kludgy, >>yes, but better than ../bin. Of course, libtool would need to detect an >>invalid bindir and fall back on ../bin. I haven't fully worked this through >>yet, though, as I've just started university, so am a bit busy, and to top >>it off, my hard drive is making loud clicking noises and bluescreening my >>laptop from time to time. > > > Be very careful about your assumptions! Libtool is certainly usable > all by itself and may be used to install packages into a different > directory from the one it is installed in. Libtool only needs > autoconf in order to be installed, and is delivered from the FSF as a > configurable stand-alone package. In a perfect world, every system > would come with a perfectly working libtool, and packages wouldn't > need to worry about including it, or configuring it. > So what! The FSF standard is to use $(bindir) for binary installation. It even states this in the make documentation. > The idea of supporting a --bindir option is tempting, but then > 'libtool --mode=install' stops looking like a simple install program, > and in fact, the --bindir option would need to be passed for several > different phases of libtool operation since it would influence the > content of the library.la file. Since Windows may be the only OS > benefiting from this, we could have a case of the tail wagging the > dog. > Would bindir be an environment variable if libtool is being executed from make? If not, setting a variable in the libtool.m4 that configure sets works. I prefer that over a switch, with a default value for the variable of ../bin. If bindir is passed to libtool through the environment then use ../bin if bindir isn't present. Earnie. |
From: Max B. <ma...@uk...> - 2002-10-15 11:12:07
|
Earnie Boyd wrote: > Bob Friesenhahn wrote: >> On Mon, 14 Oct 2002, Max Bowsher wrote: >> >>> I floated an idea on how to get around that: Adjust the libtool >>> invocation command (as determined in libtool.m4) to be "libtool >>> --bindir=$(bindir)" (or perhaps with appropriate quoting). The idea >>> being that when used from an autoconf-based makefile (is it even >>> possible to do otherwise, now there is no ltconfig?), the make >>> variable bindir is passed on to libtool. Kludgy, yes, but better >>> than ../bin. Of course, libtool would need to detect an invalid >>> bindir and fall back on ../bin. I haven't fully worked this through >>> yet, though, as I've just started university, so am a bit busy, and >>> to top it off, my hard drive is making loud clicking noises and >>> bluescreening my laptop from time to time. >> >> >> Be very careful about your assumptions! Libtool is certainly usable >> all by itself and may be used to install packages into a different >> directory from the one it is installed in. Libtool only needs >> autoconf in order to be installed, and is delivered from the FSF as a >> configurable stand-alone package. In a perfect world, every system >> would come with a perfectly working libtool, and packages wouldn't >> need to worry about including it, or configuring it. >> > > So what! The FSF standard is to use $(bindir) for binary > installation. It even states this in the make documentation. So we use bindir, and arrange to fall back to "../bin" >> The idea of supporting a --bindir option is tempting, but then >> 'libtool --mode=install' stops looking like a simple install program, >> and in fact, the --bindir option would need to be passed for several >> different phases of libtool operation since it would influence the >> content of the library.la file. Since Windows may be the only OS >> benefiting from this, we could have a case of the tail wagging the >> dog. So we conditionalize all this so it only activates on Windows. > Would bindir be an environment variable if libtool is being executed > from make? Unfortunately not. > If not, setting a variable in the libtool.m4 that > configure sets works. Unfortunately not - "make install bindir=/alternatelocation". > I prefer that over a switch, with a default > value for the variable of ../bin. I think that a switch is the only way, if we are to deal with the case I cite above. Max. |
From: Earnie B. <ear...@ya...> - 2002-10-15 12:30:52
|
Max Bowsher wrote: > Earnie Boyd wrote: > > > Unfortunately not - "make install bindir=/alternatelocation". > > >> I prefer that over a switch, with a default >>value for the variable of ../bin. > > > I think that a switch is the only way, if we are to deal with the case I > cite above. > The Makefile sets LIBTOOL := bindir=$(bindir) $(SHELL) $(top_builddir)/libtool Then: Test for the existance of bindir in the libtool script, if it doesn't exist set it to ../bin if it does exist the Makefile has passed it to libtool via an environment variable. This works for `make install bindir=/alternatelocation". Earnie. |
From: Guido D. <gui...@gm...> - 2002-10-15 16:59:29
|
Earnie Boyd wrote: > Max Bowsher wrote: > >> Earnie Boyd wrote: >> >> >> Unfortunately not - "make install bindir=/alternatelocation". >> >> >>> I prefer that over a switch, with a default >>> value for the variable of ../bin. >> >> >> >> I think that a switch is the only way, if we are to deal with the case I >> cite above. >> > > The Makefile sets > LIBTOOL := bindir=$(bindir) $(SHELL) $(top_builddir)/libtool > > Then: > Test for the existance of bindir in the libtool script, if it doesn't > exist set it to ../bin if it does exist the Makefile has passed it to > libtool via an environment variable. > > This works for `make install bindir=/alternatelocation". > Don't forget DESTDIR ! |
From: Max B. <ma...@uk...> - 2002-10-15 18:20:27
|
Earnie Boyd wrote: > The Makefile sets > LIBTOOL := bindir=$(bindir) $(SHELL) $(top_builddir)/libtool > > Then: > Test for the existance of bindir in the libtool script, if it doesn't > exist set it to ../bin if it does exist the Makefile has passed it to > libtool via an environment variable. > > This works for `make install bindir=/alternatelocation". Good point. Less impact on ltmain.sh options parsing code as well. Max. |
From: Bob F. <bfr...@si...> - 2002-10-15 18:27:16
|
On Tue, 15 Oct 2002, Max Bowsher wrote: > Earnie Boyd wrote: > > The Makefile sets > > LIBTOOL := bindir=$(bindir) $(SHELL) $(top_builddir)/libtool > > > > Then: > > Test for the existance of bindir in the libtool script, if it doesn't > > exist set it to ../bin if it does exist the Makefile has passed it to > > libtool via an environment variable. > > > > This works for `make install bindir=/alternatelocation". > > Good point. Less impact on ltmain.sh options parsing code as well. Would this part from Automake-generated Makefiles have any impact on the proposal? # Tell versions [3.59,3.63) of GNU make to not export all variables. # Otherwise a system limit (for SysV at least) may be exceeded. .NOEXPORT: ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
From: Max B. <ma...@uk...> - 2002-10-15 18:34:54
|
Bob Friesenhahn wrote: > On Tue, 15 Oct 2002, Max Bowsher wrote: > >> Earnie Boyd wrote: >>> The Makefile sets >>> LIBTOOL := bindir=$(bindir) $(SHELL) $(top_builddir)/libtool >>> >>> Then: >>> Test for the existance of bindir in the libtool script, if it >>> doesn't exist set it to ../bin if it does exist the Makefile has >>> passed it to libtool via an environment variable. >>> >>> This works for `make install bindir=/alternatelocation". >> >> Good point. Less impact on ltmain.sh options parsing code as well. > > Would this part from Automake-generated Makefiles have any impact on > the proposal? > > # Tell versions [3.59,3.63) of GNU make to not export all variables. > # Otherwise a system limit (for SysV at least) may be exceeded. > .NOEXPORT: It won't hinder it, if that it the question. Max. |
From: Bob F. <bfr...@si...> - 2002-10-15 18:40:26
|
On Tue, 15 Oct 2002, Bob Friesenhahn wrote: > > Would this part from Automake-generated Makefiles have any impact on > the proposal? > > # Tell versions [3.59,3.63) of GNU make to not export all variables. > # Otherwise a system limit (for SysV at least) may be exceeded. > .NOEXPORT: Here is some text from the GNU make manual. "Except by explicit request, make exports a variable only if it is either defined in the environment initially or set on the command line, and if its name consists only of letters, numbers, and underscores. Some shells cannot cope with environment variable names consisting of characters other than letters, numbers, and underscores. The special variables SHELL and MAKEFLAGS are always exported (unless you unexport them). MAKEFILES is exported if you set it to anything. make automatically passes down variable values that were defined on the command line, by putting them in the MAKEFLAGS variable." I don't see evidence that srcdir will normally be available in libtool's environment. Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
From: Max B. <ma...@uk...> - 2002-10-15 19:35:04
|
Bob Friesenhahn wrote: > On Tue, 15 Oct 2002, Bob Friesenhahn wrote: >> >> Would this part from Automake-generated Makefiles have any impact on >> the proposal? >> >> # Tell versions [3.59,3.63) of GNU make to not export all variables. >> # Otherwise a system limit (for SysV at least) may be exceeded. >> .NOEXPORT: > > Here is some text from the GNU make manual. > > "Except by explicit request, make exports a variable only if it is > either defined in the environment initially or set on the > command line, and if its name consists only of letters, numbers, and > underscores. Some shells cannot cope with > environment variable names consisting of characters other than > letters, numbers, and underscores. > > The special variables SHELL and MAKEFLAGS are always exported (unless > you unexport them). MAKEFILES is exported if you set > it to anything. > > make automatically passes down variable values that were defined on > the command line, by putting them in the MAKEFLAGS > variable." > > I don't see evidence that srcdir will normally be available in > libtool's environment. I assume you mean bindir, not srcdir? In which case, my answer is: Yes, thats why special attention of required to _make_ it available. Max. |
From: Bob F. <bfr...@si...> - 2002-10-15 15:43:31
|
On Tue, 15 Oct 2002, Max Bowsher wrote: > > >> The idea of supporting a --bindir option is tempting, but then > >> 'libtool --mode=install' stops looking like a simple install program, > >> and in fact, the --bindir option would need to be passed for several > >> different phases of libtool operation since it would influence the > >> content of the library.la file. Since Windows may be the only OS > >> benefiting from this, we could have a case of the tail wagging the > >> dog. > > So we conditionalize all this so it only activates on Windows. There is a fundamental flaw with this logic. Sorry to dissapoint you, but most open source software using libtool does not originate from the Windows environment. :-) If you rely on a feature which only takes effect under Windows, then packages will neglect to enable or test that feature, resulting in packages which do not build properly (or misbehave) under Windows. You can make the assumption that all libtool users will use it from packages using Autoconf and Automake so you can rely on a libtool command line passed via those tools, but this is not necessarily the case. I am aware of a number of significant packages which use libtool but don't use Automake at all. If libtool was intended to be an extension of Autoconf/Automake, then it should certainly have been absorbed into Automake, and not exist as a stand-alone utility at all. Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |