On 30/10/14 15:06, Jan Kundrát wrote:
On Saturday, 25 October 2014 12:47:21 CEST, Luca Barbato wrote:
The ABI mismatch is due the library not being versioned properly as
"usual"?
Please note that this would be a "hard thing to do". This is not just a
matter of calling an appropriate version of a given function; there are
no guarantees about the internal layout of the data structures, etc.
Furthermore, portions of C++ code might be inlined, so whenever you have
a library compiled with different GCC versions, these cannot exchange
any data which embed a C++11 data type inside. That's quite a bummer --
std::string and std::list have both changed in C++11 (forbidden
ref-counting of std::string and O(1) size of std::list::size()). The
upstream's promise is that the ABI will eventually ebcome stable when
they remove the "experimental" label on their C++11 support.
I suspect that the only solution would be a full ABI version number
change at that time, though, and people want to avoid doing this because
that will of course break all C++ programs out there. It would be
terrific if the GCC guys provided a reasonable roadmap, because saying
"we support C++11" while also saying "don't combine code built by 4.7
and 4.8, that's totally unsupported" is a bit strange. Yes, limited time
and limited manpower and what not, but it's still something which makes
using all of the C++11 features a very risky business.
And obviously providing libstdc++ and libstdc++11 (and matching headers)
is not an option =\
_quite_ annoying indeed
lu - hoping rust won't have such issues.
