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

[Ian Lance Taylor <iant at google dot com>]

jhfrontz <jeff.frontz@gmail.com> writes:

> Ian Lance Taylor-3 wrote:
>> 
>> jhfrontz <jeff.frontz@gmail.com> writes:
>>> Also, it's not a flat-out error, so there must be conditions where mixing
>>> the libraries is acceptable (or even appropriate)-- what are these
>>> conditions?
>> 
>> You can probably make the situation work if you can write your main
>> program in C only, and you don't link against the C++ libraries
>> directly, but instead dlopen them using RTLD_DEEPBIND.
>> 
>
> Thanks for the tip--but I'm pretty ignorant about the run-time loader.  Are
> you suggesting 
> 1) that I create a C-only shell around the "actual" program.
> 2) open each of the disparate stdc++ libraries with RTLD_DEEPBIND (causing
> each stdc++ library to be self-consistent).
> 3) jump to my actual C++ program (perhaps by having it in yet-another shared
> object that I would dlopen after assuaging the stdc++ clash)?

Well, I said a C only program, but on further thought I don't think
that is required.  It should work to write a C++ program, and to just
dlopen the shared library which uses libstdc++.so.5.  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.

Ian