1753774
Members
7057
Online
108799
Solutions
SOLVED
what does "file mod_perl.so" show ? it should be a shared library, else its a bad format to load.
if it is a shared library, its ABI should match with that of your executable (i.e. you cant have one 32-bit and other 64-bit).
if its a shared library of matching ABI, it better not have any thread local storage (TLS) in it (unless you are on IA64?). also none of its dependencies can have TLS. dlopen/shl_load cant load shared libraries that have TLS in them, at least on PA.
for PA32 shared libraries you can see this using "odump -subspace mod_perl.so" - the "$TBSS$" and "$TDATA$" subspaces, if they exist, should be of zero size.
for PA64, use "elfdump -S -h mod_perl.so" - the .tbss and .tdata sections should be of zero length.
if you find that a shared library - either mod_perl.so or one of its dependecies - has TLS in it, you can work around this problem by statically linking it with the executable (include it in the link line) or pre-loading it at run-time using the LD_PRELOAD_ONCE or LD_PRELOAD environment variables.
--
ranga
[i work for hpe]
if it is a shared library, its ABI should match with that of your executable (i.e. you cant have one 32-bit and other 64-bit).
if its a shared library of matching ABI, it better not have any thread local storage (TLS) in it (unless you are on IA64?). also none of its dependencies can have TLS. dlopen/shl_load cant load shared libraries that have TLS in them, at least on PA.
for PA32 shared libraries you can see this using "odump -subspace mod_perl.so" - the "$TBSS$" and "$TDATA$" subspaces, if they exist, should be of zero size.
for PA64, use "elfdump -S -h mod_perl.so" - the .tbss and .tdata sections should be of zero length.
if you find that a shared library - either mod_perl.so or one of its dependecies - has TLS in it, you can work around this problem by statically linking it with the executable (include it in the link line) or pre-loading it at run-time using the LD_PRELOAD_ONCE or LD_PRELOAD environment variables.
--
ranga
[i work for hpe]
you can use chatr or ldd on mod_perl.so to list its dependencies.
also if you are using SHLIB_PATH for both PA32 and PA64, please try to put all the PA32 paths first and PA64 paths later - the PA64 loader is smarter in ignoring unknown file types.
--
ranga
[i work for hpe]
also if you are using SHLIB_PATH for both PA32 and PA64, please try to put all the PA32 paths first and PA64 paths later - the PA64 loader is smarter in ignoring unknown file types.
--
ranga
[i work for hpe]
as i said, ldd will show you the other shared libraries that mod_perl.so depends on if any.
you can also try a simple program like this (run as a shell script):
[----
cat > test.c << @EOF
#include
#include
#include
main ()
{
void *dl = dlopen("mod_perl.so",RTLD_LAZY);
if (dl==NULL) {
puts(dlerror());
} else {
puts("success");
dlclose(dl);
}
}
@EOF
cc +DD64 test.c -ldl -o test
./test
----]
if mod_perl.so depends on something like libpthread.1 that has TLS in it, you will see a message like
[----
Cannot dlopen load module '/usr/lib/pa20_64/libpthread.1' because it contains thread specific data.
----]
in such a case the workaround is to run the test with LD_PRELOAD_ONCE set to a colon-separated list of the paths such shared libraries:
LD_PRELOAD_ONCE=/usr/lib/pa20_64/libpthread.1 ./test
this is not specific to apache, it is a limitation in the TLS implementation and can affect even the simple test case above.
--
ranga
[i work for hpe]
you can also try a simple program like this (run as a shell script):
[----
cat > test.c << @EOF
#include
#include
#include
main ()
{
void *dl = dlopen("mod_perl.so",RTLD_LAZY);
if (dl==NULL) {
puts(dlerror());
} else {
puts("success");
dlclose(dl);
}
}
@EOF
cc +DD64 test.c -ldl -o test
./test
----]
if mod_perl.so depends on something like libpthread.1 that has TLS in it, you will see a message like
[----
Cannot dlopen load module '/usr/lib/pa20_64/libpthread.1' because it contains thread specific data.
----]
in such a case the workaround is to run the test with LD_PRELOAD_ONCE set to a colon-separated list of the paths such shared libraries:
LD_PRELOAD_ONCE=/usr/lib/pa20_64/libpthread.1 ./test
this is not specific to apache, it is a limitation in the TLS implementation and can affect even the simple test case above.
--
ranga
[i work for hpe]
thanks, glad it helped :)
--
ranga
[i work for hpe]
--
ranga
[i work for hpe]