[Top][All Lists]

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

RFC: proposal for indirect deplibs

From: Ralf Wildenhues
Subject: RFC: proposal for indirect deplibs
Date: Wed, 24 Nov 2004 10:19:44 +0100
User-agent: Mutt/1.4.1i

This is a draft on how to proceed with the link_all_deplibs problem.
The idea is to expose the complexity portably to the user.
The rationale is that people get bitten by this complexity anyway,
so there is little gain in hiding it.  At the same time, systems
without needed-following linker should not be penalized.
Please comment/flame/improve/whatever.  If approved, I will rewrite this
to be part of HEADs documentation.


Libtool and inter-library dependencies


direct dependency:
A program or library has a direct dependency on a library, if it depends
on some interface that library provides, see node Interfaces for a more
thorough description.

indirect dependency:  
A program or library has an indirect dependency on a library, if it does
not depend on any interfaces of the library itself, but some
intermittent dependency library depends on such an interface.

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
dependent libraries.  Solaris and Linux are examples of this, [
prominent counter-example ].

[ Do I have to define soname?  Should I use a different word? ]

Before Libtool version 2.2, the handling of inter-library dependencies
has ignored the fact that some system linkers are smart enough to figure
out the library dependencies of dependent libraries themselves, and
always linked in all dependencies into the output.

This has lead to subtle problems on such systems when dependent
libraries are recompiled against different versions of its dependencies.
Multiple versions of a library may be linked in the same output,
resulting in a broken link.
[ insert example from Scott ]

On the other hand, on systems without a needed-following linker, it is
necessary to explicitly list all dependent libraries.  Libtool is smart
enough to find these dependencies itself if all dependent libraries are
libtool libraries (i.e., with accompanying .la files).  Since this is
often not the case, portable linking needs to specify these indirect

In order to allow to distinguish direct and indirect dependencies,
`libtool --mode=link' has two options, `-direct-deplibs' and
`-indirect-deplibs'.  The semantics are as follows:

- If none of these options are given, all libraries listed on the
  command line are treated as direct dependencies.
- The options can be given as often as necessary and hold for the
  following arguments.
- All dependencies picked up from libtool libraries (.la files) are
  treated as indirect dependencies.
- If a library is mentioned (or picked up) as both direct and indirect,
  it is treated as direct dependency.
- On systems with needed-following linker, all direct dependencies are
  encoded in the output.  On all other systems, all [ non-system? ]
  dependencies are encoded in the output.

[ TODO: Insert example here ]

On systems with needed-following linker, users are frequently tempted to
not include indirect dependencies 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 dependencies are guaranteed to be
libtool libraries (.la files), e.g. because they are built as part of
your software package as well, does omitting their indirect dependencies
work on such systems.

Example:  [ maybe it's not such a good example ] depends on, may depend on libdld, depending on the system.

Since both and 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

Open questions:
- Is it possible to find out in all cases which things actually mean the
  same library?
- Is it necessary for the previous question to be answered yes?
  Also on systems without needed-following linker?
- Is this really backwards-compatible?  I think so, libtool-1.5 and
  newer seem to ignore `-indirect-deplibs' and `-direct-deplibs'.
- Can it be implemented with reasonable effort?

reply via email to

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