Weeelll ... if you can statically link openldap into nss, and then use a map file to ensure that none of it's symbols are exported: that would do the trick. Yes, static linking should fix this problem. But I will create other headaches. Mainly maintenance related (See also comment #18). You will have to link all of

Hopefully, (being cross platform) we have to maintain such a map-file anyway; so it should be possible to ensure that we don't get any openldap symbols straying out into the main process. nss_ldap already uses such a version script, it only exports the needed symbols. IIRC the problem with Thunderbird is not, that it calls functions from

https://bugzilla.novell.com/show_bug.cgi?id=157078#c32 --- Comment #32 from Ralf Haferkamp <rhafer@novell.com> 2007-11-05 05:42:29 MST --- (In reply to comment #31 from Michael Meeks) libldap's dependencies statically into nss_ldap as well (mainly openssl and cyrus-sasl). That means with every update of those dependend packages (security or "normal" maintenance) we will have to release nss_ldap updates as well. So IMO we should try to avoid linking nss_ldap statically. the libldap that nss_ldap is linked against (OpenLDAP), but "nss_ldap" calls into the libldap that Thunderbird is linked against (Mozilla LDAP SDK).

Failing that, as JP says if you can dlopen *both* versions RTLD_LOCAL - then you'd be alright, but the 1st solution is far simpler. Poke in 'info ld' for:

"When it is used to export symbols in executables, it is similar to `--export-dynamic', except for that symbols can be exported selectively with a version script.

{ global: foo; bar; local: *; };" etc.

but perhaps I'm teaching my grandparents to suck eggs :-)

-- 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.