[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: dlopen(3) and symbol conflicts
On Thu, Mar 19, 2015 at 01:34:51PM +0100, Joerg Sonnenberger wrote:
> Depends on how dlopen is used. But I would say the real problem is
> libglusterfs in first place...
I reproduced it without libglusterfs:
- modtest is linked with -ltest, has testfunc() that calls getpid().
- libtest contains a getpid() that displays a message.
- the test program dlopen() modtest and call testfunc()
=> no message, which means libc getpid() was used
If I link the test progrm with -ltest, I get the message from
libtest's getpid(). But given that in my real world problem,
the test program is python and libtest is libglusterfs, this
is not a solution.
I have a worthy workaround: forcing libtest load into test using
LD_PRELOAD, That causes modtest to call libtetst's getpid() while
test is not linked with -ltest. Unfortunately the man page says
LD_PRELOAD could disapear some day (why?)
But that looks like a dlopen() problem: modtest is linked with -ltest,
libtest is loaded by dlopen, I can call other functions in it.
Why a libtest's symbol fails to override a libc's weak symbols? It
looks like a bug to me.
Main Index |
Thread Index |