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.