Re: dlopen(3) and symbol conflicts

[Emmanuel Dreyfus <manu%netbsd.org@localhost>]

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.

-- 
Emmanuel Dreyfus
manu%netbsd.org@localhost