http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52922
--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-04-11 00:49:39 UTC --- (In reply to comment #7) > I realise this is off-topic but I would love to know: what is causing this > limitation? GCC's "fixincludes" mechanism, which installs modified versions of system headers alongside GCC's own headers, earlier in the include path. The installed "fixed" features.h header is based on a copy of that header from glibc 2.5 (or whatever old version it is that SL5 uses) and that is incompatible with glibc 2.12 (or whatever it is SL6 uses). IIRC in glibc 2.5 the xlocale features were GNU extensions, so only enabled by _GNU_SOURCE. The xlocale features were later added to POSIX 2008, so glibc 2.12 doesn't consider them to be GNU extensions and enables them when _XOPEN_SOURCE >= 700. The glibc 2.5 features.h defines _XOPEN_SOURCE=600 (i.e. POSIX 2001) when _GNU_SOURCE is defined, because that's the latest POSIX spec that existed when glibc 2.5 was released. So the "fixed" features.h installed with the old GCC doesn't know about POSIX 2008 and doesn't set the required _XOPEN_SOURCE=700 value, so the __locale_t type is not declared by /usr/include/xlocale.h. (That's all from memory, you should be able to diff SL6's /usr/include/features.h with the header found under the GCC installation dir to confirm it.) > I thought by building gcc on the "oldest" architecture I could expect ABI > backward-compatibility on the "newer" architectures. If you use that GCC and actually build *on* the oldest system, yes, the binaries produced will run on the newer system too. But you cannot move that GCC you built to the newer system and expect it to still work. You can't expect the compiler to even work, let alone produce binaries that will run on the old systems. Building on the newer arch will create dependencies on the newer glibc and other system libs. There is far more to ABI compatibility than just the compiler used.
