[Michael Matz <matz@kde.org>] Re: duplicate dependencies [was: RE:
Very slow links: > 1 hour to lin k single executable - can we help?]
Rob Browning
rlb@defaultvalue.org
Fri, 09 Nov 2001 16:25:16 -0600
--=-=-=
For those interested, here's an attempt at an explanation of why -la
-lb -la can't always be stripped, and the libtool link-time problem in
general...
--=-=-=
Content-Type: message/rfc822
Content-Disposition: inline
X-From-Line: matzmich@cs.tu-berlin.de Fri Nov 9 13:13:03 2001
Return-Path: <matzmich@cs.tu-berlin.de>
Delivered-To: rlb@raven.i.defaultvalue.org
Received: from defaultvalue.org (omen.i.defaultvalue.org [192.168.1.1])
by raven.i.defaultvalue.org (Postfix) with ESMTP id B0D37A16
for <rlb@raven.i.defaultvalue.org>; Fri, 9 Nov 2001 13:13:03 -0600 (CST)
Received: by defaultvalue.org (Postfix)
id 4DBB93BA0; Fri, 9 Nov 2001 13:13:19 -0600 (CST)
Delivered-To: rlb@defaultvalue.org
Received: from mail.cs.tu-berlin.de (mail.cs.tu-berlin.de [130.149.17.13])
by defaultvalue.org (Postfix) with ESMTP id 361EE3B56
for <rlb@defaultvalue.org>; Fri, 9 Nov 2001 13:13:18 -0600 (CST)
Received: from platon.cs.tu-berlin.de (matzmich@platon.cs.tu-berlin.de
[130.149.25.107])
by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id UAA02179;
Fri, 9 Nov 2001 20:11:51 +0100 (MET)
Received: (from matzmich@localhost)
by platon.cs.tu-berlin.de (8.9.3/8.9.3) id UAA26795;
Fri, 9 Nov 2001 20:11:51 +0100 (MET)
Date: Fri, 9 Nov 2001 20:11:50 +0100 (MET)
From: Michael Matz <matz@kde.org>
X-X-Sender: <matzmich@platon>
To: Rob Browning <rlb@defaultvalue.org>
Cc: "Boehne, Robert" <rboehne@ricardo-us.com>, <libtool@gnu.org>
Subject: Re: duplicate dependencies [was: RE: Very slow links: > 1 hour to
lin k single executable - can we help?]
In-Reply-To: <87vggpw4a0.fsf@raven.i.defaultvalue.org>
Message-ID: <Pine.GSO.4.33.0111091951200.25381-100000@platon>
Lines: 54
Xref: raven.i.defaultvalue.org inbox:35047 libtool:41
MIME-Version: 1.0
Hi,
On Mon, 5 Nov 2001, Rob Browning wrote:
> "Boehne, Robert" <rboehne@ricardo-us.com> 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.
--=-=-=
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD
--=-=-=--