Re: libtool (a bit more serious this time)

Date view Thread view Subject view Author view

From: Alexandre Oliva (oliva@dcc.unicamp.br)
Date: Mon Jan 18 1999 - 04:49:39 EST


On Jan 18, 1999, Godmar Back <gback@cs.utah.edu> wrote:

> First, I consider it fundamentally wrong for a tool to encourage linking
> mistakes by adding libraries to the link line multiple times without being
> told to do so --- like libtool apparently does.

It does when told to do so, even if indirectly. Let me explain: if
libtool archive libfoo.la is linked with -lbar, then you link a
program with libfoo.la, libtool will replace libfoo.la with
`libfoo.${libext} -lbar', to ensure that all dependencies of libfoo
can be properly satisfied.

Now, if multiple libraries are linked with -lbar, and you link a
program with these multiple libraries, -lbar will appear in the link
command multiple times, and this should be correct.

Even when you count on library overriding, like the OSKit project
does, the fact that libtool adds libraries in the order they appear is
beneficial, because it ensures that, if the library dependencies are
properly declared, all symbols that the libtool archive imports from
its dependencies will have been resolved before any other library is
opened.

For an example, assume that a program is linked with libfoo.la, -lbaz
and -lbar, and -lbaz defines some symbols that are also defined in
-lbar. Since libfoo.la was linked with -lbar, any undefined symbols
in libfoo.la but defined in -lbar should be imported from -lbar, and
not from any other library. In order to ensure that this occurs,
libtool will actually link the program with `libfoo.${libext} -lbar
-lbaz -lbar'.

If libtool tried to outsmart you, deciding that you had already
specified -lbar, so there was no point in specifying -lbar after
libfoo.${libext}, libfoo would end up having symbols resolved in
-lbaz, not -lbaz. OTOH, if it decided that your additional
specification was duplicated and removed it, you'd end up with
unresolved symbols in -lbaz.

> Lemma 1:
> A link line should contain every library exactly once.
> Period. Big Period.

I'm sorry, but this lemma is completely bogus. A library should be
listed as many times as it must in order to ensure that inter-library
dependencies are correct.

> I hope this is useful input. The reason I'm writing is that the use of
> the word "transparent" in the following TODO entry in libtool/TODO made me
> highly concerned:

> * Inter-library dependencies should be fully tracked by libtool.
> Reminded by Alexandre Oliva. This requires looking up installed
> libtool libraries for transparent support.

The `transparency' issue has to do with being able to use -lfoo to
link in a libtool library. Thomas Tanner has been working on this,
and he's already got a patch that does just that, but don't think
we're going to include it in libtool 1.3.

-- 
Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:44 EDT