Mailinglist Archive: opensuse-bugs (9457 mails)

[bugzilla_noreply@xxxxxxxxxx]

https://bugzilla.novell.com/show_bug.cgi?id=157078#c32





--- Comment #32 from Ralf Haferkamp <rhafer@xxxxxxxxxx>  2007-11-05 05:42:29 
MST ---
(In reply to comment #31 from Michael Meeks)
> 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
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. 

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