Wrong glibc with pgf90 6.1 compiler

I get this error when I run a code that was compiled with 6.1-5 on an Opteron cluster:

/home/a13890/TEACC_w_Overflow/Run_overflow/overflow_TEACC: /opt/pgi/linux86-64/6.1/lib/libpthread.so.0: version `GLIBC_2.3.3’ not found (required by /lib64/tls/librt.so.1)

What’s the correct way to install glibc 2.3.3? We also have users that are compiling with 5.2

Thanks,

Bill

[root@opie Run_overflow]# ldd -v /lib64/tls/librt.so.1
libc.so.6 => /lib64/tls/libc.so.6 (0x0000002a95794000)
libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x0000002a959d8000)
/lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x0000002a95670000)

Version information:
/lib64/tls/librt.so.1:
ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2
libpthread.so.0 (GLIBC_2.3.3) => /lib64/tls/libpthread.so.0
libpthread.so.0 (GLIBC_2.2.5) => /lib64/tls/libpthread.so.0
libpthread.so.0 (GLIBC_PRIVATE) => /lib64/tls/libpthread.so.0
libc.so.6 (GLIBC_2.3.2) => /lib64/tls/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib64/tls/libc.so.6
libc.so.6 (GLIBC_PRIVATE) => /lib64/tls/libc.so.6
/lib64/tls/libc.so.6:
ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
ld-linux-x86-64.so.2 (GLIBC_2.2.5) => /lib64/ld-linux-x86-64.so.2
ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2
/lib64/tls/libpthread.so.0:
ld-linux-x86-64.so.2 (GLIBC_2.2.5) => /lib64/ld-linux-x86-64.so.2
ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2
libc.so.6 (GLIBC_2.3.2) => /lib64/tls/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib64/tls/libc.so.6
libc.so.6 (GLIBC_PRIVATE) => /lib64/tls/libc.so.6

Hi Bill,

Another user had a similar problem (See HERE), where a ‘libpthread.so’ symlink was added to the PGI lib directory which pointed to ‘libpgthread.so’. On all systems except Red Hat 7.3, ‘libpgthread.so’ is simply a link to ‘/lib[64]/libpthread.so’, which in this case was the wrong pthread library. To correct, the user reset the ‘libpgthread.so’ link to ‘/lib[64]/tls/libpthread.so’

I suspect you have a similar problem where the loader is picking up the non-TLS version of libpthread.so. Besides redirecting the /opt/pgi/linux86-64/6.1/lib/libpgthread.so link as the previous user had done, I think if you set your LD_LIBRARY_PATH to first include “/lib64/tls”, then it should work as well.

export LD_LIBRARY_PATH=/lib64/tls:/opt/pgi/linux86-64/6.1/lib

Hope this helps,
Mat

This worked:

setenv LD_LIBRARY_PATH /lib64/tls
setenv LD_PRELOAD /lib64/tls/libpthread.so.0

Thanks,

Bill

I’m having this same problem with shared libraries on a Rocks cluster. The code needs to load the pthread library in /lib64/tls, but it’s getting the one in /opt/pgi/linux86-64/6.1/lib.

62> mpirun -np 10 -machinefile nodes_10 ./ns

/home/a19262/GEMS/RUNS/T2356/./ns: /opt/pgi/linux86-64/6.1/lib/libpthread.so.0: version `GLIBC_2.3.3’ not found (required by /lib64/tls/librt.so.1)

63> ldd ns

/lib64/tls/libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x0000002a9566d000)

librt.so.1 => /lib64/tls/librt.so.1 (0x0000002a95781000)
libc.so.6 => /lib64/tls/libc.so.6 (0x0000002a9589c000)
libm.so.6 => /lib64/tls/libm.so.6 (0x0000002a95ae0000)
/lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x0000002a95556000)

The fix that worked on the HP XC cluster using the ld environment variables isn’t working on the Rocks cluster:

64> env |grep LD_

LD_LIBRARY_PATH=/lib64/tls
LD_PRELOAD=/lib64/tls/libpthread.so.0

I think the loader is correctly picking up the environment variables.

Thanks,

Bill

Hi Bill,

Are the environment variables being set for each node? Typically, you need to set these variables in your default evironment (i.e. “.cshrc” file) or wrap your exe in a script which first sets your environment before invoking the application.

  • Mat