HP UX Software Transition Kit (STK) manual Out -- libA.sl -- libC.sl -- libD.sl -- libB.sl

$ export LD_PRELOAD="./libB.sl"

$ ldd a.out
./libB.sl =>		./libB.sl
./libB.sl =>		./libB.sl
libA.sl	=>	./libA.sl
libB.sl	=>	./libB.sl
libc.2 =>		/usr/lib/pa20_64/libc.2
libC.sl	=>	./libC.sl
libD.sl	=	./libD.sl
libdl.1	=>	/usr/lib/pa20_64/libdl.1

a.out --> libD.sl --> libA.sl --> libB.sl --> libC.sl

Case (ii): LD_PRELOAD = "./libD.sl" In 64-bit mode, the symbol resolution order is:

$ export LD_PRELOAD="./libD.sl"

$ ldd a.out
./libD.sl =>	./libD.sl
./libD.sl =>	./libD.sl
libA.sl =>	./libA.sl
libB.sl =>	./libB.sl
libc.2 =>	/usr/lib/pa20_64/libc.2
libC.sl =>	./libC.sl
libD.sl =>	./libD.sl
libdl.1 =>	/usr/lib/pa20_64/libdl.1

a.out --> libD.sl --> libA.sl --> libB.sl- -> libC.sl

If the same symbol is defined in libA.sl and libD.sl, the 64-bit linker toolset uses the symbol defined in libD.sl because this library is loaded and searched before libA.sl when LD_PRELOAD="./libD.sl".

32-bit Behavior

With LD_PRELOAD unset, in 32-bit mode the dynamic loader forms a load graph as follows:

1.mark B, load B

2.mark A,

3.traverse D, load D

4.load C

5.load A

With this load graph, the symbol resolution order is built in reverse order in 32-bit mode:

a.out --> libA.sl --> libC.sl --> libD.sl --> libB.sl

Case (i): LD_PRELOAD="./libB.sl"

In 32-bit mode, the dependents of a.out are treated as: libB.sl, libA.sl, libB.sl. The second libB.sl is ignored by the dynamic loader, because it is a duplicate library. So, the effective dependents of a.out are treated as: libB.sl, libA.sl. The load graph is:

1.mark A, traverse D,load D

2.load C

3.load A

4.load B

The symbol resolution order is:

a.out --> libB.sl--> libA.sl --> libC.sl --> libD.sl

Case (ii): LD_PRELOAD = "./libD.sl" In 32-bit mode, the load graph is:

1.mark B, load B

2.mark A, traverse D, load D

3.load C

4.load A

Creating Shared Libraries 105