SEO

hi,

I have an executable A that links with a shared version of OpenLDAP
library (2.2.x)...some of the output from running 'chatr' on it is:

shared library dynamic path search:
SHLIB_PATH enabled first
embedded path enabled second /usr/lib
....
dynamic liblber-2.2.sl.7
dynamic libldap-2.2.sl.7
....

I also have a shared library B that links with a static version of
OpenLDAP library (2.1.4)... some of the output from running 'chatr' on
it is:

shared library dynamic path search:
SHLIB_PATH enabled first
embedded path disabled second Not Defined

Now, when executable A is running it loads (dynamically, via dlopen or
equivalent) the shared library B and then executes an exported routine
.... eventually I get a crash in OpenLDAP function. I've added code to
output OpenLDAP API info to the exported routine, and have also written
a small test app which tries to simulate the dynamic loading etc
behaviour of the executable A (but which doesn't have any sort of
dependency on OpenLDAP)

It would appear as though I get different OpenLDAP version information
being shown, depending on whether my test app is run (and loads shared
library B), or the executable A is run and does the loading/executing.
I'm just curious as to why this is happening... I would have expected
that since shared library B links with static OpenLDAP libraries, there
shouldn't be any conflict...

Is this the standard behaviour on HPUX 11.11, or some known loader bug?
Or maybe a sign that inappropriate method was used for loading the
shared library B? Is there some way around it (apart from both
executable A and library B being built using same version of OpenLDAP)?

p.s. by the way, this setup seems to work okay (no crashes) on Windows,
AIX, Solaris and Linux...

any tips/suggestions would be most welcome,

regards,
Greg


bash-3.1# uname -a
HP-UX <hostname> B.11.11 U 9000/800 1721108546 unlimited-user license

russiandevil@gmail.com writes:

> It would appear as though I get different OpenLDAP version information
> being shown, depending on whether my test app is run (and loads shared
> library B), or the executable A is run and does the loading/executing.
> I'm just curious as to why this is happening... I would have expected
> that since shared library B links with static OpenLDAP libraries, there
> shouldn't be any conflict...

Your expectations are incorrect (possibly originate from Win32).

If both libraries define some of the same symbols (which is likely),
then by default the first library that defines certain symbol "wins"
(as in, its symbol is used everywhere).

> Is this the standard behaviour on HPUX 11.11, or some known loader bug?

This is "standard" on all UNIXes (except AIX).

> Is there some way around it (apart from both
> executable A and library B being built using same version of OpenLDAP)?

You can (and should) hide (prevent from being exported) ldap symbols
in library B. Read "man ld", the '-h' option.

> p.s. by the way, this setup seems to work okay (no crashes) on Windows,
> AIX,

Windows and AIX use different export strategy ...

> Solaris and Linux...

Possibly work "by chance" (i.e. the bug is there, you just haven't
observed it yet).

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

thank you Paul. I seem to have gotten around the problem by using the
-Wl,-B,symbolic at the compiler command line... this is not exactly
hiding the symbols, but seems to get the job done