Re: duplicate dependencies [was: RE: Very slow links: > 1 hour to lin k single executable - can we help?]

[Michael Matz]

Hi,

On Mon, 5 Nov 2001, Rob Browning wrote:

> "Boehne, Robert" <address@hidden> writes:
>
> > This is a known problem that results from supporting multiple
> > dependent archive libraries.  In some cases libtool can't strip the
> > redundant -lfoo -lbar in dependencies.
>
> Is this because it doesn't know how, or because stripping them would
> be bad in some situations (what you say later implies the latter, but
> I wanted to be sure), and if stripping duplicates would be bad, why?

It's like this: static libraries may depend circularly on each other
(shared libs too, but for those it doesn't matter), so there are
situations, where -la -lb -la is required, and the second -la may not be
stripped.  libtool recognizes these situations, when the user gives
_explicitely_ to the libtool link command such multiple -l arguments.
libtool then also adds the appropriate -l flags to the dependency_libs in
the .la file.  If now that .la file is used for linking another lib, those
multiple -l's are read in, and remembered.  If the user now unfortunately
gives one of those multiple -l's again also on libtools command line, it's
added again, and no multiples are removed.  Due to some bugs in libtool
these double -l's might multiplicate more and more, even to non-sense
situations like "-la -la -la -la -la -lb -la", but due to the
"specialness" of -la they get not cleaned up.

The point is (unless one fixes the assorted bugs in libtool), to be
painfully sure, that one adds _nowhere_ the same -l argument multiple
times to the same libtool link command (it's OK to repeat a dependence
lib again, which might already be written in some .la file, which is used,
i.e. suppose b.la contains already a -la, and one producues c.la by
"libtool --mode=link ld -o c.la b.la -la".  In that situation the multiple
-la's _are_ removed.  Compare this to
"libtool --mode=link ld -o c.la b.la -la -la".  From that command on all
is doomed.  All libraries depending on c.la will contain heaps over heaps
of -la, which grow bigger and bigger the more far away c.la becomes in the
dependecy list (e.g. if z.la dependes not directly on c.la, but only
through y.la <-- x.la <-- w.la and so on, the list of -la's will probably
span the equator).

This is also how I handle it in KDE.  Ensuring that no -l get into link
commands multiple times (currently some plugins get multiple -l's, but
that's no big problem, as they are not linked against, but are leaves in
the dependecy tree).  Note that the above workaround is based on a changed
multiple-language-branch of libtool.  I have no real experience with HEAD.
It uses autoconf 2.5x exclusively, that's why I can't switch to it in KDE.


Ciao,
Michael.