* Thien-Thi Nguyen wrote on Wed, Nov 24, 2004 at 11:53:25AM CET: > Ralf Wildenhues <[EMAIL PROTECTED]> 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? _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool