[Bug 960048] Can't load '/usr/lib64/perl5/auto/Fcntl/Fcntl.so' - undefined symbols

[bugzilla at redhat.com]

Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=960048

--- Comment #2 from Petr Pisar <ppisar at redhat.com> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=SG45KNpr5r&a=cc_unsubscribe