On Sun, Feb 03, 2008 at 05:17:45PM -0800, Russ Allbery wrote: > Stephen Gran <[EMAIL PROTECTED]> writes:
> > reopen 327585 > > found 327585 2.3.35-1 > > thanks > > This is in all likelihood not fixed (I am struggling with similar issues > > in freeradius, and I can guarantee the same techniques are not working > > there, and we both use the Debian ltdl). See > > https://bugs.launchpad.net/openldap/+bug/90812 for more reports of it > > being broken. > Well, I tested the Perl backend in slapd a while back and it worked for > me, so I really do think this bug is closed. That's why I closed it. Did you test the perl backend using any XS modules? The Debian OpenLDAP packages are linked against the system libltdl, which opens all objects with RLTD_LOCAL instead of RTLD_GLOBAL. RTLD_GLOBAL is what upstream libltdl uses, but it's not a sane behavior for a general-purpose system library because it's completely unscalable and has resulted in symbol clobbering bugs in the past; so the Debian package is patched to use RLTD_LOCAL, which in turn is not usable for the case of multiple levels of plugins where the plugins at the bottom level reference symbols that they expect to be provided by the caller. Since the perl package in Debian is not linked against libperl, perl extensions also cannot be linked against libperl since this would cause two copies of the perl XS symbols to be loaded. So perl modules have dangling symbol references that are expected to be resolved by whatever dlopen()s them, but if the perl interpreter itself is loaded via dlopen(RTLD_LOCAL), the perl symbols are not visible to the very perl extensions that it's loading, regardless of what flags the perl interpreter itself uses when calling dlopen(). Stephen and I were just discussing this extensively this morning in connection with freeradius, which has the same problem in Debian for rlm_perl; I'm pretty sure this analysis is correct, but I'm open to the possibility that it works by some means I haven't thought of so am interested to hear of any test cases you have for this. BTW, a similar bug was reported recently (... in the past 3 months or so; and possibly only via the mailing list) on the OpenLDAP package because back_meta references symbols from back_ldap but doesn't link against it, so back_meta in Debian can never see those symbols even if back_ldap is loaded first. I have a possible fix for this (which btw is detected by upstream's 'make test'), but have been reluctant to implement it so far because it's an ugly thing involving making symlinks to back_ldap to keep libtool happy. Ultimately, I think it was a poor decision for the libltdl authors to create an interface that doesn't support specifying crucial flags like RTLD_GLOBAL and RTLD_LOCAL when opening objects, as this has left us with use cases which have mutually exclusive requirements. Perhaps it's time to try to persuade libltdl upstream to add a fixed interface. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
