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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux