Aaron Richton wrote:
On Thu, 6 Jun 2013, Howard Chu wrote:
Doug Leavitt wrote:
Finally, Solaris direct linking should protect the third party
application in the event that dynamically loaded Solaris library
dynamically loads one of the two libldaps for it's needs. In this
event even if both libraries are loaded into the application, the
Solaris library will use the one it needs while the application will
use the one it was linked with and they won't cross name space or
functional boundaries.
You might suggest to your colleagues at Oracle that they do this in other
libraries they ship too.
http://www.openldap.org/its/index.cgi/Incoming?id=7599
To be fair, that ITS is for Linux, and last I heard the direct linking
support patches weren't accepted to glibc. So the Solaris-style "ld
-Bdirect -Minterposers.mapfile" won't work for that report.
We're getting a bit off-topic, but there's no reason for a vendor library
whose purpose is not to provide an LDAP API to expose/export LDAP API symbols.
They could use -Bsymbolic or an explicit list of exported symbols in a mapfile
to prevent such symbol leaks from occurring. You don't *need* any particular
Solaris-specific features to avoid these issues.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/