On Oct 22, 2008, at 5:51 PM, Ralf Wildenhues wrote:
Shouldn't it work to re-dlopen the lib with RTLD_GLOBAL?
I actually don't know -- what will the linker do in this scenario?
(now I'm curious :-) )
Also, recent libltdl should allow you to choose which scope you want
in
the first place
Ralf Wildenhues wrote:
Jeff Squyres wrote:
We use lt_dlopen() to open the plugins (Libtool's wrapper for a
portable dlopen). It opens all plugins (DSOs) in a private scope.
That private scope is kept deep in the OPAL MCA base and not exposed
elsewhere in the c
Hello Jeff, Eugene,
> Jeff Squyres wrote:
>
>> We use lt_dlopen() to open the plugins (Libtool's wrapper for a
>> portable dlopen). It opens all plugins (DSOs) in a private scope.
>> That private scope is kept deep in the OPAL MCA base and not exposed
>> elsewhere in the code base. So
Jeff Squyres wrote:
We use lt_dlopen() to open the plugins (Libtool's wrapper for a
portable dlopen). It opens all plugins (DSOs) in a private scope.
That private scope is kept deep in the OPAL MCA base and not exposed
elsewhere in the code base. So if you manually dlopen a plugin
again
George reminds me that I forgot to explain why you couldn't dlsym
We use lt_dlopen() to open the plugins (Libtool's wrapper for a
portable dlopen). It opens all plugins (DSOs) in a private scope.
That private scope is kept deep in the OPAL MCA base and not exposed
elsewhere in the cod
Short answer because we're all still in Chicago...
Terry tells me that you're just hacking around trying to see what
works, etc. So adding direct calls to the BTL in this kind of
scenario is ok. I'm sure you're aware that this is not good for real
code. :-)
To directly call a BTL funct
