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