duplicate instances of a shared library that is linked against an OpenRAVE plugin

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

duplicate instances of a shared library that is linked against an OpenRAVE plugin

Michael Koval
I have two OpenRAVE plugins, A and B, that depend on a common shared
library C. It appears that A and B are each loading a separate copy of
C when I call RaveInitialize. This manifests itself in two places: (1)
the global state in C differs depending upon whether I access it from
A or B and (2) dynamic_cast'ing an object constructed A in B fails if
the type was defined in C. Even worse, only one set of the global
variables is getting statically initialized.

Surprisingly, this happens if both A and B in my OPENRAVE_PLUGIN path
even if C is not present. Therefore, the duplication seems to occur
when RaveInitialize searches for valid plugins.

I've played around with the -fPIC, -rdynamic, and --export-dynamic
linking flags (on all three libraries) to no avail. The documentation
I've read online suggests that only a single instance of C should be
loaded. Any suggestions?

Thanks,
-Michael

------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: duplicate instances of a shared library that is linked against an OpenRAVE plugin

Rosen Diankov
Administrator
when openrave loads plugins it uses:

dlopen("my.so", RTLD_NOW);

which when you look at the docs, means:

 Symbols defined in this library are not made  available  to resolve references in subsequently loaded libraries.

What you can do is call dlopen("C.so", RTLD_GLOBAL|RTLD_NOW) right before the RaveInitialize call, hopefully that should force only once instance of your library. I'm not sure if that will fix the dynamic casting though, casting across shared object boundaries is tricky and i've never got it working.

The right way to design C is to remove any static/global variables. That's really bad because you lose control over static variable initialization and destruction.

rosen,






2013/8/7 Michael Koval <[hidden email]>
I have two OpenRAVE plugins, A and B, that depend on a common shared
library C. It appears that A and B are each loading a separate copy of
C when I call RaveInitialize. This manifests itself in two places: (1)
the global state in C differs depending upon whether I access it from
A or B and (2) dynamic_cast'ing an object constructed A in B fails if
the type was defined in C. Even worse, only one set of the global
variables is getting statically initialized.

Surprisingly, this happens if both A and B in my OPENRAVE_PLUGIN path
even if C is not present. Therefore, the duplication seems to occur
when RaveInitialize searches for valid plugins.

I've played around with the -fPIC, -rdynamic, and --export-dynamic
linking flags (on all three libraries) to no avail. The documentation
I've read online suggests that only a single instance of C should be
loaded. Any suggestions?

Thanks,
-Michael

------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users


------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: duplicate instances of a shared library that is linked against an OpenRAVE plugin

Michael Koval
Thanks, Rosen! I actually stumbled across the same solution (see
below) right before seeing your email.

I wonder if it makes sense to change plugindatabase.h to add the
RTLD_GLOBAL flag by default. Our lab has run into C++ typeinfo
problems in OpenRAVE (especially when catching exceptions) a few times
now. GCC has a pretty thorough page about getting typeinfo working in
shared objects: <http://gcc.gnu.org/faq.html#dso>. That page suggests
that typeinfo should be properly resolved if the shared objects are
linked with the export-dynamic option (-Wl,-E or -rdynamic) and the
RTLD_GLOBAL flag is passed to dlopen when they are loaded. This would
fix dynamic_cast on OpenRAVE's interfaces and eliminate the need for
the RaveInterfaceCast workaround.

I agree that static and global variables are generally to be avoided,
but they're sometimes unavoidable. Singletons, especially when they
are factories, aren't _always_ a sign of bad design. :-)

-Michael

On Wed, Aug 7, 2013 at 12:06 AM, Rosen Diankov <[hidden email]> wrote:

