libtool
[Top][All Lists]
Advanced

[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:39:09 +0200
User-agent: Mutt/1.4.1i

* Gleb Natapov wrote on Mon, Aug 08, 2005 at 11:20:51AM CEST:
> On Mon, Aug 08, 2005 at 11:10:08AM +0200, Ralf Wildenhues wrote:
> 
> > - 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.
> I know that linking plugin.so with liba solves the issue, but 
> the question is why RTLD_GLOBAL doesn't take effect in library init function. 
> Currently the problem was solved by not calling dlopen in init.

Hmm.  Maybe you should contact either gcc or glibc people about this
issue.  It seems one of the tools involved is at fault here (though I
guess it's rather a documentation update than a fix which you will
receive :)

It'd be good if you could let us know of the eventual outcome.

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]