Re: risk of mixing libstdc++ versions in one executable

[jhfrontz <jeff dot frontz at gmail dot com>]

jhfrontz wrote:
> 
> 
> Ian Lance Taylor-3 wrote:
>> 
>> The RTLD_DEEPBIND should protect you from the libstdc++ version
>> collision,
>> I hope.  The main difficulty is that you need to use dlsym to get the
>> functions you want to call; you can't call them directly.
>> 
>> 
> 
> The functions I need to call in the third-party library are
> well-defined/known and I can easily call them by using function pointers
> set using dlsym().
> 
> 
> 
> 


Update: the RTLD_DEEPBIND works -- sort of.  It pulls in the right
libraries, but has some strange side effect.  I call dlsym() and get an
address of a desired function; I do an indirect call off of the retrieved
address and see the appropriate code being executed in the dlopen()'d
library (by using stepi in gdb).  However, the behavior of the function is
incorrect (as determined by the values set/returned by the function);
calling the function directly (by way of linking directly against the
offending library) results in the desired behavior.

Is there any side-effect of doing an indirect call off of a value returned
dlsym() (vs. calling the desired function directly from a run-time loaded
library)?  The timing of when the library's (or libraries') _init() routine
is called as well as the memory layout are obvious ones, but on the surface
these both seem irrelevant for this library.

Thanks,
Jeff
-- 
View this message in context: http://www.nabble.com/risk-of-mixing-libstdc%2B%2B-versions-in-one-executable-tp19909697p20101949.html
Sent from the gcc - libstdc++ mailing list archive at Nabble.com.