> when openrave loads plugins it uses:
>
> dlopen("my.so", RTLD_NOW);
>
> which when you look at the docs, means:
>
>  Symbols defined in this library are not made  available  to resolve
> references in subsequently loaded libraries.
>
> What you can do is call dlopen("C.so", RTLD_GLOBAL|RTLD_NOW) right before
> the RaveInitialize call, hopefully that should force only once instance of
> your library. I'm not sure if that will fix the dynamic casting though,
> casting across shared object boundaries is tricky and i've never got it
> working.
>
> The right way to design C is to remove any static/global variables. That's
> really bad because you lose control over static variable initialization and
> destruction.
>
> rosen,
>
>
>
>
>
>
> 2013/8/7 Michael Koval <[hidden email]>
>>
>> I have two OpenRAVE plugins, A and B, that depend on a common shared
>> library C. It appears that A and B are each loading a separate copy of
>> C when I call RaveInitialize. This manifests itself in two places: (1)
>> the global state in C differs depending upon whether I access it from
>> A or B and (2) dynamic_cast'ing an object constructed A in B fails if
>> the type was defined in C. Even worse, only one set of the global
>> variables is getting statically initialized.
>>
>> Surprisingly, this happens if both A and B in my OPENRAVE_PLUGIN path
>> even if C is not present. Therefore, the duplication seems to occur
>> when RaveInitialize searches for valid plugins.
>>
>> I've played around with the -fPIC, -rdynamic, and --export-dynamic
>> linking flags (on all three libraries) to no avail. The documentation
>> I've read online suggests that only a single instance of C should be
>> loaded. Any suggestions?
>>
>> Thanks,
>> -Michael
>>
>>
>> ------------------------------------------------------------------------------
>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>> It's a free troubleshooting tool designed for production.
>> Get down to code-level detail for bottlenecks, with <2% overhead.
>> Download for free and get started troubleshooting in minutes.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Openrave-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>
>

------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: duplicate instances of a shared library that is linked against an OpenRAVE plugin

Rosen Diankov
Administrator
RTLD_GLOBAL is dangerous and produces extremely difficult to debug errors. we cannot have that enabled by default.

your best bet is to call dlopen on any libraries you need before RaveInitialize. You can even parse the OPENRAVE_PLUGINS variable and open every plugin.

singletons and static variables are two different things. while singletons are fine, static singletons can also be pretty dangerous. for example:

1. your GUI object is managed by a static variable. The constraint is that GUI objects can only work on their data on a GUI thread.
2. your plugin gets unloaded
3. your GUI object is now released in some random thread that decided to do the shared object unlinking
4. your application segfaults

rosen,




2013/8/7 Michael Koval <[hidden email]>
Thanks, Rosen! I actually stumbled across the same solution (see
below) right before seeing your email.

I wonder if it makes sense to change plugindatabase.h to add the
RTLD_GLOBAL flag by default. Our lab has run into C++ typeinfo
problems in OpenRAVE (especially when catching exceptions) a few times
now. GCC has a pretty thorough page about getting typeinfo working in
shared objects: <http://gcc.gnu.org/faq.html#dso>. That page suggests
that typeinfo should be properly resolved if the shared objects are
linked with the export-dynamic option (-Wl,-E or -rdynamic) and the
RTLD_GLOBAL flag is passed to dlopen when they are loaded. This would
fix dynamic_cast on OpenRAVE's interfaces and eliminate the need for
the RaveInterfaceCast workaround.

I agree that static and global variables are generally to be avoided,
but they're sometimes unavoidable. Singletons, especially when they
are factories, aren't _always_ a sign of bad design. :-)

-Michael

On Wed, Aug 7, 2013 at 12:06 AM, Rosen Diankov <[hidden email]> wrote:
> when openrave loads plugins it uses:
>
> dlopen("my.so", RTLD_NOW);
>
> which when you look at the docs, means:
>
>  Symbols defined in this library are not made  available  to resolve
> references in subsequently loaded libraries.
>
> What you can do is call dlopen("C.so", RTLD_GLOBAL|RTLD_NOW) right before
> the RaveInitialize call, hopefully that should force only once instance of
> your library. I'm not sure if that will fix the dynamic casting though,
> casting across shared object boundaries is tricky and i've never got it
> working.
>
> The right way to design C is to remove any static/global variables. That's
> really bad because you lose control over static variable initialization and
> destruction.
>
> rosen,
>
>
>
>
>
>
> 2013/8/7 Michael Koval <[hidden email]>
>>
>> I have two OpenRAVE plugins, A and B, that depend on a common shared
>> library C. It appears that A and B are each loading a separate copy of
>> C when I call RaveInitialize. This manifests itself in two places: (1)
>> the global state in C differs depending upon whether I access it from
>> A or B and (2) dynamic_cast'ing an object constructed A in B fails if
>> the type was defined in C. Even worse, only one set of the global
>> variables is getting statically initialized.
>>
>> Surprisingly, this happens if both A and B in my OPENRAVE_PLUGIN path
>> even if C is not present. Therefore, the duplication seems to occur
>> when RaveInitialize searches for valid plugins.
>>
>> I've played around with the -fPIC, -rdynamic, and --export-dynamic
>> linking flags (on all three libraries) to no avail. The documentation
>> I've read online suggests that only a single instance of C should be
>> loaded. Any suggestions?
>>
>> Thanks,
>> -Michael
>>
>>
>> ------------------------------------------------------------------------------
>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>> It's a free troubleshooting tool designed for production.
>> Get down to code-level detail for bottlenecks, with <2% overhead.
>> Download for free and get started troubleshooting in minutes.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Openrave-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/openrave-users
>
>


