Re: Exporting symbols for dlopen from shared library?

[Marat Boshernitsan <maratb at cs dot berkeley dot edu>]

Yes I have.  As I understand it, RTLD_GLOBAL will make all symbols from
the library available to subsequent dlopen calls.  This is, actually,
something I don't want to do with bar.so, since foo.so may load bar1.so and
bar2.so and I don't want them to conflict.

It seems that what I need is that foo.so be loaded with RTLD_GLOBAL into
Tcl/Tk or Java interpreter, but I have no control over their source
code.  Is there some other way to achieve the same effect?

Thanks,

-- Marat

hjl@lucon.org (H.J. Lu) writes:

> > 
> > 
> > Hi,
> > 
> > I am having the following problem with explicit loading of dynamic
> > libraries:
> > 
> > I am working on dynamic library that can be loaded into the JVM and
> > Tcl/Tk interpreter.  This library, say foo.so, needs to load another
> > dynamic library using dlopen, say bar.so.  The name of bar.so is not
> > determinable until runtime.  The problem is that bar.so relies on
> > certain symbols from foo.so that it cannot find when loaded with dlopen.
> > 
> > I was having exactly the same problem before, when foo.so was built as
> > an executable, but I managed to fix it by passing -export-dynamic to the
> > linker (-rdynamic to gcc on Linux).  Is there a similar compiler/linker
> > magic I can use to build foo.so?
> > 
> > Compiler egcs-1.0.2.
> > Linker GNU ld 2.9
> > Platforms Redhat Linux 5.0, Solaris 2.6.
> > 
> 
> Have you tried RTLD_GLOBAL?
> 
> # man dlopen
> 
> will tell what RTLD_GLOBAL does.
> 
> -- 
> H.J. Lu (hjl@gnu.org)