You've missed at least one ABI incompatibility in GCC 4.7 and later, as demonstrated in real life by (at least) libboost_python, and distilled into this test case.
At least these bug reports are probably caused by this ABI incompatibility: https://svn.boost.org/trac/boost/ticket/6919 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455 https://svn.boost.org/trac/boost/ticket/6895 As I've said before, I really wish GCC devs would take the ABI incompatibility problem more seriously. Lots of users have already started using -std=c++0x mode, and have absolutely no idea that it's completely unsafe to do so on a normal linux distro, linking against regular C++ libraries that are not compiled with a) c++11 enabled, and b) the exact same version of GCC. I understand that the ABI changes generally cannot be avoided, but a lot of pain for a lot of people could be avoided by making things fail obviously with a link error, instead of sometimes, arbitrarily, if you're lucky, you'll get a segfault at runtime. ====test1.cpp==== #include <utility> std::pair<int, int> execute() { return std::make_pair(0, 1); } ====test2.cpp==== #include <utility> #include <stdio.h> std::pair<int, int> execute(); int main() { std::pair<int, int> result = execute(); printf("%d %d\n", result.first, result.second); } ====test.sh==== #!/bin/sh CC="g++-4.7 -O1" $CC -std=c++03 -o test_cxx03.o -c test.cpp $CC -std=c++0x -o test_cxx11.o -c test.cpp $CC -std=c++03 -o test2_cxx03.o -c test2.cpp $CC -std=c++0x -o test2_cxx11.o -c test2.cpp $CC -o test test_cxx03.o test2_cxx03.o; ./test $CC -o test test_cxx11.o test2_cxx11.o; ./test $CC -o test test_cxx03.o test2_cxx11.o; ./test $CC -o test test_cxx11.o test2_cxx03.o; ./test ====output==== 0 1 0 1 -1757034448 32767 Segmentation fault
