Re: libtool optimization
Bob Friesenhahn <[EMAIL PROTECTED]> - Tue, 21 Oct 2008 18:32:23 -0500 (CDT) >On Wed, 22 Oct 2008, Michel Briand wrote: >> >> Honestly I wanted to do two optimizations. >> >> Firstly, I've tested /bin/dash and seen that it's much faster >> than /bin/bash on my normal sized project. >> ->> is it possible to choose the shell in autogen ? That way users do >> not have to bother to call configure like this ? > >If you did that then the configure script would likely only work on >your system. If it only runs on your system, what's the point? > You don't see my point. In autogen I want to have a way to select a different shell (for configure & libtool). I'm not saying that I'll choose a shell that fails to run the tools or that I'll not ask the user for the best shell available... Furthermore you seems to indicate that Dash would not run configure ? Should autoconf find the correct sed program for example (@SED@), it could also find the best shell available, isn't it ? >> Secondly, I wanted to optimize the way gcc is called ? Why does libtool >> need to create a shell snippet for all source files ? A Makefile that >> simply calls gcc for each source file is much much faster ; > >Libtool is for portably creating libraries. If you only plan to >create libraries that work on your own computer, then you can >hard-code everything in a Makefile and skip using libtool. > Sure. No comment. >Regardless, libtool 2.2 and latter has been shown to have minimal >impact on build times. > Noted. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool optimization
Hello, * Michel Briand wrote on Wed, Oct 22, 2008 at 10:20:14AM CEST: > > You don't see my point. In autogen I want to have a way to select a > different shell (for configure & libtool). That is not possible with current Autoconf and Libtool. Sorry. You can only choose that at configure run time, not at autoconf run time. But that makes sense: configure run time is the earliest time when the system in question is nailed down. And it is system- dependent which shell is appropriate to use. (As we cannot know whether your 'autogen' script runs configure or not, we cannot know whether that is a problem for you or not.) > I'm not saying that I'll > choose a shell that fails to run the tools or that I'll not ask the > user for the best shell available... > Furthermore you seems to indicate that Dash would not run configure ? There should be no problem with dash. > Should autoconf find the correct sed program for example (@SED@), it > could also find the best shell available, isn't it ? But it does. Not autoconf; but configure does try to find a decent shell unless you set CONFIG_SHELL when invoking configure. > >Regardless, libtool 2.2 and latter has been shown to have minimal > >impact on build times. > > Noted. IIUC then that means you haven't tried it yet, right? Please try 2.2.6 before complaining further about its execution time; we do not have the resources to support non-fatal bugs in old versions of Libtool; and slower execution time is a non-fatal bug. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool optimization
On Wed, 22 Oct 2008, Michel Briand wrote: You don't see my point. In autogen I want to have a way to select a different shell (for configure & libtool). I'm not saying that I'll choose a shell that fails to run the tools or that I'll not ask the user for the best shell available... As Ralph detailed earlier, it is possible for the end user to specify the shell to use. It is actually pretty challenging to know which shell on a system works since they are often riddled with bugs or obscure behavior. Sometimes it seems like things works but wrong results are discovered later. Even though versions of bash also have bugs, it is easier to understand the bugs in one implementation so autoconf currently checks for bash first and then sticks with it if it is available. The shell selection functionality is part of Autoconf and some of the world's most experienced developers have been involved in designing the selection logic. Furthermore you seems to indicate that Dash would not run configure ? In my testing, dash is a real speed daemon and does usually work to perform normal package configuration. However, I learned the hard way that wrong things could happen if dash was used by the maintainer of a package. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
Hi Vincent, * Vincent Torri wrote on Wed, Oct 22, 2008 at 08:18:28AM CEST: > > Now I have a problem with libm.a. The ptch you provided is good for all > the static lib i currently used, but recently i had to use libm.a (more > precisely, it's libtool which adds -lm when c++ code is used). > * arm-mingw32ce-nm -f posix -A ~/local/opt/mingw32ce/arm-mingw32ce/lib/libm.a > > /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libm.a[_libm_dummy.o]: .bss > b > /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libm.a[_libm_dummy.o]: > .data d > /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libm.a[_libm_dummy.o]: > .debug_abbrev N > /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libm.a[_libm_dummy.o]: > .debug_info N > /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libm.a[_libm_dummy.o]: > .debug_line N > /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libm.a[_libm_dummy.o]: > .text t Since this is a dummy library only, the prudent thing for libtool to do would be just to drop instances of -lm. This is already done for some other hosts. I hope to address all the pending Libtool issues soonish. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
