What I’d like to see is the output of the following commands:
ls -l /lib64/libpthread.so.0
ls -l /lib64/tls/libpthread.so.0
-rwxr-xr-x 1 root root 95509 2004-11-05 11:05 /lib64/libpthread.so.0
-rwxr-xr-x 1 root root 99188 2004-11-05 11:17 /lib64/tls/libpthread.so.0
pgcc test.c -v -lpthread -o test.pgi
/opt/pgi/linux86-64/6.0/bin/pgc test.c -opt 1 -x 119 0xa10000 -x 122 0x40 -x 123 0x1000 -x 127 4 -x 19 0x400000 -quad -x 120 0x80000000 -x 59 4 -y 80 0x1000 -x 80 0x10800000 -astype 0 -stdinc /opt/pgi/linux86-64/6.0/include:/usr/local/include:/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/include:/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/include:/usr/include -def unix -def __unix -def __unix__ -def linux -def __linux -def __linux__ -def __inline__= -def __NO_INLINE__ -def __NO_MATH_INLINES -def __x86_64__ -def __LONG_MAX__=9223372036854775807L -def '__SIZE_TYPE__=unsigned long int' -def '__PTRDIFF_TYPE__=long int' -def __THROW= -def __amd64__ -predicate '#machine(x86_64) #lint(off) #system(posix) #cpu(x86_64)' -cmdline '+pgcc test.c -v -lpthread -o test.pgi' -asm /tmp/pgccaaaaawsbat.s
PGC-I-0222-Redundant definition for symbol __THROW (/usr/include/sys/cdefs.h: 57)
PGC-W-0118-Function print_message_function does not contain a return statement (test.c: 37)
PGC/x86-64 Linux/x86-64 6.0-2: compilation completed with warnings
/usr/bin/as /tmp/pgccaaaaawsbat.s -o /tmp/pgccbaaaawsbau.o
/usr/bin/ld /usr/lib64/crt1.o /usr/lib64/crti.o /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/crtbegin.o -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /tmp/pgccbaaaawsbau.o -o test.pgi -L/opt/pgi/linux86-64/6.0/lib -L/usr/lib64 -L/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3 -rpath /opt/pgi/linux86-64/6.0/lib -lpthread -lc -lnspgc -lpgc -lm -lgcc -lc -lgcc /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/crtend.o /usr/lib64/crtn.o
Unlinking /tmp/pgccaaaaawsbat.s
Unlinking /tmp/pgccbaaaawsbau.o
echo $LD_LIBRARY_PATH
This is actually null; however, I have the following in my ld.so.conf:
/opt/pgi/linux86-64/6.0/lib
/opt/pgi/linux86-64/6.0/libso
ldd test.pgi
libpthread.so.0 => /opt/pgi/linux86-64/6.0/lib/libpthread.so.0 (0x0000002a9566d000)
libc.so.6 => /lib64/tls/libc.so.6 (0x0000002a9581f000)
libm.so.6 => /lib64/tls/libm.so.6 (0x0000002a95a41000)
/lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x0000002a95556000)
test.pgi
./test.pgi: relocation error: /opt/pgi/linux86-64/6.0/lib/libpthread.so.0: symbol _h_errno, version GLIBC_2.2.5 not defined in file libc.so.6 with link time reference
Also, have you made any changes to your system that might have changed these libraries?
Only if using the YAST updater counts as changes to the system. I actually do all of my development from within a chrooted environment. In this way, I can ensure that I’m not actually making any changes to the ‘real’ system’s software/libraries. (And I frequently just rsync the ‘real’ system → the ‘chroot’ to back out any changes made to the chroot). It’s a fairly nice setup that lets me have the ‘real’ system completely clean – nothing that is not installed from SLES9 RPM’s (ie. using its updater/installer) is on the ‘real’ system. I go to great lenghts to make sure the ‘real’ system is clean.
I’ve actually ran the test.c compile from the ‘real’ system just to ensure that everything listed above are identical to the results from within the ‘chroot’ – they are.
I’ve also done a query of the RPM database to see if anything touches the libc libraries. I’ve even re-installed them, overwriting what was there. No difference.
I’ve removed entries from ld.so.conf that relate to other non-gcc non-pgi compilers, just in case there may be some sort of conflict. Again, it makes no difference in PGI’s behavior.