Re: RFC: proposal for indirect deplibs

[Ralf Wildenhues]

* Thien-Thi Nguyen wrote on Wed, Nov 24, 2004 at 11:53:25AM CET:
> Ralf Wildenhues <address@hidden> writes:
> 
>    [definitions]
> 
> my head is already swimming because "dependent", "dependency" and
> "dependence" all are very subtly different and have different
> meanings in different contexts.

OK.  Let's clean this up.

> i like the term "upstream" and "downstream" because a moment's
> thought in comparison w/ the real-world (physical) motion of water
> shows what is upstream affects what is downstream, but not the
> other way around.
> 
> unfortunately, i have no suggestion on how to adapt these terms to
> things that are mutually-dependent.

Let's see.  The analogy to a class hierarchy fits somehow (with the
exception of mutual dependency). So, what about:
- base library
- derived library (one that depends on `base')
- mutual dependent libraries (I was hoping I could avoid this term).

- direct vs. indirect base library
example:  libA -> { libB, libC }, libB -> { libC, libD }
then libD is indirect base of libA, and libC direct base of libA.
Conversely, libA is directly derived from libB and libC, and
indirectly derived from libD.

Does that make more sense?  A rewritten draft, amended by a few more
examples, is at the end of this mail.

> as for the rest of the text, IIUC you are proposing a way to
> explicitly distguish direct from indirect.  how about also
> distiguishing between "fatal-indirect" and "non-fatal-indirect"?
> (i presume lack of direct is always fatal.)

What exactly do you mean with these terms?  (I have a vague idea
but would rather like to know a precise definition.)

I am trying to allow 
- libraries to have as few dependencies as possible
- while still being portable to all kinds of systems.
The advantage of the former is only felt on systems like linux or
solaris (and then only with shared libraries, of course).

Since it is in general impossible to find out which library dependencies
are directly or indirectly derived by looking at the source


Thanks for your feedback!

Regards,
Ralf


Libtool and inter-library dependencies
======================================

Definitions:

direct base library:
A program or library has a direct base library, if it depends on some
interface that base provides, see node Interfaces for a more thorough
description.
Example:
If you use cos() in your program or library, then libm is a direct
base library, and your program/library is directly derived from it.

indirect base library:
A program or library has an indirect base library, if it does
not depend on any interfaces of the library itself, but some
base library of the program depends on such an interface.
Example:
A program makes no use of any math routines itself, but uses a library
libalgorithms, which uses the cos() function.  Then libm will be a
indirect base library of the program, but a direct library of
libalgorithms.  Conversely, libalgorithm is directly derived from libm,
but your program is indirectly derived from libm.


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 ].

[ 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 base libraries of base libraries (recursively) themselves, and
always linked in all base libraries into the output.

This has lead to subtle problems on such systems when base libraries are
recompiled against different versions of its bases.  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 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.

In order to allow to distinguish direct and indirect base libraries,
`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 bases.
- The options can be given as often as necessary and hold for the
  following arguments (thus, order is important).
- All bases picked up from libtool libraries (i.e., the information
  found in the dependency_libs variable in .la files) are treated as
  indirect base libraries.
- If a library is mentioned (or picked up) as both direct and indirect
  base, it is treated as direct base.
- On systems with needed-following linker, only the direct base
  libraries encoded in the output.  On all other systems (and of course
  when linking statically), all [ non-system? ] bases are encoded
  in the output.

[ TODO: Insert example here ]

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.


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?
- What about rpath?