Operating System - Linux
1748211 Members
4943 Online
108759 Solutions
New Discussion юеВ

Cannot load module '/usr/lib/hpux32/libpthread.so.1' because it contains thread specific data

 
SOLVED
Go to solution
Srinivas Cheruku
New Member

Cannot load module '/usr/lib/hpux32/libpthread.so.1' because it contains thread specific data

Hi,

We have a problem with a shared library, and threaded local storage - can anybody help ? We have reviewed other messages in this forum which are also related to TLS, but none of them seem to help us fix the problem.

Here are the details :

There is a binary called client, and one called server. These communicate with each other via IP, and are designed to test the libraries we are having problems with.

When we run server and client programs we see error in syslog :

"unable to dlopen /krb5/ext/lib/libgssapiv2.sl: Cannot dlopen load module '/usr/lib/hpux32/libpthread.so.1' because it contains thread specific data."

The client and server programs are linked with a shared library called libsasl2.sl, which then uses shl_load to load libgssapiv2.sl, which depends on libgss.sl and other libraries.

When we run the server program with truss, the libgssapiv2.sl, libgss.sl and libc.so.1 libraries are opened and then the above mentioned error occurs. Please find below the truss output when server is run:

open("/krb5/ext/lib/libgssapiv2.sl", O_RDONLY, 0) = 4
...
open("/krb5/appsec-rt/lib/libgss.sl", O_RDONLY, 0) = 4
...
open("/usr/lib/hpux32/libc.so.1", O_RDONLY, 0) = 4
...
open("/usr/lib/hpux32/libpthread.so.1", O_RDONLY, 0) = 4
...
unable to dlopen /krb5/ext/lib/libgssapiv2.sl: Cannot dlopen load module '/usr/lib/hpux32/libpthread.so.1' because it contains thread specific data.

libgssapiv2.sl and libgss.sl are dependent on /usr/lib/hpux32/libpthread.so.1. Please find below the ldd output:

$ ldd /krb5/ext/lib/libgssapiv2.sl
libgss.sl => /krb5/appsec-rt/lib/libgss.sl
libc.so.1 => /usr/lib/hpux32/libc.so.1
libpthread.so.1 => /usr/lib/hpux32/libpthread.so.1
libdl.so.1 => /usr/lib/hpux32/libdl.so.1
libcstbk5.sl => /krb5/lib/libcstbk5.sl
libm.so.1 => /usr/lib/hpux32/libm.so.1
libsec.so.1 => /usr/lib/hpux32/libsec.so.1
libexpat.sl => /krb5/lib/libexpat.sl
libdl.so.1 => /usr/lib/hpux32/libdl.so.1
libdl.so.1 => /usr/lib/hpux32/libdl.so.1
libm.so.1 => /usr/lib/hpux32/libm.so.1
libm.so.1 => /usr/lib/hpux32/libm.so.1
$
$ ldd /krb5/appsec-rt/lib/libgss.sl
libpthread.so.1 => /usr/lib/hpux32/libpthread.so.1
libdl.so.1 => /usr/lib/hpux32/libdl.so.1
libcstbk5.sl => /krb5/lib/libcstbk5.sl
libm.so.1 => /usr/lib/hpux32/libm.so.1
libsec.so.1 => /usr/lib/hpux32/libsec.so.1
libexpat.sl => /krb5/lib/libexpat.sl
libm.so.1 => /usr/lib/hpux32/libm.so.1
libm.so.1 => /usr/lib/hpux32/libm.so.1
$

As mentioned in other forum posts, use of LD_PRELOAD is a way to fix this, but we find this removes the error seen in syslog, but gives us a different error.

LD_PRELOAD=/usr/lib/hpux32/libpthread.so.1; export LD_PRELOAD

truss output:
open("/krb5/ext/lib/libgssapiv2.sl", O_RDONLY, 0) = 4
...
open("/krb5/appsec-rt/lib/libgss.sl", O_RDONLY, 0) = 4
...
open("/usr/lib/hpux32/libc.so.1", O_RDONLY, 0) = 4
...
open("/usr/lib/hpux32/libpthread.so.1", O_RDONLY, 0) = 4
...
open("/usr/lib/hpux32/libdl.so.1", O_RDONLY, 0) = 4
...
open("/krb5/lib/libcstbk5.sl", O_RDONLY, 0) = 4
...
open("/usr/lib/hpux32/libm.so.1", O_RDONLY, 0) = 4
...
open("/usr/lib/hpux32/libsec.so.1", O_RDONLY, 0) = 4
...
open("/krb5/lib/libexpat.sl", O_RDONLY, 0) = 4
...
open("/usr/lib/hpux32/libpthread.so.1", O_RDONLY, 0) = 4
...
open("/usr/lib/hpux32/libdl.so.1", O_RDONLY, 0) = 4
...
open("/usr/lib/hpux32/libm.so.1", O_RDONLY, 0) = 4
...
open("/usr/lib/hpux32/libdl.so.1", O_RDONLY, 0) = 4
...
open("/usr/lib/hpux32/libm.so.1", O_RDONLY, 0) = 4
...
unable to dlopen /krb5/ext/lib/libgssapiv2.sl: Unsatisfied data symbol 'GSS_C_NT_USER_NAME' in load module '/krb5/ext/lib/libgssapiv2.sl'.

We have tried on HP-UX (B.11.23 U IA64) and also on HP-UX (B.11.11 PARISC) and observed the same error for 32-bit compilation. We haven't tested 64-bit yet, because we want to make 32-bit code work first.

I would very much appreciate if anyonce can help me to solve this issue.

