dmlopen and glibc core symbols resolving
Thu Oct 6 09:41:00 GMT 2011
My Linux application needs some third party shared library (libTPSL.so)
on some "common" shared library (libcommon.so.1). The application requires
"common" shared library version 2 (libcommon.so.2). To resolve
symbols conflict the application loads libTPSL.so into separate
While execution the application crashes with stack (according gdb)
dlmopen->_dl_open->dl_open_worker->add_to_global->crash in ld-linux.so.2.
As I see there are 2 instances of glibc(libc/libdl/etc), in
application's address space -
the first is in global namespace (LM_ID_BASE), the second is in
by dlmopen. The second instance of glibc is created because libcommon.so.x
The question. Is there any glibc magic which can prevent the second
glibc loading if it is required by shared library opened via dlmopen?
Thank you in advance
More information about the Libc-help