RFC: We should take a more conservative approach to libstdc++ compatibility...

Greetings all! This is the result of a chat between Richard and myself just now.

These days Clang does a great job of detecting GCC and libstdc++ installations and using them… such a great job that Clang installed today will work with GCC 4.9 if such a thing existed and were installed.

As we’ve noticed recently, this can cause problems, and now that we have clang releases and GCC releases with decent compatibility out in the wild (3.2 and 4.{6,7} resp.), I think we should take a different approach:

  1. Set a max GCC version we use, and on trunk have it be silly (v99.99.99).
  2. On the release branch, lower this to the highest GCC version we test that release against. This protects a released clang from using newer GCC libstdc++ which is both good and bad – no improvements from updates, but no breakage from updates.
  3. Teach the driver about incompatible versions of GCC and libstdc++, and have it try to find a different version when available. (Mostly relevant to 4.4 and 4.5 and C++11 headers…)
  4. Teach Clang itself to warn on a libstdc++ version macro which is one of the versions that has incompatibilities so users understand what is happening.

Thoughts?

Greetings all! This is the result of a chat between Richard and myself
just now.

These days Clang does a great job of detecting GCC and libstdc++
installations and using them... such a great job that Clang installed today
will work with GCC 4.9 if such a thing existed and were installed.

As we've noticed recently, this can cause problems, and now that we have
clang releases and GCC releases with decent compatibility out in the wild
(3.2 and 4.{6,7} resp.), I think we should take a different approach:

1) Set a max GCC version we use, and on trunk have it be silly (v99.99.99).
2) On the release branch, lower this to the highest GCC version we test
that release against. This protects a released clang from using newer GCC
libstdc++ which is both good and bad -- no improvements from updates, but
no breakage from updates.
3) Teach the driver about incompatible versions of GCC and libstdc++, and
have it try to find a different version when available. (Mostly relevant to
4.4 and 4.5 and C++11 headers...)
4) Teach Clang itself to warn on a libstdc++ version macro which is one of
the versions that has incompatibilities so users understand what is
happening.

Thoughts?

Seems totally reasonable here.

-eric

Makes sense to me, though I don't want to make the release process unreasonably complicated. Should we have the week before the release branch figure out #2 and (temporarily) set it on mainline?

-Chris

I would weaken it a bit by saying: only use a version higher than this hardcoded value if you couldn't find a safer one. Warn all you like (with -Wtoo-recent-libstdc++ on by default), but if there is only libstdc++-4.9 on my machine and clang refuses to even try to use it, that's a pain.

The max value could be overridden by a secret option to "configure".

-Krzysztof

I would weaken it a bit by saying: only use a version higher than this
hardcoded value if you couldn’t find a safer one. Warn all you like
(with -Wtoo-recent-libstdc++ on by default), but if there is only
libstdc+±4.9 on my machine and clang refuses to even try to use it,
that’s a pain.

The max value could be overridden by a secret option to “configure”.

-Krzysztof

Would an option be more suitable ? The problem of configure is that releases are also distributed as binaries…

Possibly, reusing -stdlib flag as -stdlib=libstc++v4.9.

– Matthieu