[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: OpenLDAP / Oracle LDAP: naming collision for ldap_set_option/ldap_get_option



Hi Andrew,

i didn't swap them around on my own. The problem is caused by the linker ;)

libclntsh.so.11.1 also provides the routines for accessing an Oracle database (which is required). As the library is monolithic i can't simply remove some routines as i don't know what Oracle is doing then.

I thought that using a separate namespace from the OpenLDAP and a separate one for the Oracle family would be helpful to avoid any trouble in the future.

Kind regards
Peter


On 24.05.2011 11:41, Andrew Findlay wrote:
On Fri, May 20, 2011 at 01:40:29PM +0200, Peter Steiert wrote:

After longer investigation i found out that the routines:
	ldap_set_option
	ldap_get_option

are defined in OpenLDAP/ldap.h as well as in Oracle/ldap.h
and are locatable in Oraclelib/libclntsh.so.11.1 as well as in
OpenLDAP/libldap_r.so.

So the ld-loader is sometimes offering the oracle code to the client
and sometime the openldap code. This causes failure in the
application.

No surprise there! I doubt very much that the OpenLDAP
libraries and the Oracle ones would be ABI-compatible so you
should not expect to swap them around.

Now my question to the community here:
Is there a global naming definiton about these routines to avoid
such a conflict?
Wouldn't it be better if Oracle would use it's own namespace
convention as well as OpenLDAP?

The correct soution is to link the application in such a way
that it picks up at runtime the same library that it was
linked against when built. It is generally a recipe for
disaster to try to link two LDAP libraries in one
application (this is one of the problems with the original
PAM LDAP and NSS LDAP implementations).

What does Oraclelib/libclntsh.so.11.1 provide? Do you really
need it? You could certainly have a problem if it lumps LDAP
code in with other stuff that you need. (If that is the
case, then maybe you should consider running the LDAP code
in a separate process with a simple socket link between the
two).

Andrew