[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: use of modules, static vs shared, and dependencies

From: Howard Chu
Subject: Re: use of modules, static vs shared, and dependencies
Date: Sun, 18 Sep 2005 22:32:46 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050909 SeaMonkey/1.1a

Ralf Wildenhues wrote:
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's in favor of non-recursive

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?)

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.:

prog: slapd $(SLAPD_DYNAMIC_STUFF)

        blah blah blah

        blah blah blah

dummy2 $(SLAPD_DYNAMIC_STUFF): slapd
        blah blah blah

  -- Howard Chu
  Chief Architect, Symas Corp.
  Director, Highland Sun
  OpenLDAP Core Team  

reply via email to

[Prev in Thread] Current Thread [Next in Thread]