Re: [Mingw-msys] Re: MinGW libtool DLL failure
On Fri, 18 Oct 2002, Albert Chin wrote: > On Tue, Oct 15, 2002 at 10:43:08AM -0500, Bob Friesenhahn wrote: > > 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. > > Doesn't this conflict with the libtool option -no-undefined: > - Macro: AC_LIBTOOL_WIN32_DLL > This macro should be used if the package has been ported to build > clean dlls on win32 platforms. Usually this means that any Due to `auto-import' enhancements in the version of binutils used by Cygwin and MinGW, I believe that using this macro is no longer necessary. Packages which have been enhanced (or compromised, depending on point of view) by being decorated with dllexport/dllimport annotations may still benefit from use of the macro. Unix-derived packages which do not use AC_LIBTOOL_WIN32_DLL and do not incorporate dllexport/dllimport annotations are capable of building DLLs by incorporating recent libtool. > It seems that CYGWIN needs -no-undefined but this might be problematic > on other unices. It is true that Cygwin/MinGW need -no-undefined in order to build DLLs. I have not encountered a problem with specifying -no-undefined under various unixes. Indeed, I believe that this issue isn't Windows specific because IBM's AIX also requires -no-undefined. In order to ensure that the maximum number of packages will compile under Windows, the auto* tools should automatically incorporate any tests/features required for packages to build under Windows without their authors taking specific action to make this possible. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
On Tue, Oct 15, 2002 at 10:43:08AM -0500, Bob Friesenhahn wrote: > 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. Doesn't this conflict with the libtool option -no-undefined: - Macro: AC_LIBTOOL_WIN32_DLL This macro should be used if the package has been ported to build clean dlls on win32 platforms. Usually this means that any library data items are exported with `__declspec(dllexport)' and imported with `__declspec(dllimport)'. If this macro is not used, libtool will assume that the package libraries are not dll clean and will build only static libraries on win32 hosts. This macro must be called *before* `AC_PROG_LIBTOOL', and provision must be made to pass `-no-undefined' to `libtool' in link mode from the package `Makefile'. Naturally, if you pass `-no-undefined', you must ensure that all the library symbols *really are* defined at link time! It seems that CYGWIN needs -no-undefined but this might be problematic on other unices. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
Bob Friesenhahn wrote: > > 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. > Do you have examples of libtool use without autoconf and/or automake? Why does libtool.m4 get installed into share/aclocal/? AFAIK, libtool without autoconf/automake doesn't exist. Earnie. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
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. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
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 [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
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. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
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 [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
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. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
Bob Friesenhahn wrote: > On Tue, 15 Oct 2002, Max Bowsher wrote: >> >> 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. :-) Of course not. > 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. Sorry, how is this different from the current situation? This is just another Win32 oddness that needs to be worked around. > 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. I could be wrong, but I think my solution would work just fine with autoconf+libtool (without automake). Does anyone use libtool without autoconf? Even if they do, then libtool can just fall back to ../bin (or even put the DLLs alongside the implibs). Max. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
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 ! ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
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 [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
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. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
Guido Draheim wrote:
>> 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.
>>
>
> yes.
>
> Just reiterating the link to the macro that I add regularly to
> configure.ac
> http://ac-archive.sourceforge.net/guidod/ac_set_default_paths_system.html
>
> The main trick is to modify only the default-path (!!) of the
> libdirpath and therefore let the user be free to override it on the
> commandline. When a user has overridden the bindirpath then "../bin"
> might simply be the wrong choice as it would not end up near the
> binary nor in the $PATH.
>
> libdir=`echo $libdir |sed -e 's:^..exec_prefix./lib$:${bindir}:'`
>
> perhaps add a similar thing to the libtool m4 macro, no?
I don't think this is the same issue at all. The problem is that libtool
needs to install _2_ files, and is (at the moment) only given the
destination of one of them.
Max.
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
>
> 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.
>
yes.
Just reiterating the link to the macro that I add regularly to configure.ac
http://ac-archive.sourceforge.net/guidod/ac_set_default_paths_system.html
The main trick is to modify only the default-path (!!) of the libdirpath
and therefore let the user be free to override it on the commandline. When
a user has overridden the bindirpath then "../bin" might simply be the wrong
choice as it would not end up near the binary nor in the $PATH.
libdir=`echo $libdir |sed -e 's:^..exec_prefix./lib$:${bindir}:'`
perhaps add a similar thing to the libtool m4 macro, no?
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
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. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
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. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
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 [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
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. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
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 [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
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 > [EMAIL PROTECTED] > 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 > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/mingw-msys > ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
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 [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
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 [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
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 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
Tor Lillqvist <[EMAIL PROTECTED]> 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. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
Earnie Boyd writes: > I've seen some looong 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 2 (for instance) helped. This was on Win2k. If I remember correctly, CVS HEAD libtool earlier used to arrive at a pretty high limit, over 2, but then at some point started to use the lower limit. --tml ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
Elizabeth, Here is another MinGW-related problem to fix. I do not know if this is specific to C++ DLLs, or if it happens for all cases where the library depends on an uninstalled libtool library. I suspect the latter since I recall also seeing the problem when building libwmf. Note that in this case libMagick++.la depends on libMagick.la. /bin/sh /scooby/src/graphics/ImageMagick/mkinstalldirs /usr/local/lib /bin/sh ../../libtool --mode=install /bin/install -c libMagick++.la /usr/local/lib/libMagick++.la libtool: install: warning: relinking `libMagick++.la' (cd /c/home/bfriesen/mingw/ImageMagick-16-shared/Magick++/lib; /bin/sh ../../libtool --mode=relink g++ -O0 -march=i686 -L/usr/local/lib -L/usr/local/lib -o libMagick++.la -rpath /usr/local/lib -release 5.5.1 Blob.lo BlobRef.lo CoderInfo.lo Color.lo Drawable.lo Exception.lo Functions.lo Geometry.lo Image.lo ImageRef.lo Montage.lo Options.lo Pixels.lo STL.lo Thread.lo TypeMetric.lo ../../magick/libMagick.la) g++ -shared .libs/Blob.o .libs/BlobRef.o .libs/CoderInfo.o .libs/Color.o .libs/Drawable.o .libs/Exception.o .libs/Functions.o .libs/Geometry.o .libs/Image.o .libs/ImageRef.o .libs/Montage.o .libs/Options.o .libs/Pixels.o .libs/STL.o .libs/Thread.o .libs/TypeMetric.o -L/usr/local/lib -lMagick -Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6 -Lc:/mingw/bin/../lib/gcc-lib -L/mingw/lib/gcc-lib/mingw32/2.95.3-6 -Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../mingw32/lib -L/mingw/lib/gcc-lib/mingw32/2.95.3-6/../../../../mingw32/lib -Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../.. -L/mingw/lib/gcc-lib/mingw32/2.95.3-6/../../.. -lstdc++ -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmsvcrt -o .libs/libMagick++-5-5-1.dll -Wl,--out-implib,.libs/libMagick++-5-5-1.dll.a c:\mingw\bin\..\lib\gcc-lib\mingw32\2.95.3-6\..\..\..\..\mingw32\bin\ld.exe: cannot find -lMagick libtool: install: error: relink `libMagick++.la' with the above command before installing it Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
Earnie Boyd <[EMAIL PROTECTED]> writes: > I've seen some looong 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 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
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 [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
Elizabeth Barham wrote: Earnie Boyd <[EMAIL PROTECTED]> 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 looong 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. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
Earnie Boyd <[EMAIL PROTECTED]> 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 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
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. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
