[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: dlopen from dlopend library question
From: |
Ralf Wildenhues |
Subject: |
Re: dlopen from dlopend library question |
Date: |
Mon, 8 Aug 2005 11:10:08 +0200 |
User-agent: |
Mutt/1.4.1i |
Hi Gleb,
* Gleb Natapov wrote on Sun, Aug 07, 2005 at 11:31:54AM CEST:
> On Tue, Aug 02, 2005 at 03:44:05PM +0200, Ralf Wildenhues wrote:
> > * Gleb Natapov wrote on Mon, Aug 01, 2005 at 04:58:03PM CEST:
*snip*
> > > After investigation of the problem I found that liba.so tries to load
> > > plugin.so from library constructor. Even if liba.so is dlopen with
> > > RTLD_GLOBAL flag set, plugin.so can't resolve symbols from liba.so
> >
> > Just so we don't misunderstand each other: what exactly do you mean by
> > library constructor? Are you overwriting DT_INIT? (If so, you are a far
> > way from portable shared libraries.)
> I am talking about function marked __attribute__((constructor)).
Yes, that is what I meant.
> Portability is not an issue for me.
OK. You should look into it more.
> > > Program 'prog' calls dlopen(liba.so, RTLD_GLOBAL), in constructor liba.so
> > > calls dlopen(plugin.so) and this call fails with unresolved symbols
> > > from liba.so.
> > >
> > > If we add function init_a() to liba.so and move dlopen(plugin.so) from
> > > constructor to the function and we call this function from 'prog' after
> > > dlopen (liba.so, RTLD_GLOBAL) then everything works as expected.
> >
> > Best would be if you showed short reproducible code. Not that I know
> > whether I could help you then.
> >
> Attached. To compile run following:
> $ gcc liba.c -shared -o liba.so
> $ gcc plugin.c -shared -o plugin.so
> $ gcc prog.c -ldl -o prog
Some notes:
- In general, you _must_ use -fPIC to compile the code that ends up in
shared objects. Above will fail blatantly on x86_64, for example.
- You should make use of dlerror, for example like this, in
the failure case:
fprintf (stderr, "Load of plugin.so failed: %s\n", dlerror());
- Quoting 'info gcc Link\ Options':
|
| (1) On some systems, `gcc -shared' needs to build supplementary stub
| code for constructors to work. On multi-libbed systems, `gcc -shared'
| must select the correct support libraries to link against. Failing to
| supply the correct flags may lead to subtle defects. Supplying them in
| cases where they are not necessary is innocuous.
So, for example, using
gcc plugin.c -shared -o plugin.so -L. -la
and then using
LD_LIRBARY_PAH=. ./prog
will succeed.
> Notice that second dlopen of plugin.so succeeds.
HTH,
Ralf