libtool
[Top][All Lists]
Advanced

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

Re: RFC: proposal for indirect deplibs


From: Noah Misch
Subject: Re: RFC: proposal for indirect deplibs
Date: Wed, 24 Nov 2004 23:51:56 -0800
User-agent: Mutt/1.5.6i

This is a great document.  A few comments --

On Wed, Nov 24, 2004 at 02:05:50PM +0100, Ralf Wildenhues wrote:
> needed-following linker:
> A system with a needed-following linker has a means to record
> dependencies on other libraries within a library (based on the soname of
> the dependency library), and a linker that uses this information to load
> all base libraries.  Solaris and Linux are examples of this,
> [ prominent counter-example ].

The dynamic linker must also respect the rpaths of libraries if we are to rely
upon it for semantics tantamount to directly linking all dependencies.

> On the other hand, on systems without a needed-following linker, it is
> necessary to explicitly list all base libraries, direct as well as
> indirect.  Libtool is smart enough to find all base libraries of libtool
> libraries.  But often, base libraries are not produces by libtool on
> such systems.  So portable linking needs to specify these indirect
> base libraries.

This paragraph makes an admonition that is independent of whether libtool links
dependency libraries directly, but its placement in the text and the ``On the
other hand'' opening might lead readers to think otherwise.  I would adjust and
incorporate it into another node or the introduction to this node.  It is an
important consideration, so I would also add it to the branch-2.0 manual.

> On systems with needed-following linker, users are frequently tempted to
> not include indirect base libraries in the link line at all.  Be warned,
> however, that this is not portable, because it will generally fail on
> other systems.  Only if your direct base libraries are guaranteed to be
> libtool libraries (.la files), e.g. because they are built as part of
> your software package as well, does omitting indirect base libraries
> work portably.
> 
> Example:  [ maybe it's not such a good example ]
> libltdl.la depends on libdlloader.la,
> libdlloader.la may depend on libdld, depending on the system.
> libltdl.la depends on libdlloader.la,
> libdlloader.la may depend on libdld, depending on the system.
> 
> Since both libltdl.la and libdlloader.la are built within the same
> package and thus guaranteed to both be libtool libraries, it is ok to
> omit `-ldld' from the link line of libltdl.la.

I think it is safe to assume that libraries that have been libtool libraries
will remain libtool libraries.  Libtool itself makes this assumption when
populating dependency_libs.  Indeed, were we recommend that users explicitly
list dependencies of libraries they do not control, we may as well remove all
dependency tracking from libtool, as it would only hide portability bugs.

Libraries that became libtool libraries partway through their evolution pose a
problem.  Fortunately, most libraries with interesting dependency graphs that do
not use libtool seem to ship a foo-config script or a pkg-config database that
indicates their version and dependency information.  Users of those libraries
can use the -config script to check the library version and dependency
information and decide how to proceed.




reply via email to

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