This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

dmlopen and glibc core symbols resolving


Hi all,

My Linux application needs some third party shared library (libTPSL.so) which depends
on some "common" shared library (libcommon.so.1). The application requires
"common" shared library version 2 (libcommon.so.2). To resolve libcommon.so.x
symbols conflict the application loads libTPSL.so into separate namespace via
dlmopen.


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 namespace created
by dlmopen. The second instance of glibc is created because libcommon.so.x
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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]