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.
Regards, Ralf Libtool and inter-library dependencies ====================================== Definitions: 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 dependencies. 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 ] 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? _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool