Bug 960048

Happens with perl-5.16.3-242.fc18.x86_64 as well.

Also:
# ldd /usr/lib64/perl5/auto/Fcntl/Fcntl.so
	linux-vdso.so.1 =>  (0x00007fff0ad6c000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f1c72ebc000)
	/lib64/ld-linux-x86-64.so.2 (0x000000370f200000)

No libperl.so here. Shouldn't Fcntl.so be linked with libperl as well? I'm not sure what the correct solution here is.

Fcntl.so is plug-in into libperl.so, so there is no DT_NEED on libperl.so. That's Ok.

I checked the openldap's back_perl.so and it's built properly:

$ scanelf -nr /usr/lib64/openldap/back_perl-2.4.so.2
 TYPE   RPATH NEEDED FILE 
ET_DYN /usr/lib64/perl5/CORE libperl.so,libnsl.so.1,libm.so.6,libcrypt.so.1,libutil.so.1,libldap_r-2.4.so.2,libsasl2.so.2,libssl3.so,libsmime3.so,libnss3.so,libnssutil3.so,libplds4.so,libplc4.so,libnspr4.so,libpthread.so.0,libdl.so.2,liblber-2.4.so.2,libresolv.so.2,libc.so.6 /usr/lib64/openldap/back_perl-2.4.so.2 

I suspect slapd dlopens the back_perl.so with strange linking flags that makes some libperl symbols unavailable.

openldap relies to lt_dlopenext(), and libtool library documentation states some funny things about threads which is the symbol reported by the error message:

Note that libltdl is not well tested in a multithreaded environment, though the intention is that it should work (see Using libltdl in a multi threaded environment). It was reported that GNU/Linux's glibc 2.0's dlopen with ‘RTLD_LAZY’ (which libltdl uses by default) is not thread-safe, but this problem is supposed to be fixed in glibc 2.1. On the other hand, ‘RTLD_NOW’ was reported to introduce problems in multi-threaded applications on FreeBSD. Working around these problems is left as an exercise for the reader; contributions are certainly welcome.

There is excellent analysis of the problem in Debian bug tracking system <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=327585#50>. It's as I suspected:

The libtool dynamic loader lt_dlopen() used by openldap does not allow loading modules from modules and that is exactly what openldap does. slapd loads back_perl module that pulls in libperl symbols, but libperl loads Fork.so module that is not linked against libperl (for a good reason, to prevent from double-linking). And because ld_dlopen prohibits exporting resolved symbols globally, i.e. the libperl symbols, Fork.so, or any XS Perl module, will not see libperl symbols.

There is no easy fix:

(1) One can change openldap to use dlopen() instead of lt_dlopen().

(2) One can change libtool to export all symbols globally.

(3) One can start linking all Perl XS modules against libperl.

Created attachment 744718 [details]
Work-around for openldap

This is copy of patch used by Debian <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=327585> to make slapd exporting all module symbols globally.

Current libtool allows to change export strategy to RTLD_GLOBAL. That merged (1) and (2) proposals into one solution on openldap side.

The (3) proposal is not doable in released Fedora because complete fix would require rebuilding all Perl packages (more the 2000).

So I propose to implement the work-around in openldap.

Thanks, Petr!

As stated in the debian bugreport:

"... the *right* fix is to fix perl ... so that everything is linked against libperl.  All other solutions are workarounds, not fixes."

And also:

"The patch proposed ... carries side effects, because it will cause openldap to open all modules with RTLD_GLOBAL. This increases the risk of a symbol collision causing openldap to crash (the precise issue that libltdl was switched to RTLD_LOCAL to avoid), and even if that doesn't result in a bug now, it might do so in the future.

But it seems to be the best we can do short of the perl fix ... "

... which in our case is to rebuild more than 2000 packages.

So yes, I'll apply this workaround.

Pushed:
http://pkgs.fedoraproject.org/cgit/openldap.git/commit/?id=05278cd5066d3f531afd05926d8f76a487eb8c64

openldap-2.4.35-4.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/openldap-2.4.35-4.fc19

openldap-2.4.35-4.fc18.1 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/openldap-2.4.35-4.fc18.1

Package openldap-2.4.35-4.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing openldap-2.4.35-4.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-7759/openldap-2.4.35-4.fc19
then log in and leave karma (feedback).

openldap-2.4.35-4.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

openldap-2.4.35-4.fc18.1 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.