Problems regarding symbol scoping from shared libraries.

[Paresh Borkar]

Hi,

We are trying to port our application to hp-ux11 (32-bit) from Sun solaris. The application is written in C++ and we are building with aCC on hp-ux (on solaris, we build using g++). Following are two problems we are facing:

(1) Regarding symbol scope:
On hp-ux the shl_load call by default loads a module in the global scope. This call of shl_load does not offer any flags which can be used to load a module with symbols in local scope (similar to the RTLD_LOCAL flag for dlopen() on solaris). We have two archives (say archive1 and archive2) which have the same functions/classes but are different
versions (i.e. different implementations). We have two shared libraries (say sl1 and sl2). The shared library sl1 links with archive1 and sl2 links with archive2. Both these shared libraries are loaded by the webserver (iPlanet or Apache). Function calls from one shared library (say sl1) to functions in it's archive (archive1) are executing same function from other archive (archive2) instead.

We had faced a similar problem about symbol scoping for apache on solaris, which we resolved by loading the libraries at local scope (using RTLD_LOCAL).

We have tried the following options on hp-ux so far, without any success:
1. Link the shared libraries with '-B symbolic' option to resolve call paths internally.
2. Export only selected functions from the shared libraries using the '+e symbol' option, to ensure that the other symbols become local scope.

(2) Regarding multiple copies of archive files containing static data:
We build an archive file containing some static global data (primitive types like pointers or bool). This archive file is linked in to multiple shared libraries that we create. All these shared libraries get loaded
(dynamically) by our own application server.

My question is, will each shared library maintain/have a private copy of the static global data from the archive or will there exist a single copy of global static data in the server.

Currently with the test driver that we have tried, looks like only one copy of the global static data from the archive is being maintained in the server.

Any help regarding the above two problems will be appreciated.

Thanks,
Paresh.

[Mike Stroyan]

The most straightforward approach is to require patch PHSS_24303 or one of its successors. The current dld.sl from that patch provides dlopen and the RTLD_LOCAL feature for 32-bit executable. (It was there in /usr/lib/pa20_64/libdl.sl from the start of 11.0 for 64-bit executables.)
I have attached an example that demonstrates that symbols
are local to the shared libraries.

[Paresh Borkar]

Hi Mike,

Thanks a lot for the help.

We tried to download the patch you mentioned, but found that it is not the relevant patch. Was there a typo in the patch number?

Anyways, we downloaded patch number (PHSS_23440) which is "s700_800 11.00 ld(1) and linker tools cumulative patch". After installing this patch, we tried the your sample application. It runs fine. The next thing we tried is as follows: We created a small main2.cpp as shown below:
/* start main2.cpp*/
#include

extern "C" void a(void);

int main(int argc, char *argv[])
{
a();
return 0;
}
/* end main2.cpp */

We built liba.sl and libb.sl using your makefile.
Then we tried the following two things:
1. Implicitly linked main2.cpp with both the shared libraries by
aCC +z main2.cpp -L`pwd` -la -lb

The output from a.out was:

constructing A to 9 at 0x7afe8078
constructing A to 7 at 0x7afe8078
constructing A to 7 at 0x7b0407b8
in a calling common_name()

in common_name from a
a sees global.i=7, local.i=7

2. Then we changed the order of the libraries on command line as:
aCC +z main2.cpp -L`pwd` -lb -la

The output from a.out was:

constructing A to 7 at 0x7afe8078
constructing A to 9 at 0x7afe8078
constructing A to 7 at 0x7b0407b8
in a calling common_name()

in common_name from b
a sees global.i=9, local.i=7

Points from the outputs:
(a) The same address is getting used for the global data from both libraries (i.e. 0x7afe8078). And the same is being over written in the second constructor call.
(b) The function common_name is called from the first -lLibrary that we link with on the command line.

What this shows is that for implicitly linked libraries (i.e. with -lLibrary), those are loaded by the run-time linker at global scope.
Is this correct or are we missing something over here?

In our project we have a whole bunch of shared libraries, that we link implicitly with (using -lLibrary option). And we would like these to be loaded at local scope. Is there some way to achieve this?

Thanks once again.

Regards,
Paresh.

[Mike Stroyan]

Patch PHSS_24303 will be the successor to PHSS_23440. I forgot that it still hadn't been released.
I don't know of any link directive that will produce the same binding effects as RTLD_LOCAL. The one approach that will make symbols local regardless of loading style is to hide symbols before the shared library is created.
The attached example uses ld with -r and -h to create one .o from all the .o files that will go into a shared library.
Hiding "global" and "common_name" at that time makes them really local to the single .o and to the shared library.

[Jon Press]

I am having a similar but different problem. I have a C++ shared library that I dynamically load (using shl_load()) for which "-B symbolic" ought to be the correct solution, based on my experience on other platforms. However, I found from experience and from other research on the web that shared libraries that are loaded with shl_load() must be linked with aCC, not ld, or else their constructors will not be called. But aCC does not have "-B symbolic" or any other switcht that looks equivalent. Any ideas?

[Paresh Borkar]

You are right, shared libraries and executables must be linked with aCC command.
Here is the excerpt from the "HP-UX Linker and Libraries User's Guide" document.


If you are linking any C++ object files to create an executable or a shared library, you must use the CC command to link. This ensures that c++patch executes and chains together your nonlocal static constructors and destructors. If you use ld, the library or executable may not work correctly and you may not get any error messages.


Refer to
http://docs.hp.com/cgi-bin/onlinedocs.py?mpn=B2355-90655&service=hpux&path=../B2355-90655/00/00/18&title=HP-UX%20Linker%20and%20Libraries%20User%27s%20Guide

To pass the '-B,symbolic' option to the linker from aCC use '-Wl' option. You need to pass '-Wl,-B,symbolic' to aCC. Refer to documentation on the '-W' compiler option.

hope this helps.