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.
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
