Re: FYI: duplicate removal patch [Was Re: ok, new libtool for cygwin updates]

[Michael Matz]

Hi,

On Sun, 1 Apr 2001, Gary V. Vaughan wrote:
> >
> > I see.  Argh, This then again means, that libtool will probably generate
> > excessively large link commands for KDE.
>
> Yes it does =(O|  Although ugly, Robert has applied the following to MLB so
> that portability at least is not affected in that case:

I know about the incremental linking (but I'm not sure it also applies to
libraries, or only to .o files. Given how it works (using ld -r IIRC) it
normally only _can_ work with .o's, because _all_ libs have to be
mentioned in one link command, to have any effect).

But apart from sheer ugliness in link commands I think about another
problem I first saw on HP-UX.  When a shared lib is mentioned mutiple
times on the link command it somehow also ends up multple times in the
executable, and when this is run, it tries to load/relocate the same lib
again and again (at least an ldd equivalent makes me think so).

> > We sometimes list also dependent libs in the makefiles (history and
>
> Removing the deplib listings from Makefile.am would probably make a huge
> difference to the length of the link lines where deep dependency trees are
> being used...

Yep. I'll see to remove the duplicated stuff from our Makefile.am's. (But
those are many ;-) )

> > Furthermore it really makes no sense to _not_ remove
> > duplicates for shared libs (it only applies to archives), because anyway
> > only the first one is searched for undefined symbols.
>
> Certainly for modern UNIX architectures, however, I get the impression from
> Alexandre that there are platforms which do require topologically ordered
> listings of shared libraries in the final link line in order to be able to

Hmm, Alexandre?  Are there really platforms where this is the case for
shared libs?


Ciao,
Michael.