11-19-2008 05:23 PM
dlhdl = dlopen("libmydll.sl",RTLD_LAZY|RTLD_GLOBAL);
When the DLL & app are compiled as 32-bit this always fails - with an error saying that the it cannot open the shared lib libmydll.sl ...
However it works when I compile both the DLL & app as 64-bit (+DD64).
Is there any additional settings to get dlopen to work in 32-bit mode
(all the env settings are the same when I try the tests i.e. SHLIB_PATH, LD_LIBRARY_PATH etc are all the same)
11-21-2008 11:50 AM
So when I do a dlopen/shl_load of this library I get:
/usr/lib/dld.sl: Can't shl_load() a library containing Thread Local Storage: /usr/lib/libpthread.1
The documentation seems to suggest that I can compile my shared library with the +tls=dynamic option and I should'nt see this anymore ... however that does not seem to work. I still get the same error messsage.
By the way the versions I have is:
aCC: HP ANSI C++ B3910B A.03.60
HPUX B.11.11 U 9000/800
(exporting LD_PRELOAD does solve the problem - but I'd like to be able to resolve it without having users do this)
11-21-2008 03:01 PM
You shouldn't link shlibs with libpthread. -mt has been fixed to no longer do that with -b. Only the executable should be linked with libpthread.
>I can compile my shared library with the +tls=dynamic option and I shouldn't see this anymore
That only works for your shlib, not for libpthread. And +tls=dynamic doesn't work for PA.
>exporting LD_PRELOAD does solve the problem
As I mentioned, if you are actually creating threads, then link your executables with libpthread.
If you aren't creating threads, then don't link your shlibs with -mt.