Library linking and loading problem

English Applications
1

Hi All,

I am using SLES: Linux informixva 2.6.27.39-0.3-vmi #1 SMP 2009-11-23 12:57:38 +0100 i686 i686 i386 GNU/Linux

On this OS I am facing problem of library loading. Here is what I am doing:

I have 2 vender specific ODBC driver libraries (say X and Y). So we have same function signatures for most of the APIs defined in these libraries.

On top of these driver libraries, I have built 2 more secondary libraries (A is built on top of X and B is built on top of Y).

A is linked to X in following ways: -L/home/user/tempA/lib/ -lX -Wl,-rpath -Wl,/home/user/tempA/lib/
B is linked to Y in following ways: -L/home/user/tempB/lib/ -lY -Wl,-rpath -Wl,/home/user/tempB/lib/

Now my application needs to use both A and B. While compiling my application I specified A first to the linker.

When my app is running, if I call APIs from lib A everything works fine, since A uses X. But when I call APIs from B, what is happening is that B’s call to Y is getting resolved to X.

If I reverse the order of library declaration when compiling my application (put B first and then A), the behaviour is like:
B’s calls to Y are fine. A’s calls to X are being resolved to Y.

On windows and Ubuntu, my app works fine. To me it seems that the runtime loader is resolving exports just on functionName on SUSE, while on Ubuntu it is LibraryName+functionName

Can anyone help me on this?

Regards,
Ambrish Bhargava

2

Indeed Windows does it the way you want. But the standard Unix behavior is the one you are obtaining in openSUSE (it’s really hard to believe Ubuntu changed that, but…)

This can be “fixed” versioning the symbols in libX and libY, supposing you have access to its code.

3

To be absolutely clear. From http://www.sco.com/developers/devspecs/gabi41.pdf, page 92:

When the dynamic linker creates the memory segments for an object file, the
dependencies (recorded in D T N E E D E D entries of the dynamic structure) tell what
shared objects are needed to supply the program’s services. By repeatedly connecting
referenced shared objects and their dependencies, the dynamic linker
builds a complete process image. When resolving symbolic references, the
dynamic linker examines the symbol tables with a breadth-first search. That is, it
first looks at the symbol table of the executable program itself, then at the symbol
tables of theD T N E E D E D entries (in order), then at the second levelD T N E E D E D
entries, and so on.

4

Thanks for the info.

Regards,
Ambrish Bhargava