risk of mixing libstdc++ versions in one executable

risk of mixing libstdc++ versions in one executable

[jhfrontz]

In reviewing the 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?

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?

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

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

[David Daney]

jhfrontz wrote:
> In reviewing the 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?

Well at the highest level, it is almost guaranteed not to work.  This is because the ABIs of libraries differs among other problems.

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

That is one problem you might find.

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

If you test it and it works, I would say go ahead and ignore the warning.  But if it fails, don't say you were not warned.

David Daney

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

[jhfrontz]

David Daney wrote:
> 
> jhfrontz wrote:
>> In reviewing the 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?
> 
> Well at the highest level, it is almost guaranteed not to work.  This is
> because the ABIs of libraries differs among other problems.
> 
>>  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?
> 
> That is one problem you might find.
> 
>> 
>> If I have such a firewall, can I safely ignore the ominous warning from
>> ld?
>> 
> 
> If you test it and it works, I would say go ahead and ignore the warning. 
> But if it fails, don't say you were not warned.
> 
> David Daney
> 
> 

OK, thanks, but I'm not sure how to test it.  I mean, I can run the
resulting executable and it seems to behave well, but I'm not sure if that's
an appropriate/sufficient test.  Before I can design an appropriate test, I
need to understand the failure modes that I'm looking for.  What are the
failure modes for mixing the two libraries?  Will these failures only occur
in code that attempts to make use of a library for which it was not
compiled?

To put it another way-- someone had some idea of bad things to come when
they added the warning message; what are these bad things and what would
induce their appearance?

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?

Thanks,
Jeff

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