[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: duplicate dependencies [was: RE: Very slow links: > 1 hour to lin k
Re: duplicate dependencies [was: RE: Very slow links: > 1 hour to lin k single executable - can we help?]
Fri, 9 Nov 2001 20:11:50 +0100 (MET)
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.