Hi Howard,
Hope you don't mind my chiming in here... mostly for the benefit
of the archives, and lurkers:
Howard Chu wrote:
why should we
go through the module-handling work for something that is statically
linked into the main executable...
You only have to write the module calling code onc
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 (w
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 reo
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 structu
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 libmiddl
