This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
risk of mixing libstdc++ versions in one executable
- From: jhfrontz <jeff dot frontz at gmail dot com>
- To: libstdc++ at gcc dot gnu dot org
- Date: Thu, 9 Oct 2008 17:00:15 -0700 (PDT)
- Subject: risk of mixing libstdc++ versions in one executable
[I posted this in gcc-help but didn't really get a satisfying answer]
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?
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?
I've received a suggestion that "the ABIs of libraries differ" but if I
"test it and it works, I would say go ahead and ignore the warning."
However, 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
really 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?
Ideas?
Thanks,
Jeff
--
View this message in context: http://www.nabble.com/risk-of-mixing-libstdc%2B%2B-versions-in-one-executable-tp19909638p19909638.html
Sent from the gcc - libstdc++ mailing list archive at Nabble.com.