RE: slapd and dynamic modules

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 06:56 PM 2/25/2004, Howard Chu wrote:
>Another approach here is to merge slapadd/slapcat/slapindex into the main
>slapd binary and just differentiate based on argv[0] and commandline args.
>Any objections?

Seems like a reasonable suggestion.

Kurt


>  -- Howard Chu
>  Chief Architect, Symas Corp.       Director, Highland Sun
>  http://www.symas.com               http://highlandsun.com/hyc
>  Symas: Premier OpenSource Development and Support
>
>> -----Original Message-----
>> From: owner-openldap-devel@OpenLDAP.org
>> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Howard Chu
>> Sent: Tuesday, January 20, 2004 11:30 PM
>
>> 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.