libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gary V . Vaughan
Subject: Re: FYI: duplicate removal patch [Was Re: ok, new libtool for cygwin updates]
Date: Sun, 1 Apr 2001 14:55:38 +0100

Hello.

On Sunday 01 April 2001  1:16 pm, Michael Matz wrote:
> On Sun, 1 Apr 2001, Gary V. Vaughan wrote:
> > > > I have applied the following to HEAD (and similar to MLB).
> > >
> > > Why also MLB?  Was it really broken there too?  I ask, because I
> > > _definitely_ got multiple libraries in link commands.
> >
> > Try out the new depdemo-dups.test on an old libtool script, and you'll
> > see what I mean.  Perhaps I have found and fixed a similar but different
> > bug?
>
> 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:

        * ltconfig.in: Add a test to find the approximate limit
        to the length of command line arguments.  The number
        calculated here should always be lower than the actual
        limit.
        * ltmain.in: Test the length of the command line to be
        executed and use an incremtnal linking scheme if the
        command is too long to be interpreted without error.
        * doc: Test the length of the command line to be
        executed and use an incremtnal linking scheme if the
        command is too long to be interpreted without error.
        * doc/libtool.texi (Reloadable Objects): Added a few
        sentences to describe how piecewise linking is done
        for shared objects by creating reloadable object files.

>  We sometimes list also dependent
> libs in the makefiles (history and lazyness), and this then cumulates over
> many libraries.  Hmm, OK I need to check, if this really is so, but I
> suspect it.

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...

>  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 
locate all of the symbols shared between those libraries.  So, unless I am 
mistaken, the only way to fix that would be to have another case statement to 
remove shared deplibs only on platforms that are known to handle it well.  
Yuck.

I'm prepared to put the support for that into libtool if Alexandre concurs, 
but I'll (once again) rely on people to send me host triplets for platforms 
that can definitely survive the duplicate removal.  This is something we can 
debate between 1.3d and 1.4.

> Ciao,
> Michael.

Cheers,
        Gary.
-- 
  ___              _   ___   __              _         mailto: address@hidden
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___       address@hidden
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page:  /___/                      /___/                  gpg public key:
http://www.oranda.demon.co.uk           http://www.oranda.demon.co.uk/key.asc



reply via email to

[Prev in Thread] Current Thread [Next in Thread]