[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: Mon, 19 Sep 2005 14:58:36 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050909 SeaMonkey/1.1a

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?


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!

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

reply via email to

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