libtool
[Top][All Lists]
Advanced

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

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


From: Ralf Wildenhues
Subject: Re: use of modules, static vs shared, and dependencies
Date: Mon, 19 Sep 2005 17:13:07 +0200
User-agent: Mutt/1.4.1i

Hi Howard,

* Howard Chu wrote on Mon, Sep 19, 2005 at 07:32:46AM CEST:
> 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 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?

> 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.
You don't use dlpreopening though, 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?

Cheers, and thanks for your explanations and the pointer!
Ralf




reply via email to

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