$ test3
object is 1
The PA-32 linker toolset defines the object global variable in libA.so as a storage export symbol. The dynamic loader, when searching for a definition of object to satisfy the import request in libA.so, does not stop with the storage export in that library. It continues to see if there is a data export symbol for the same symbol definition.
The IPF linker and PA-64 toolset produces:
$ test 3
object is 0
The IPF and PA-64 linker toolset does not allow storage exports from a shared library. The uninitialized variable called object in a.o turns into a data export in libA.so, with an initial value of 0. During symbol resolution for the import request from that same library, the dynamic loader stops with the first seen definition.
Symbol Searching in Dependent Libraries
In the IPF and PA-64 linker toolset, the linker searches dependent libraries in a breadth-first order for symbol resolution. This means it searches libraries linked to the main program file before libraries linked to shared libraries. This behavior change is consistent with other SVR4 systems. The linker also searches siblings of a dependent shared library before its children. For example, using the structure described in Figure 30 (page 130), if libD had dependent libraries libDK and libLH, libD, libE, libF, then libDK, libLH is searched in that order. The dlopen library management routines and executable files (a.out) created by the linker with the +std option (default) use the breadth-first search order.
The PA-32 linker toolset searches dependent libraries in a depth-first order. This means it searches dependent shared library files in the order in which they are linked to shared libraries. The shl_load library management routines and executable files (a.out) created by the linker with the +compat option use the depth-first search order.
NOTE: If you have data or function names that are duplicated in different shared libraries, the IPF and PA-64 linker may link in a different version of a procedure than the current release. This can lead to unexpected results.
Figure 30 (page 130) shows an example program with shared libraries (the shaded boxes are libA.so dependent libraries; and the example does not consider libDK or libLH) and compares the two search methods:
Using Shared Libraries in Default Mode 129