About the GCC and C++ ABI identification tokens


I notice that Clang 5 still identifies itself as GCC 4.2.1, on Mac as on Linux. Couldn't this be upgraded by now, especially when running with -stdlib=libstdc++ where it might make sense to provide the same conditional information to code being compiled as G++ would?

An example, with wxWidgets 3.0 (built with clang 5.0) and Audacity 2.2.2 (built with GCC 7.2.0). This is on Linux, so clang will use the latest libstdc++ (lib + headers) by default:

%> audacity
11:58:22: Warning: Mismatch between the program and library build versions detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1002,wx containers,compatible with 2.8),
and your program used 3.0 (wchar_t,compiler with C++ ABI 1010,wx containers,compatible with 2.8).

In practice Audacity runs just fine when I patch my wxWidgets install to turn that abort into a warning message.

FWIW, the wxWidgets build doesn't specifically request C++11 while the Audacity build does. Apologies if that explains the flagged ABI differences.


At my previous employer we carried a local patch to convince Clang trunk to identify as GCC 4.6.1 to work around some overzealous build system compiler detection. It might be nice (or completely reckless) to give users a way to force the GCC version string.

4.2.1 does seem old as a default.

  • Kim

Den tors 22 mars 2018 12:40René J.V. Bertin via cfe-dev <cfe-dev@lists.llvm.org> skrev:

As I recall, part of the reason we picked 4.2.1 is because glibc tries to use some GCC features added after that (and not supported by Clang) if Clang advertises itself as being a later version. I don’t know off-hand which features those might be, and it’s entirely possible that we could advertise a later version.

Perhaps someone could look through the GCC release notes to find what the latest version we could reasonably claim to be compatible with is, and we could try claiming to be that version and see what breaks.

Previous discussion: http://clang-developers.42468.n3.nabble.com/RFC-Bump-up-clang-s-GNUC-MINOR-td3982225.html

The most significant one that I know of is __builtin_va_arg_pack and __builtin_va_arg_pack_len, which are GCC4.3 and heavily used with FORITFY_SOURCE. We have an implementation of it (it requires some inliner work, plus some CFE work), but it is not what I would call a clean thing to implement.

Other than that, it is pretty insignificant.