Hi Tor, * Tor Lillqvist wrote on Tue, Mar 15, 2005 at 10:32:41AM CET: > Ralf Wildenhues writes: > > Linking is a problem, though: shell wrappers break, > > I have never liked (or understood...) libtool's shell wrappers or its > relinking on Win32. I always use --disable-static, I always run a > "make install", and make sure the bin directory of the installation > location is in my PATH, before any "make check". And I always comment > out the "need_relink=yes" in any ltmain.sh that I come across ;-) This > means shell wrappers won't be produced. Or am I completely confused?
Well, the feeling towards shell wrappers and their need in general are different matters. :) It might be the case that libtool actually creates wrappers in situations where they are not strictly necessary. This has been reported before, and I would be happy to take patches which improve on the situation while not compromising functionality and portability. But in general, if you link against uninstalled libraries, you will have to relink upon `make install'. In general, you then also have to have add some linker hackery upon execution of the uninstalled binary, so that it will actually pick up the uninstalled libraries versus older installed versions. If that is not the case on some architectures, we could optimize here. Honestly, I don't know off the head whether Cygwin falls into that category (I think win uses PATH for searching libraries). > > How much is the actual speedup in numbers? > > Very significant. I don't have my old machine (450 MHz PIII running > Win2k) around any longer, but libtool-cache made it feel like a > totally new machine. A rough guess would five times faster builds of > stuff like GLib or GTK. Now it would _really_ be interesting to see how much speedup is left with Libtool HEAD using ash, vs. libtool-cache with Libtool HEAD using ash. And if there are bottlenecks left that can /easily/ be improved. Regards, Ralf _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