------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: duplicate instances of a shared library that is linked against an OpenRAVE plugin

Michael Koval
I understand that RTLD_GLOBAL can cause collisions between
identically-named symbols in different shared objects and can cause
subtle errors. However, RTLD_LOCAL causes an entirely separate set of
difficult-to-debug errors. Even if I completely eliminate
global/static from state code, there is no way I can guarantee that
every third-party library I link with (and their, potentially
recursive, dependencies...) does the same. And this is without
considering the known dynamic_cast/type_info/exception issues.

Is there any way to fix this without passing RTLD_GLOBAL to dlopen?
How do other C++ plugin systems, like pluginlib, work around this
problem? I can manually load the offending libraries with RTLD_GLOBAL
as a stopgap measure, but it doesn't seem like a scalable solution.

I see your point about global state, e.g. with GUIs. However, I don't
see any way to implement a singleton without at least one static
variable. You need to store the instance (or a pointer to the
instance) somewhere.

Thanks for your help. This has been a great opportunity to learn more
about how OpenRAVE's plugin system works under the hood. :-)

-Michael

On Wed, Aug 7, 2013 at 3:10 AM, Rosen Diankov <[hidden email]> wrote:

> RTLD_GLOBAL is dangerous and produces extremely difficult to debug errors.
> we cannot have that enabled by default.
>
> your best bet is to call dlopen on any libraries you need before
> RaveInitialize. You can even parse the OPENRAVE_PLUGINS variable and open
> every plugin.
>
> singletons and static variables are two different things. while singletons
> are fine, static singletons can also be pretty dangerous. for example:
>
> 1. your GUI object is managed by a static variable. The constraint is that
> GUI objects can only work on their data on a GUI thread.
> 2. your plugin gets unloaded
> 3. your GUI object is now released in some random thread that decided to do
> the shared object unlinking
> 4. your application segfaults
>
> rosen,
>
>
>
>
> 2013/8/7 Michael Koval <[hidden email]>
>>
>> Thanks, Rosen! I actually stumbled across the same solution (see
>> below) right before seeing your email.
>>
>> I wonder if it makes sense to change plugindatabase.h to add the
>> RTLD_GLOBAL flag by default. Our lab has run into C++ typeinfo
>> problems in OpenRAVE (especially when catching exceptions) a few times
>> now. GCC has a pretty thorough page about getting typeinfo working in
>> shared objects: <http://gcc.gnu.org/faq.html#dso>. That page suggests
>> that typeinfo should be properly resolved if the shared objects are
>> linked with the export-dynamic option (-Wl,-E or -rdynamic) and the
>> RTLD_GLOBAL flag is passed to dlopen when they are loaded. This would
>> fix dynamic_cast on OpenRAVE's interfaces and eliminate the need for
>> the RaveInterfaceCast workaround.
>>
>> I agree that static and global variables are generally to be avoided,
>> but they're sometimes unavoidable. Singletons, especially when they
>> are factories, aren't _always_ a sign of bad design. :-)
>>
>> -Michael
>>
>> On Wed, Aug 7, 2013 at 12:06 AM, Rosen Diankov <[hidden email]>
>> wrote:
>> > when openrave loads plugins it uses:
>> >
>> > dlopen("my.so", RTLD_NOW);
>> >
>> > which when you look at the docs, means:
>> >
>> >  Symbols defined in this library are not made  available  to resolve
>> > references in subsequently loaded libraries.
>> >
>> > What you can do is call dlopen("C.so", RTLD_GLOBAL|RTLD_NOW) right
>> > before
>> > the RaveInitialize call, hopefully that should force only once instance
>> > of
>> > your library. I'm not sure if that will fix the dynamic casting though,
>> > casting across shared object boundaries is tricky and i've never got it
>> > working.
>> >
>> > The right way to design C is to remove any static/global variables.
>> > That's
>> > really bad because you lose control over static variable initialization
>> > and
>> > destruction.
>> >
>> > rosen,
>> >
>> >
>> >
>> >
>> >
>> >
>> > 2013/8/7 Michael Koval <[hidden email]>
>> >>
>> >> I have two OpenRAVE plugins, A and B, that depend on a common shared
>> >> library C. It appears that A and B are each loading a separate copy of
>> >> C when I call RaveInitialize. This manifests itself in two places: (1)
>> >> the global state in C differs depending upon whether I access it from
>> >> A or B and (2) dynamic_cast'ing an object constructed A in B fails if
>> >> the type was defined in C. Even worse, only one set of the global
>> >> variables is getting statically initialized.
>> >>
>> >> Surprisingly, this happens if both A and B in my OPENRAVE_PLUGIN path
>> >> even if C is not present. Therefore, the duplication seems to occur
>> >> when RaveInitialize searches for valid plugins.
>> >>
>> >> I've played around with the -fPIC, -rdynamic, and --export-dynamic
>> >> linking flags (on all three libraries) to no avail. The documentation
>> >> I've read online suggests that only a single instance of C should be
>> >> loaded. Any suggestions?
>> >>
>> >> Thanks,
>> >> -Michael
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>> >> It's a free troubleshooting tool designed for production.
>> >> Get down to code-level detail for bottlenecks, with <2% overhead.
>> >> Download for free and get started troubleshooting in minutes.
>> >>
>> >>
>> >> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>> >> _______________________________________________
>> >> Openrave-users mailing list
>> >> [hidden email]
>> >> https://lists.sourceforge.net/lists/listinfo/openrave-users
>> >
>> >
>
>

