algorithms. For any standard mode library, it uses the IPF/PA-64-style algorithms. Only the load order of the libraries themselves is fixed between depth-first or breadth-first.

If you use mixed mode shared libraries, the behavior is based on the first mode encountered. At runtime, the dynamic loader does a depth-first search if the dependent libraries at the highest level are compatibility mode libraries. Otherwise, it does breadth-first searching. This applies to all dependent libraries of the incomplete executable file. The loader cannot toggle back and forth between depth-first and breadth-first at the library level, so the first dependent library it sees determines which search method to use. Example:

#build standard mode dlls

#libfile1.so is a dependent of libfile2.so

$ ld -b file1.o -o libfile1.so +h libfile1.1

$ ld -b file2.o -o libfile2.so +h libfile2.1 -L. -lfile1

#build compatibility mode dlls

#libfile3.so is a dependent of libfile4.so

$ ld -b file3.o -o libfile3.so +h libfile3.1

$ ld -b file4.o -o libfile4.so +h libfile4.1 -L. -lfile3 +compat $ ln -s libfile1.so libfile1.1

$ ln -s libfile3.so libfile3.1

#build a dll using both standard and compatibility mode dependent dlls

#since we didn't specify +compat, the resulting dll is a standard mode dll

$ ld -b file5.o -o libfile5.so +h libfile5.1 -L. -lfile4 -lfile2 $ ln -s libfile4.so libfile4.1

$ ln -s libfile2.so libfile2.1 $ ld main.o -L. -lfile5 -lc

The resulting a.out has standard mode dependents, libfile5.so and libc.so. libfile5.so have two dependents,: libfile4.so and libfile2.so. Thelibfile4.so library is a compatibility mode library, and has a dependent, libfile3.so. libfile2.so is a standard mode library, and has a dependent, libfile1.so. The dynamic loader does a breadth-first search of all dependent libraries needed by a.out because the link was done without +compat and libfile5.so is a standard mode library. The loader uses IPF/PA-64 search techniques on all libraries except for libfile3.so, in which case it uses PA-32 search techniques.

NOTE: Embedded path inheritance is not applied to any mixed mode shared library and its descendents. It is only applied to libraries in an a.out linked with +compat. Embedded path inheritance does not apply to a breadth-first search mechanism.

IPF Library Examples

The examples demonstrate the behavior of compatibility and standard mode shared libraries created by the IPF linker toolset:

Library Example: Creating an IPF Compatibility Mode Shared Library

The following example creates a compatibility mode shared library:

$ ld -b file1.o -o libfile1.so +h libfile1.1

$

ld -b file2.o

-o libfile2.so +h ./libfile2.1

$

ld -b file3.o

-o libfile3.so +h /var/tmp/libfile3.1

$

ld -b file4.o

-o libfile4.so

$

ld -b +compat

file3a.o -o libfile3a.so -L. -lfile -lfile3 +h libfile3a.1

$

ld -b +compat

file2a.o -o libfile2a.so libfile2.so ./libfile4.so +b /var/tmp

$

elfdump -L libfile3a.so libfile2a.so

libfile3a.so:

 

*** Dynamic Section ***

Index

Tag

Value

0

 

HPNeeded

1:./libfile1.1

1

 

HPNeeded

1:/var/tmp/libfile3.1

2

 

Soname

libfile3a.1

Using Shared Libraries in Default Mode 131

Page 131
Image 131
HP UX Software Transition Kit (STK) manual IPF Library Examples, Libfile4.so