SCons stupidly treats Clang as if it were GCC (hint: it's not) and that
causes the config check to fail due to the version symbols being
absent/not what we expect. So just ignore the GCC version when Clang is
detected, in the config test program; we can probably expect whoever is
using Clang to be able to deal with any issues that may arise from
attempting to use a Clang version we don't support.
As for why we don't test the Clang version number, according to
<http://clang.llvm.org/docs/LanguageExtensions.html#builtin-macros>,
"marketing version numbers should not be used to check for language
features, as different vendors use different numbering schemes." And
indeed, it is the case with the versions of Clang shipped with XCode
that they do not accurately reflect the upstream version they correspond
to and have weird version numbers such as 5 (as of this writing upstrema
hasn't even released version 4.0 yet). Such is life.
