controlling scope of symbols in shared libraries

[Michael Shifflett]

I have a Java application that loads two different C shared libraries using loadLibrary - let's call them liba.sl and libb.sl.

liba.sl relies on another shared library, liba_depend.sl. Similarly, libb.sl relies on another shared library, libb_depend.sl. The dependent shared libraries, liba_depend.sl and libb_depend.sl contain common symbol names. In other words, there are functions defined in liba_depend.sl with the same names as functions in libb_depend.sl.

The problem that I see is that the first dependent library loaded is used to resolve symbols in both liba.sl and libb.sl. The desired behavior is for liba.sl to resolve symbols using liba_depend.sl and for libb.sl to resolve symbols using libb_depend.sl. I see the desired behavior on Solaris, Linux, AIX, and Windows but observe the problem on HP-UX.

Using HP-UX 11.0 PA-RISC 2.0 and JDK 1.4.1.

Thanks in advance for any help.

Mike Shifflett
mshifflett@convera.com

[Michael Shifflett]

I have reproduced the problem in a "pure C" environment - that is with Java out of the picture. Here, a C application uses shl_load() to load liba.sl and libb.sl. But libb.sl is resolving symbols in liba_depend.sl instead of in libb_depend.sl. If I switch the order in which I load liba.sl and libb.sl, then I can control which dependent library is used to resolve symbols in both liba.sl and libb.sl. But I cannot achieve the desired behavior of each libX.sl resolving symbols in libX_depend.sl. I see that there may be shl_load flags that could alter the behavior but these are probably irrelevant because the real problem exists for me with Java's loadLibrary(), where I cannot control the flags passed, presumably to shl_load.

[ranganath ramachandra · Accepted solution]

the linker's '-B group' option should solve your problem. but currently this functionality is available only on PA64, but coming soon on PA32. for PA32, direct binding is one way to achieve this.

ld -B direct -o libb.sl libb_depend.sl b.o ...

you need the latest linker/loader patches in both the development and runtime environments. PHSS_30965 (11.00) and PHSS_30966 (11.11) will be out tomorrow or so.

[Mike Stroyan]

Here is another approach that can be used with the tools available for 32-bit processes. You could use wrapper shared libraries with init functions that actually call dlopen with RTLD_LOCAL to bring in liba.sl and liba_depend.sl or libb.sl and libb_depend.sl. That would keep the symbols hidden from normal relocation. The wrappers could use dlsym with a dlopen handle to find the symbols you really want out of those shared libraries.