Re: controlling scope of symbols in shared libraries (342 Views)
Reply
Occasional Visitor
Michael Shifflett
Posts: 2
Registered: ‎07-13-2004
Message 1 of 4 (342 Views)
Accepted Solution

controlling scope of symbols in shared libraries

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
Occasional Visitor
Michael Shifflett
Posts: 2
Registered: ‎07-13-2004
Message 2 of 4 (342 Views)

Re: controlling scope of symbols in shared libraries

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.
Esteemed Contributor
ranganath ramachandra
Posts: 375
Registered: ‎05-16-2003
Message 3 of 4 (342 Views)

Re: controlling scope of symbols in shared libraries

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.
Honored Contributor
Mike Stroyan
Posts: 888
Registered: ‎11-22-1996
Message 4 of 4 (342 Views)

Re: controlling scope of symbols in shared libraries

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.
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.