RE: Link performance: some numbers and a hack

[Bob Friesenhahn]

On Fri, 19 Sep 2003, Iñaki García Etxebarria wrote:

> > Static libs on every platform need to have this dependency info.
> Oops, I didn't consider that. Sure.
>
> In any case, I'm not talking about removing this info but simply
> ignoring it when linking dynamic libs (which I guess is the situation
> 95% of the time on platforms with dynamic libs).

The information in the dynamic libs may be incorrect, or it may not
actually exist.

> The algorithm should be something like (in linux):
> - include_dynamic(libfoo):
>       read libfooname.so from libfoo.la and pass to gcc [but ignore
>       dependency_libs]
> - include_static(libfoo):
>       as currently done in libtool since we need the deps.
> Does this make any sense? One potential problem I can see is the case
> when libfoo.so has been linked against a static lib itself, will this
> break things?
>
> When the time to generate the .la file comes, libtool would include the
> dependencies just as it does now.
>
> Comments?,

It would be good to see why linking is so slow when all the libraries
are listed.  Is the same library listed multiple times due to
dependency concatenation?  Is the library listing order poor, forcing
the linker to accumulate many symbols, or to re-scan the library list
for a symbol?  It may be that adding a good library dependency
optimizer to libtool plus fixing dependency lists in the various
libraries so that they are in optimum/correct order is the most
portable solution to improve link times.  Unfortunately, usability
improvements to the linker often hide inefficiencies which should be
avoided.  Try compiling your package on an archaic version of Linux
and you will see what I mean.

I don't see long link times for my libtool-based package even though
it depends on 36 libraries.  However, the libraries have been
carefully listed in the optimum order.

Bob
======================================
Bob Friesenhahn
address@hidden
http://www.simplesystems.org/users/bfriesen