Re: RFC: proposal for indirect deplibs

[Jacob Meuser]

On Wed, Nov 24, 2004 at 02:05:50PM +0100, Ralf Wildenhues wrote:
> * 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!

Thank you Ralf for putting time into this!  What you have here makes
sense to me.

-- 
<address@hidden>

> 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?
> 
> 
> _______________________________________________
> Libtool mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/libtool