Thanks,
Srini
6 REPLIES 6
Dennis Handly
Acclaimed Contributor
Solution

Re: Cannot load module '/usr/lib/hpux32/libpthread.so.1' because it contains thread specific data

The only solution is to use LD_PRELOAD=.../libpthread as you mentioned. Or you must link your application with libpthread.

The error with GSS_C_NT_USER_NAME is probably there in both cases, you are just getting past the TLS error. You need to find where GSS_C_NT_USER_NAME is defined.

Note adding libpthread to your application will require compiling C++ sources with -mt.
Tim Alsop
Advisor

Re: Cannot load module '/usr/lib/hpux32/libpthread.so.1' because it contains thread specific data

Dennis,

I am replying on behalf of Srini, who is working with me on this issue.

We tried with LD_PRELOAD and the TLS error goes away - instead we are getting the following error when running the server binary :

# ./server -m GSSAPI
/usr/lib/dld.sl: Unresolved symbol: GSS_C_NT_HOSTBASED_SERVICE (data) from /krb5/ext/lib/libgssapiv2.sl
/usr/lib/dld.sl: Unresolved symbol: GSS_C_NT_USER_NAME (data) from /krb5/ext/lib/libgssapiv2.sl
/usr/lib/dld.sl: Unresolved module for symbol: gssapiv2_server_plug_init (code) from /krb5/ext/lib/libgssapiv2.sl
Abort(coredump)
#

We know where these symbols are defined (in libgss.sl), but don't understand why they are not available. It seems that the symbol table is not available to libraries that are loading this library.

Also, it is worth noting that this code is working perfectly on Solaris, AIX, Linux etc. but we cannot make it work on HP/UX. We think this is because on HP/UX we have to use -ldld when linking, and shl_load() instead of dlopen() to load libraries.

Can you explain what you mean by the -mt in relation to the libpthread library ?

Thanks,
Tim
Dennis Handly
Acclaimed Contributor

Re: Cannot load module '/usr/lib/hpux32/libpthread.so.1' because it contains thread specific data

>instead we are getting the following error when running the server binary :
dld.sl: Unresolved: GSS_C_NT_HOSTBASED_SERVICE (data) .../libgssapiv2.sl
dld.sl: Unresolved: GSS_C_NT_USER_NAME (data)
dld.sl: Unresolved module for symbol: gssapiv2_server_plug_init (code)

This is your real error. You only imagined the TLS one. ;-)

>We know where these symbols are defined (in libgss.sl), ... It seems that the symbol table is not available to libraries that are loading this library.

Does /usr/ccs/bin/odump -slexport libgss.sl show all 3 symbols above?

(I think "Unresolved module" is the reason the module was loaded that needed the other 2 unsat symbols.)

>We think this is because on HP-UX we have to use -ldld when linking, and shl_load() instead of dlopen() to load libraries.

I'm not sure that would make a difference but you can use dlopen.

>Can you explain what you mean by the -mt in relation to the libpthread library?

If your application is aC++, you can't link with libpthread without compiling with -mt. Otherwise you get all sorts of errors with strings and iostreams.
Tim Alsop
Advisor

Re: Cannot load module '/usr/lib/hpux32/libpthread.so.1' because it contains thread specific data

Yes, I think you are correct - the 'real' problem is related to symbols, not TLS. The TLS problem just got in the way :-)

One of the symbols mentioned is in libgssapiv2.sl - see below :

# /usr/ccs/bin/odump -slexport /krb5/ext/lib/libgssapiv2.sl |grep gssapiv2_server
000000006 000000001 00000 0x00005818 Code 000000,155 00 gssapiv2_server_plug_init
#

When I tried odump with libgss.sl the other two symbols were not shown, so I guess this is why it is complaining...

We previously tried dlopen() to load the shared library, and found this gave us threaded local storage errors, so we changed to using shl_load() and the errors went away. I just changed the code to use dlopen() again and didn't get same results as before, so we need to look into this some more.

Thanks for explaining the -mt. Our code is C, not C++ so we have just used -lpthread and this does not give lots of errors.

I will work with Srini on Monday and let you know how we get on with this, but thank you so far for your help.
Tim Alsop
Advisor

Re: Cannot load module '/usr/lib/hpux32/libpthread.so.1' because it contains thread specific data

Dennis,

We have fixed this problem. We found, when we compiled libgssapiv2.sl that the wrong header file was being used, and the header didn't contain the symbols required at runtime.

It was your suggestion to use odump to check the symbols that pointed us in this direction, so I would like to thankyou for your help.

We can close this now.

Regards,
Tim
Srinivas Cheruku
New Member

Re: Cannot load module '/usr/lib/hpux32/libpthread.so.1' because it contains thread specific data

The only solution is to use LD_PRELOAD=.../libpthread as you mentioned. Or you must link your application with libpthread.

The error with GSS_C_NT_USER_NAME is probably there in both cases, you are just getting past the TLS error. You need to find where GSS_C_NT_USER_NAME is defined.

>instead we are getting the following error when running the server binary :
dld.sl: Unresolved: GSS_C_NT_HOSTBASED_SERVICE (data) .../libgssapiv2.sl
dld.sl: Unresolved: GSS_C_NT_USER_NAME (data)
dld.sl: Unresolved module for symbol: gssapiv2_server_plug_init (code)

This is your real error. You only imagined the TLS one. ;-)

>We know where these symbols are defined (in libgss.sl), ... It seems that the symbol table is not available to libraries that are loading this library.

Does /usr/ccs/bin/odump -slexport libgss.sl show all 3 symbols above?

(I think "Unresolved module" is the reason the module was loaded that needed the other 2 unsat symbols.)