------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: duplicate instances of a shared library that is linked against an OpenRAVE plugin

Rosen Diankov
Administrator
Michael,

Your bring excellent points to the table.

The fact that RTTI information of symbols might not be exposed of a library is not a critical problem of the system. The system will still work perfectly, you just can't make dynamic casts. I've thought about this issue very hard, and it turns out you don't need dynamic casts if the system is designed well. I've been designing complex systems using OpenRAVE that bridge many libraries together, and dynamic cats have never been a major issue.

RTLD_GLOBAL is *really* dangerous. Even if you are careful designing your own libraries, if you link with a library that is not well coded, and it has a lot of dependencies, then it will drag all of those symbols and RTTI info in the global scope. Furthermore, your libraries can start executing code from other libraries! So even though RTTI will return some information, that information could be wrong! Don't use RTLD_GLOBAL unless you control every aspect of your program.

My other advise is to only have static singletons in your main source program and not in your libraries. When a library object is created, someone will be creating it, meaning that someone will own it, meaning that it doesn't have to be static. I have yet to see a true use-case where static singletons in libraries are necessary. OpenRAVE itself has only one static singleton managing the global runtime because that's the way OpenRAVE evolved. However, I can tell you that life would have been better without the static singleton; unfortunately too many people rely on the current behavior and it's too late to change ;0/

In any case there is a stopgap measure if you really really need it, it's called

typeid

For example:

MyClass* a = new MyClass();
string classname = typeid(*a).name();

Now classname would be some mangled version of "MyClass" depending on your compiler.


best,
rosen,



2013/8/8 Michael Koval <[hidden email]>
I understand that RTLD_GLOBAL can cause collisions between
identically-named symbols in different shared objects and can cause
subtle errors. However, RTLD_LOCAL causes an entirely separate set of
difficult-to-debug errors. Even if I completely eliminate
global/static from state code, there is no way I can guarantee that
every third-party library I link with (and their, potentially
recursive, dependencies...) does the same. And this is without
considering the known dynamic_cast/type_info/exception issues.

Is there any way to fix this without passing RTLD_GLOBAL to dlopen?
How do other C++ plugin systems, like pluginlib, work around this
problem? I can manually load the offending libraries with RTLD_GLOBAL
as a stopgap measure, but it doesn't seem like a scalable solution.

I see your point about global state, e.g. with GUIs. However, I don't
see any way to implement a singleton without at least one static
variable. You need to store the instance (or a pointer to the
instance) somewhere.

Thanks for your help. This has been a great opportunity to learn more
about how OpenRAVE's plugin system works under the hood. :-)

-Michael

