slapd and dynamic modules

["Howard Chu" <hyc@highlandsun.com>]

Well, this problem first reared its head with Windows and I ignored it, but
it's also an issue on z/OS and some AIX releases as well - on these
platforms, not only do shared objects need to have symbol references fully
resolved at build time, but the name of the file that provides the symbols is
also embedded by the linker, and only that named file is allowed to resolve
the symbols at runtime. This is in contrast to SysV-derived dynamic linkers,
which record the file dependencies but allow a symbol to be resolved by the
first module the runtime linker sees, regardless of whether it was the same
file that was originally linked at build time.

What this means to us is that on these platforms, plugins, overlays, modules,
and dynamic backends all must be linked against the slapd binary, and that
they generally will not behave correctly when loaded by the
slapadd/slapcat/slap* tools. If they are implicitly linked against slapd (as
our current build environment is set up) then when e.g. slapadd loads a
module, that module will implicitly bring in a copy of the slapd binary. And
when the module calls a function to register itself (like backend_init or
overlay_register) it will do so in the address space of the slapd image. When
slapadd gets to a point that tries to invoke code from that module, (e.g.,
"backend bdb") it will fail, because the module isn't registered in slapadd's
address space.

Having gone through this a few different ways in my mind, it seems the only
reliable solution to the problem is to build slapd itself as a DLL, with
slapd/main.c linking against it. Likewise the slap tools would link against
the DLL instead of statically linking the .o's and mimic that it does now.
And of course the backends and any other dynamic modules would link against
the slapd DLL and everything will work great. The up side is that this "fix"
doesn't break any of the other platforms that support dynamic linking.

The downside is that this may make the static builds a little weird; I
haven't thought that far yet. Any comments?

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support