dmlopen and glibc core symbols resolving

Vladimir Simonov
Thu Oct 6 09:41:00 GMT 2011

Hi all,

My Linux application needs some third party shared library ( 
which depends
on some "common" shared library ( The application requires
"common" shared library version 2 ( To resolve
symbols conflict the application loads into separate 
namespace via

While execution the application crashes with stack (according gdb)
dlmopen->_dl_open->dl_open_worker->add_to_global->crash in
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 
namespace created
by dlmopen. The second instance of glibc is created because
require it.

The question. Is there any glibc magic which can prevent the second 
instance of
glibc loading if it is required by shared library opened via dlmopen?

Thank you in advance
Vladimir Simonov

More information about the Libc-help mailing list