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

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

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

> In reviewing the [gcc-help] archives, I see admonitions to avoid using
> different versions of libstdc++ in one binary (specifically libstcd++5 and
> libstdc++6, which results in the confusing-to-the-unsuspecting "/usr/bin/ld:
> warning: libstdc++.so.5, needed by
> some-undersupported-IRRATIONAL-INSTRUMENTS-third-party.so, may conflict with
> libstdc++.so.6" message).
>
> But, really, what is the basis for the warning?  Is it that the binary may
> in one place use an object created by one library version and then in
> another place hand the object off to a member function in the other library
> version?

When you compile C++ code using libstdc++, some of the template
functions are instantiated in your program, and some of the template
functions come from -lstdc++.  For the template functions in your
program, some have the same name in libstdc++.so.5 and libstdc++.so.6.
When you run your program, any libstdc++ symbols that are included in
the executable will override the symbols in the two versions of the
libstdc++ shared library.  The effect is that code written against
libstdc++.so.5 may call the libstdc++.so.6 routines, and vice-versa.
That fails because the data structures are defined differently.

> I'm in a conundrum because I'm dealing with various third-parties' software;
> I can't get access to everything I need to make them all play well together. 
> But, I'm hoping it's not so bad--in my case, the C++ code in the third-party
> software requiring the older library is disjoint from every other bit of C++
> code in the process; there is a strict C
> calling-convention/pass-only-intrinsic-data-types "firewall" between the
> poorly supported third-party library and the rest of the C++ code in the
> process.
>
> If I have such a firewall, can I safely ignore the ominous warning from ld?

No, it doesn't help, because of ELF symbol overriding.

> 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?

The linker generally permits you to shoot yourself in the foot.

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.

Ian