Re: Speeding up libtool

[Ralf Wildenhues]

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