A real-world example of libltdl use and an issue with static and shared linking, and library interdependencies. Come up while testing usability of CVS HEAD. :)
We have - a large libuserapi provides an API for third-party users (programs and possibly libraries), - libuserapi depends on libmiddle which is a middle layer (think algorithm abstraction), and that in turn depends on - libplatform, the platform abstraction library. The latter also directly uses libltdl. All three of them can make use of modules through this (via another abstraction layer in libplatform). The modules themselves need symbols from varying sets of the three libraries themselves, and thus are linked against them. The package allows, at configure time, to choose whether some module may be built dynamically, or statically directly linked into (one of) the layer libraries (it is then built as a convenience library; there is no prelinking involved, the libtool `-dlopen' switch is not used either). At runtime, the user may still choose which of the available modules to actually use now. The build tree consists of several hundred directories. Issue: When linked statically, a module needs to be built before its encompassing library. OTOH, if built dynamically, it needs the library to link against it. This is currently solved by reordering SUBDIRS during configure. Obviously, this limits the source tree structure, and the chance to eliminate many Makefile.am's in favor of non-recursive builds. Can we do better than this in any way with the features in CVS HEAD? When using preopened modules, do we provide for this kind of setup at all? Portably for all kinds of systems? Should I draw a diagram? (yes, I know, it should be a test case.. did I mention it's large?) Cheers, Ralf _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool