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

Question

I get this error while loading a lib with dlopen():

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

I looked this up on google and the following export fixed it.

export LD_PRELOAD=/usr/lib/hpux64/libpthread.so.1

Can anybody tell me what exactly LD_PRELOAD does and why I have to preload this lib? Why does the linker not load it?

Compiling with -lpthread does not help either.

ENV: HP-UX hhtenb1 B.11.31 U ia64 3881169896 unlimited-user license

score 0 · Accepted Answer · answered Nov 10 '10 at 08:47

0

I can't tell you all the details on HPUX, but try linking your program with -lpthread - that may solve your problem.

As is, the library you're dlopen()ing seems to be digging around at run-time to find a version of libpthread. LD_PRELOAD just loads the specified library as if you'd dlopened them, but it does it before the program has a chance to start running.

Not sure of details, but a vague guess: some library you're using has called the pthread static data functions before your dlopen triggers a load of libpthread (but why would it try to load pthread then if the first library had it as a dependency? - not sure / maybe that indicates the former library statically linked some pthread content?).

answered Nov 10 '10 at 08:47

Tony Delroy

102,968
15
177
252

Tony I already tried that. It has no affect. I get the same error. – rahul Nov 11 '10 at 04:50
@rahul: Perhaps it's finding the '/usr/lib/pa20_64/libpthread.1' version that it complains about at run-time. Try specifying `-L/usr/lib/hpux64 -lpthread`. Check with ldd which version your binary will load, or with pldd (or HPUX's equivalent) to see which version a running process has loaded. – Tony Delroy Nov 11 '10 at 04:56

score -1 · Answer 2 · edited Jun 27 '13 at 15:06

We had this error below on hpux-11.31 IA64 running DB2-10.1.2 and doing the

    "export LD_PRELOAD=/usr/lib/hpux64/libpthread.so.1"

fixed it.

DATA #2 : String, 49 bytes
/home/db2inst1/sqllib/lib64/icc/libgsk8iccs_64.so
CALLSTCK: (Static functions may not be resolved correctly, as they are resolved to the nearest symbol)
  [0] 0xC000000032488900 pdOSSeLoggingCallback + 0x980
  [1] 0xC000000010CC5A00 ossLog + 0x4E0
  [2] 0xC000000010CC5610 ossLog + 0xF0
  [3] 0xC00000003255E100 _Z27cryptDynamicLoadGSKitCryptoPc + 0x5F0
  [4] 0xC00000003255F460 cryptContextRealInit + 0x200
  [5] 0xC000000032561950 cryptContextCheckAndInit + 0x130
  [6] 0xC000000032561B70 cryptDHInit + 0x120
  [7] 0xC00000003384FBD0 sqlexSlcServerEncryptAccsec + 0x170
  [8] 0xC00000003384F7B0 _Z33sqlexSlcServerEncryptAuthenticateP14db2UCinterfacelPj + 0xF0
  [9] 0xC0000000321FB7D0 _Z20sqlexAppAuthenticateP14db2UCinterface + 0x1A60
  [10] 0xC0000000321F8920 _Z18sqljrDrdaArConnectP14db2UCinterface + 0x140
  [11] 0xC0000000321E96F0 _Z16sqleUCdrdaARinitP14db2UCconHandle + 0x230
  [12] 0xC000000032238CD0 sqleUCappConnect + 0x13C0
  [13] 0xC000000032647B20  _Z14CLI_sqlConnectP15CLI_CONNECTINFOP5sqlcaP19CLI_ERRORHEADERINFO + 0x32A0
  [14] 0xC0000000325D5710 _Z11SQLConnect2P15CLI_CONNECTINFOPhsS1_sS1_sS1_sh + 0xA10
  [15] 0xC0000000325ADB90 _Z17SQLDriverConnect2P15CLI_CONNECTINFOPvPhsS2_sPsthhP19CLI_ERRORHEADERINFO + 0x26E0
  [16] 0xC0000000325AAC00 _Z11SQLConnect1P15CLI_CONNECTINFOPhsS1_sS1_s + 0xB60
  [17] 0xC0000000325A8E30 SQLConnect + 0xC10
  [18] 0x4000000000001EA0 main + 0x620
  [19] 0xC00000000006E9B0 _DYNAMIC + 0xC00000000006E993

This does not answer the question. – Graeme Perrow Nov 27 '14 at 16:58 — Graeme Perrow, Nov 27 '14 at 16:58

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

2 Answers2