On Wed, Aug 7, 2013 at 3:10 AM, Rosen Diankov <[hidden email]> wrote:
> RTLD_GLOBAL is dangerous and produces extremely difficult to debug errors.
> we cannot have that enabled by default.
>
> your best bet is to call dlopen on any libraries you need before
> RaveInitialize. You can even parse the OPENRAVE_PLUGINS variable and open
> every plugin.
>
> singletons and static variables are two different things. while singletons
> are fine, static singletons can also be pretty dangerous. for example:
>
> 1. your GUI object is managed by a static variable. The constraint is that
> GUI objects can only work on their data on a GUI thread.
> 2. your plugin gets unloaded
> 3. your GUI object is now released in some random thread that decided to do
> the shared object unlinking
> 4. your application segfaults
>
> rosen,
>
>
>
>
> 2013/8/7 Michael Koval <[hidden email]>
>>
>> Thanks, Rosen! I actually stumbled across the same solution (see
>> below) right before seeing your email.
>>
>> I wonder if it makes sense to change plugindatabase.h to add the
>> RTLD_GLOBAL flag by default. Our lab has run into C++ typeinfo
>> problems in OpenRAVE (especially when catching exceptions) a few times
>> now. GCC has a pretty thorough page about getting typeinfo working in
>> shared objects: <http://gcc.gnu.org/faq.html#dso>. That page suggests
>> that typeinfo should be properly resolved if the shared objects are
>> linked with the export-dynamic option (-Wl,-E or -rdynamic) and the
>> RTLD_GLOBAL flag is passed to dlopen when they are loaded. This would
>> fix dynamic_cast on OpenRAVE's interfaces and eliminate the need for
>> the RaveInterfaceCast workaround.
>>
>> I agree that static and global variables are generally to be avoided,
>> but they're sometimes unavoidable. Singletons, especially when they
>> are factories, aren't _always_ a sign of bad design. :-)
>>
>> -Michael
>>
>> On Wed, Aug 7, 2013 at 12:06 AM, Rosen Diankov <[hidden email]>
>> wrote:
>> > when openrave loads plugins it uses:
>> >
>> > dlopen("my.so", RTLD_NOW);
>> >
>> > which when you look at the docs, means:
>> >
>> >  Symbols defined in this library are not made  available  to resolve
>> > references in subsequently loaded libraries.
>> >
>> > What you can do is call dlopen("C.so", RTLD_GLOBAL|RTLD_NOW) right
>> > before
>> > the RaveInitialize call, hopefully that should force only once instance
>> > of
>> > your library. I'm not sure if that will fix the dynamic casting though,
>> > casting across shared object boundaries is tricky and i've never got it
>> > working.
>> >
>> > The right way to design C is to remove any static/global variables.
>> > That's
>> > really bad because you lose control over static variable initialization
>> > and
>> > destruction.
>> >
>> > rosen,
>> >
>> >
>> >
>> >
>> >
>> >
>> > 2013/8/7 Michael Koval <[hidden email]>
>> >>
>> >> I have two OpenRAVE plugins, A and B, that depend on a common shared
>> >> library C. It appears that A and B are each loading a separate copy of
>> >> C when I call RaveInitialize. This manifests itself in two places: (1)
>> >> the global state in C differs depending upon whether I access it from
>> >> A or B and (2) dynamic_cast'ing an object constructed A in B fails if
>> >> the type was defined in C. Even worse, only one set of the global
>> >> variables is getting statically initialized.
>> >>
>> >> Surprisingly, this happens if both A and B in my OPENRAVE_PLUGIN path
>> >> even if C is not present. Therefore, the duplication seems to occur
>> >> when RaveInitialize searches for valid plugins.
>> >>
>> >> I've played around with the -fPIC, -rdynamic, and --export-dynamic
>> >> linking flags (on all three libraries) to no avail. The documentation
>> >> I've read online suggests that only a single instance of C should be
>> >> loaded. Any suggestions?
>> >>
>> >> Thanks,
>> >> -Michael
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>> >> It's a free troubleshooting tool designed for production.
>> >> Get down to code-level detail for bottlenecks, with <2% overhead.
>> >> Download for free and get started troubleshooting in minutes.
>> >>
>> >>
>> >> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>> >> _______________________________________________
>> >> Openrave-users mailing list
>> >> [hidden email]
>> >> https://lists.sourceforge.net/lists/listinfo/openrave-users
>> >
>> >
>
>


------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
Openrave-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openrave-users
Loading...