SLAPI (Fwd of: SLAPI (ITS#2073))

["Pierangelo Masarati" <ando@sys-net.it>]

I'm forwarding this to -devel because someone else may
wish to jump in and contribute to the development of the
SLAPI patch proposed by Steve Omrani <somrani@us.ibm.com>.
An updated version is available at

        http://www.sys-net.it/~ando/Download

> Ando,
>
> The additions you have suggested to slapd/config.c , slapd/slap.h,
> back-ldbm/init.c, back-bdb/init.c and removals from
> back-ldbm/comfig.c, back-ldbm/Makefile.in, back-bdb/config.c and
> back-bdb/Makefile.in work fine. The warnings from libtool come form
> linking shared library (libslapi.so) against static libraries from the
> libraries directory (libldif, libavl, libldbm, ...). By way of
> experimentation, I have converted the libraries to shared objects and
> the warnings simply went away. However, there is another problem.
> libslapi.so (and hence all plugins) need to share some global symbols
> with slapd in a way very similar to sharing of symbols between
> slapd.exe and the dynamic
> backends/external dynamic modules. This means we have to offer the
> users
>  methods to build slapd where all libraries are shared objects or
> static. User may build slapd  with static or shared object libraries
> regardless of whether libslapi.so is built. However, if a user is
> planing to build libslapi.so, then all libraries must be built in
> shared objects mode -- this is a prereq. Finally, some of the global
> symbols that libslapi.so needs are in slapd/*.c files. These files
> need to be collected in a separate directory so a shared object is
> produced that can be linked with both slapd daemon and libslapi.so. I
> am basically trying to get this last step working, but I am having
> difficulties getting all symbols resolved.

I was playing right now with SLAPI code; I can't make it work,
I think because of some linking problem (everything compiles
fine, except for that nasty libtool warning, but then I can't
even step thru the code with gdb without seeing very weird things, like
variables changing value between two steps that have nothing
to do with them and so.

BTW, I came out with another simplification: I removed
the ldapload.* files and replaced all the open/sym operations
with those of libltdl, since there's no need to add an additional
layer of dynamic loading functions and libltdl should ensure enough
abstraction.

The basic point for doing dynamic linking is that you need to
export symbols from the modules to slapd, and symbols from slapd
to the modules.  I think static libraries linked in slapd and
dynamic plugins can coexist without any harm; all you need to do
is compile the plugins with -shared and slapd with -rdynamic
(-export-dynamic in libtool, but this may be non-portable), so
that slapd exports its symbols to dynamic libraries (and solves
the chicken-and-egg problem).

If this is not viable, we may move all the functions that are
required by modules into a dynamic library that is linked both
by slapd and by the modules (that's what you did with your link,
only you made it static, if I understand it correctly).

I didn't check yet how this was fixed for dynamic backends, but
could make all the dynamic loaded stuff I ever compiled this way.

One more question, BTW: what's the "official" documentation for
SLAPI?  I guess it is a "de facto" standard from Netscape, right?

Ando.

PS: should we move to -devel, or stay with the ITS to keep track
of the issue?

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it