https://bugzilla.novell.com/show_bug.cgi?id=157078
User mmeeks@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=157078#c36
--- Comment #36 from Michael Meeks 2008-05-27 08:36:17 MDT ---
Well - it's an interesting bug certainly :-)
glibc dlopen's the *nss* libraries - that then link to openldap client:
26206: transferring control: wget
26206:
--2008-05-26 15:28:47-- http://www.ibm.com/
Resolving www.ibm.com... 26206: find library=libnss_files.so.2 [0];
searching
26206: search cache=/etc/ld.so.cache
26206: trying file=/lib64/libnss_files.so.2
this good stuff then links directly to openldap-client:
$ ldd /lib/libnss_ldap.so.2
linux-gate.so.1 => (0xffffe000)
libldap-2.4.so.2 => /usr/lib/libldap-2.4.so.2 (0xf7e6b000)
liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 (0xf7e5c000)
..
$ rpm -qf /usr/lib/libldap-2.4.so.2
openldap2-client-32bit-2.4.9-4
etc.
So - the symbol problems are not -such- an issue for the glibc pieces since
they are versioned GLIBC_PRIVATE, but as soon as we link the external library
we have:
$ objdump -T /lib/libnss_ldap.so.2
/lib/libnss_ldap.so.2: file format elf32-i386
DYNAMIC SYMBOL TABLE:
..
00000000 DF *UND* 000002d8 ldap_first_attribute
..
00000000 DF *UND* 0000002b ldap_memfree
etc. which cause the grief of course.
SOOooo ...
Perhaps this is something for RTLD_DEEPBIND in glibc ?
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.