libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: dlopen from dlopend library question


From: Gleb Natapov
Subject: Re: dlopen from dlopend library question
Date: Mon, 8 Aug 2005 12:45:52 +0300

On Mon, Aug 08, 2005 at 11:39:09AM +0200, Ralf Wildenhues wrote:
> * 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 :)
I also think so. But I'll try.

--
                        Gleb.




reply via email to

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