use of modules, static vs shared, and dependencies

[Ralf Wildenhues]

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