We have this situation in OpenLDAP slapd, since a number of modules can
be built either statically (linked into the slapd executable) or
dynamically (loaded by libltdl), and several of the modules depend on
each other in addition to the main slapd executable and the
libldap/liblber libraries (which may be static or dynamic). In this
case, each module's compilation is controlled by a three way --enable
switch at configure time: no (don't build), yes (static), mod (dynamic).
The list of static and dynamic modules go into two separate Makefile
macros. The slapd Makefile compiles all static modules, the slapd
executable, and then all dynamic modules, three separate steps. There
are appropriate dummies in case either of those two macros is empty, e.g.:
OK, you have one single Makefile from which to build stuff.
Actually no, each module is in its own subdirectory with its own
Makefile. We also set a BUILD_FOO=yes|mod macro for each of the modules
so that its own Makefile knows what to do. There's also a subdirectory
(overlays) that contains a bunch of modules that can be either static or
dynamic, we just descend into it twice - once with "make static" and
once with "make dynamic". (Yes, we should probably streamine this so
that there aren't two different approaches to building modules...)
You don't use dlpreopening though, right?
Right.
One thing I haven't grasped is this: suppose one would like to use
dlpreopening for the static case. Will this help in any way with the
dependency mess? Is there anything we can do to automate this or keep
the user from shooting himself in the foot with wrong dependencies?
I remember when we first added dynamic module support, we also tried to
support dlpreopening, but that was just confusing. I.e., why should we
go through the module-handling work for something that is statically
linked into the main executable... So in our case, there didn't seem to
be anything to be gained from that.
There is of course some other overhead for static modules; for example
our configure script generates a backends.c file that contains an array
of references to the entry points of all the static backends.
Cheers, and thanks for your explanations and the pointer!
Ralf
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool