same symbol across shared libraries

[Steve Carlin]

Hi,

My problem is this:

I have two shared libraries, one that dynamically links with db2 shared libraries and one that dynamically links with odbc shared libraries. The functions in these underlying shared libraries are exactly the same (e.g. SQLConnect() ).

My application dynamically loads the library linked with db2 shared library first. Later on, my application dynamically loads the odbc shared library. The problem occurs when I call the SQLConnect() function within my odbc shared library. It is calling the wrong SQLConnect! (the one within the db2 library as opposed to the one within the odbc library).

Is there a linker option that I am missing? I did a scan through the man pages, but I didn't see anything.

Thanks,

SC

[Vincent Fleming]

It sounds like the dynamic linker is getting confused... how is it to know which SQLConnect() you want? So, it gives you the first it finds (the first loaded).

There are three things that I can think of that you can do to resolve this...

1. Change the name of the SQLCOnnect in one of the libraries, if you have source.
2. Statically link the odbc library to the executable.
3. Force the load of the odbc library before the db2 library, like this:

if ((hndl_foo = shl_load("libfoo.sl",
BIND_IMMEDIATE, 0)) == NULL)
perror("shl_load: error loading libfoo.sl"), exit(1);

Good luck

[Myriam Boileau]

Hi Steve,

We are having the exact same problem with db2 and odbc.

I was wondering if you were able to resolve your problem. If so could you please tell me what you did.

Looking at Vincent's answer, 1 is impossible, 2 might work but will cause other problems for us and 3 doesn't work.

Thanks for you time,
Myriam.

[Steve Carlin]

Hi,

I got sidetracked for awhile and haven't been able to look at the problem.

After looking at the solutions proposed, we have the exact same issues that I'm sure you have, that is:
for 1) We don't have the source code
for 2) We do not want to statically link either library
for 3) Forcing the load in the reverse order would cause the exact same problem for the other library.

So, no, I don't have a solution yet. I'll post a reply if I do find a solution that works for us.

Sorry,

SC

[Mike Stroyan · Accepted solution]

You may get the behavior you want by using dlopen with the RTLD_LOCAL flag.
dlopen is available for 32 bit programs on 11.00 by getting a current linker tools patch such as PHSS_23440 .
In the case of 32 bit executables the dlopen function is in libdld.sl rather than libdl.sl.

[Steve Carlin]

OK, this sounds very promising. I was using shl_load originially because the dlopen didn't exist on HP-10.

But I'm still not there yet. The dlopen works, but my first attempt to use dlsym always returns NULL. The dlopen/dlsym that I have works on other UNIX platforms.

I have a feeling that it has something to do with the function not being exported right. I tried using the +ee link object, but it didn't work. I would appreciate any help you can give. In the meantime, I'll keep looking.

Thanks,

SC

[Mike Stroyan]

You can check shared library symbol export and import lists for 32-bit excutables using
"odump -slexportlist" and
"odump -slimportlist".
odump is delivered as part of PHSS_24303. For 64 bit executables use
"elfdump -t".
You might get useful complaints from dld.sl by setting
"export _HP_DLDOPTS=-warnings"
as described in "man dld.sl".

[Pierre-Olivier Ceffis]

Hey there!

I've just had the same problem under the same circonstances.

I got 2 wrapper libraries, one linking to db2, the other linking to oracle. I dynamically load the wrappers (with calls to shl_load) in my application when a database connection is needed, and the second wrapper loaded gets symbols resolved from the wrong library.

The problem is that both the oracle and the db2 libs export symbols with the same name.

Two ways to get rid of the problem:
- pass the BIND_FIRST flag to shl_load when loading the wrapper libs. When loading the second wrapper (say the wrapper to db2), all the needed libs (that is the db2 libs) will be placed at the head of the symbol search order, ensuring that the dynamic linker resolves all the needed symbols in the db2 libs, and not in the oracle libs (that would already be loaded)
- build the wrapper libs using -Wl,-Bsymbolic option, causing all the unresolved symbols in the library to be resolved internally (if possible)

I just hope it helps!
POC