pthread_stubs.5 (2010 09)

pthread_stubs(5) pthread_stubs(5)

$ cc +DA2.0W thread.c -L. -l1 -l2

$ a.out

Error

$ ldd a.out

lib1.sl => ./lib1.sl

lib2.sl => ./lib2.sl

libc.2 => /usr/lib/pa20_64/libc.2

libpthread.1 => /lib/pa20_64/libpthread.1

libdl.1 => /usr/lib/pa20_64/libdl.1

$ LD_PRELOAD="/lib/pa20_64/libpthread.1" a.out

Success

a.out correctly lists -lpthread for a threaded application.

$ ld -b -o lib1.sl lib1.o

$ ld -b -o lib2.sl -lpthread lib2.o

$ cc +DA2.0W thread.c -L. -l1 -l2 -lpthread

$ a.out

Success

$ ldd a.out

lib1.sl => ./lib1.sl

lib2.sl => ./lib2.sl

libpthread.1 => /usr/lib/pa20_64/libpthread.1

libc.2 => /usr/lib/pa20_64/libc.2

libpthread.1 => /lib/pa20_64/libpthread.1

libdl.1 => /usr/lib/pa20_64/libdl.1

Example 4 (archived libc)

If the link line of your shared library contains

-lc to explicitly link in libc, remove

-lc.Otherwise,

shared libraries may be referencing

libc.2 while the a.out may refer to older (archived) libc ver-

sion. Thus the application will actually be using two different versions of libc and possibly mixing the

code. This may cause compatibility problems. Basically, an application or library should never directly

link against libc. All programs need to be linked against libc (which the compiler does automati-

cally), so a shared library will always have the interfaces it needs to execute properly without needing to

specify -lc on the link line.