void afunc()

{

printf ("\tin ARCHIVE library procedure 'afunc'\n");

}

main.c

main()

{

bfunc();

}

If these files are compiled and linked as:

$ cc -c main.c unsat.c archive.c $ cc -c +z sharedlib.c

$ ld -b sharedlib.o -o libA.so $ ar rv libB.a archive.o

$ cc main.o libA.so unsat.o libB.a -o test1

The PA-32 linker toolset produces:

$ test1

in ARCHIVE library procedure `afunc'

At link time, there is an outstanding unsatisfied symbol for afunc() when libB is found. The exported symbol for afunc() is not remembered after libA.so is scanned. At run time, the afunc() symbol that is called is the one that came from the archive library, which resides in test1. The IPF and PA-64 linker toolset produces:

$ test1

in SHARED library procedure `afunc'

The IPF and PA-64 linker remembers the symbol for afunc(), and archive.o is not pulled out of libB.a. The shared library version of afunc is called during execution. This behavior is consistent with other SVR4 systems.

Resolution of Unsatisfied Shared Library References

In the IPF and PA-64 linker toolset, the dynamic loader requires that all symbols referenced by all loaded libraries be satisfied at the appropriate time. This is consistent with other SVR4 systems.

The PA-32 linker toolset accepts unresolved symbols in some cases. For example, if an entry point defined in an object file is never reachable from the main program file, the unresolved symbol is allowed. You can use the +vshlibunsats linker option to find unresolved symbols in shared libraries.

For example, given these source files:

lib1.c

void a()

{

}

lib2.c

extern int unsat; void b()

{

unsat = 14;

}

Using Shared Libraries in Default Mode 127