CXX-3300 update build-from-source minimum supported compiler versions

[eramongodb]

Summary

This PR proposes updating our minimum compiler version requirements:

• GCC 4.8.2 -> GCC 8.1
• Clang 3.5 -> Clang 3.8
• Apple Clang 5.1 -> Apple Clang 13.1
• MSVC 19.0.23506 (VS 2015 Update 1) -> MSVC 19.0.24210 (VS 2015 Update 3)

Important

This PR only affects the build from source requirements. They do not apply to users compiling or linking against our libraries. They are not propagated by package config files, prebuilt libraries, or headers.

Note

This PR is focused only on compiler support for the C++11 standard. Newer standards are not in scope. Other features or improvements such as debugging, diagnostics, platform compatibility, and performance are not in scope.

Background

The current minimum compiler version requirements have not been substantially updated since their introduction in Jan 2016 (CXX-807) for the initial v3.0 release. They are long overdue for an update given changes to supported platforms and environments, EVG task coverage, C++ standard support by compilers, and the evolution of the codebase since these values were initially set.

The current state of minimum supported compiler versions are as follows.

GCC 4.8.2 (October 2013)

This GCC version "contains experimental support for the second ISO C++ standard (2011)", "most of which have been implemented in an experimental C++11 mode". Notably missing features include:

• "Rvalue references for *this" despite current usage.
  • First seen: January 2015 in src/stdx/optional.hpp.
• "Generalized attributes" despite current usage.
  • First seen (tests only): June 2020 in src/third_party/catch/include/catch.hpp.
  • First seen (library code): February 2024 in src/bsoncxx/include/bsoncxx/v_noabi/bsoncxx/stdx/optional.hpp.
• "Alignment support" despite prior usage (removed by 197e279).
  • First seen: Janurary 2015 in src/bson/util/stack.hpp.

In short, GCC 4.8 does not fully support the C++11 standard. Compatibility with GCC 4.8, including dealing with numerous compiler bugs, have repeatedly caused pain over the years (plenty just for the C++ Driver, but also for libmongocrypt and the C Driver).

Clang 3.5 (September 2014)

According to C++ Support in Clang, "Clang 3.3 and later implement all of the ISO C++ 2011 standard." There is not much to say here: there is no notable issues with this compiler version aside from the lack of minor conformance improvements which are implemented in newer releases.

Apple Clang 5.1 (March 2014)

The Apple Clang compiler version number only roughly corresponds to the Xcode version number. Additionally, the correspondance between Apple Clang and equivalent Clang/LLVM versions are also only roughly correlated, e.g. Apple Clang 5.1 corresponds to Clang 5.1, but uses LLVM 3.4. C++11 conformance documentation per release is lacking. The best we can do is assume support is consistent with the corresponding Clang version.

Tip

"Apple Clang" is the compiler (+ toolchain). Xcode is the IDE that provides Apple Clang.

MSVC 19.0.23506 (November 2015)

This version number corresponds to Visual Studio 2015 Update 1. The format is as reported by CMake's CMAKE_(C|CXX)_COMPILER_VERSION variable, derived from the _MSC_FULL_VER preprocessor macro. For clarity, the corresponding Visual Studio release version which (first) provides the given MSVC version will be mentioned alongside the MSVC version.

"Expression SFINAE" and "two-phase name lookup" are not supported until MSVC 19.14 (Visual Studio 2017). Tracking instances of these features in our codebase is difficult, but there are many cases of VS 2015 interfering with supposedly well-formed code (e.g. as far back as Jan 2016). All other "C++03/11 Core language features" are labeled as "Supported" since VS 2015. However, there are numerous conformance issues which are only toggled by the /permissive- flag, which is not enabled by either CMAKE_CXX_STANDARD_REQUIRED=ON or CMAKE_CXX_EXTENSIONS=OFF (cmake/cmake#17068). The set of /Zc: flags which are applied by default without /permissive- (which toggles all most of them) varies across MSVC releases.

Tip

"Microsoft Visual C++" (MSVC) is the compiler (+ toolchain). "Visual Studio" is the IDE that provides MSVC.

Note

We do not currently document or enforce minimum compatibility requirements for the "Windows SDK" or "Platform Toolset". However, the toolset version is included in the ABI tag suffix when built with MSVC.

Current Compilation Coverage

The lowest compiler versions (per CMake output) currently tested by our EVG config are:

• GCC 4.8.5 (June 2015) on rhel7.9-latest.
• Clang 7.0.1 (Sep 2023) on rhel80.
• Apple Clang 15.0.0 (Sep 2023) on macos-14-arm64.
• MSVC: 19.0.24223 (March 2019) on windows-vsCurrent.

Proposal

This PR proposes updating our minimum compiler version requirements to better match our actual requirements, to avoid continued backward compatibility support with long-unsupported compiler versions, and to hopefully help pave the way to refine our documentation for supported targets by specifying compiler version rather than specific operating system release versions (e.g. RHEL 7, Ubuntu 20.04, etc.). Support for specific operating systems would continue to (indirectly) inform our minimum supported compiler versions (e.g. see below concerning GCC on RHEL 7).

The proposed minimum compiler versions are as follows.

GCC 8.1 (May 2018)

The "C++ Standards Support in GCC" page states:

GCC 4.8.1 was the first feature-complete implementation of the 2011 C++ standard, previously known as C++0x.

and the libstdc++ doc's "Implementation Status" section states:

GCC 5.1 was the first release with non-experimental C++11 support, so the API and ABI of features added in C++11 is only stable since that release.

However, GCC 5 release notes state:

C++11 contains several changes to the C++ language, most of which have been implemented in an experimental C++11 mode in GCC.

Note

As an aside, GCC 5 satisfies the C Driver's C99 conformance requirement:

GCC has substantially complete support for this standard version; see http://gcc.gnu.org/c99status.html for details.

GCC 6 is the first release whose notes declare full support for the C++11 standard:

C++11 contains several changes to the C++ language, all of which have been implemented in GCC.

Therefore, GCC 6 is the minimum compiler version which fully satisfies our long-standing C++11 or newer requirement (at least, per GCC documentation). However, this PR proposes going further and raising the minimum to GCC 8 instead. RHEL also bumped their default provided toolchain from GCC 4.8 on RHEL 7 straight to GCC 8 on RHEL 8. For comparison with other Linux distros we currently support, Ubuntu 20.04 LTS provides GCC 9 by default (but GCC 8 is also available) and Debian 10 provides GCC 8 by default.

Tip

GCC uses a versioning scheme where X.0 is reserved for development and X.1 is the first minor version for the public release. Therefore, GCC 8.1 is the first official GCC 8 release version; there is no GCC 8.0. LLVM also started using this versioning scheme beginning with Clang 18.1.

The oldest particular operating system we currently need to continue supporting (per Drivers Maintainability & Compatibility Policy) is RHEL 7, which distributes GCC 4.8.x:

• RHEL 7 Docs: "10. Compiler and Tools"
• RHEL Knowledgebase: "What gcc versions are available in Red Hat Enterprise Linux?"
• RHEL Customer Portal: "Product Life Cycle of Red Hat Software Collections for Red Hat Enterprise Linux 7"

However, MongoDB Server's support for RHEL 7 concerns the use of prebuilt binaries which target the operating system's environment. It is not support for building the server from source on RHEL 7 as a host. On the other hand, the C++ Driver's support for RHEL 7 currently requires being able to build on RHEL 7 as a host, as we do not yet support a strategy for prebuilt binary distribution or cross-compilation.

Therefore, rather than continuing to support GCC 4.8 due to RHEL 7 compatibility, this PR proposes that we instead require users who build the C++ Driver libraries from source on RHEL 7 to install a "Red Hat Developer Toolset" (DTS) which provides a sufficiently recent GCC compiler version that satisfies our minimum requirements. According to multiple official Red Hat articles, the ability to install GCC 8 on RHEL 7 via DTS is an expected workflow:

• "Hello World - installing GCC on RHEL 7" (Feb 2019)
• "How to install GCC 8 and Clang/LLVM 6 on Red Hat Enterprise Linux 7 " (Mar 2019)
• "Developer Toolset 8.1 and GCC 8.3 now available for Red Hat Enterprise Linux 7" (Jun 2019)

Note

Red Hat Developer Toolsets (e.g. devtoolset-N) are EOL. The latest version, DTS 12, was "retired" in June 2024. They have been succeeded by "GCC Toolsets" (e.g. gcc-toolset-N-toolchain) which are distributed via Red Hat Software Collections (RHSCL).

Note

The Linux Kernel recently (May 2025) updated their own minimum required compiler version from GCC 5 to GCC 8. The minimum was raised from GCC 4.9 to GCC 5 in Sep 2021. GCC 4.8 was dropped in July 2020 with this relatable comment:

The latest (in a long string) of reasons for minimum compiler version upgrades was commit 5435f73d5c4a ("efi/x86: Fix build with gcc 4"). Ard points out that RHEL 7 uses gcc-4.8, but the people who stay back on old RHEL versions persumably also don't build their own kernels anyway. And maybe they should cross-built or just have a little side affair with a newer compiler?

Clang 3.8 (March 2016)

Although Clang 3.5 seems to fully support the C++11, I would like to propose raising it to 3.8 anyways for the following reasons:

• libc++ 3.8 is the oldest release for which I can find doc pages which state "C++11 Support: Complete".
• Clang 3.8 includes some minor C++11 conformance improvements. This applies to Clang 3.9, not Clang 3.8.

Even though our current compilation task coverage only goes back as far as Clang 7.0, I do not think we need to raise the minimum requirement to exactly match our current coverage for this case. Therefore, I think Clang 3.8 is a reasonable interim requirement. That being said, if we want to raise the Clang version to one that is comparable to GCC 8 w.r.t. recency, Red Hat suggests Clang 6 (March 2018) may be a good pick.

Note

Clang 5.0 is the last release which defaults to -std=gnu++98 (changed to -std=gnu++14 in Clang 6.0) and the first release to fully support the C++17 standard. When the minimum required C++ standard is eventually raised to C++17, this would be a good corresponding minimum required Clang version.

Apple Clang 13.1 (October 2021)

To match the Clang 3.8 requirement, the minimum required equivalent version would be Apple Clang 4.5 (Xcode 4.5 on Mac OS X 10.7). However, we deprecated support for MacOS 12 and older in the 4.1.0 release (CXX-3194) and plan to drop them in an upcoming release (CXX-3193). This means the oldest Apple Clang version we actually need to support is really Apple Clang 13.1.6 (with Xcode 13.4.1 on MacOS 13), which corresponds to Clang 13.1.6 (with LLVM 13.0). This minimum requirement should suffice for now until we drop support for MacOS 13 as well after it reaches EOL. Upgrading from Xcode 5.1 to Xcode 13 will include several C++11 conformance improvements.

Note

Xcode 13 is apparently too old to be worth mentioning under "Other Xcode versions" in their Xcode versions list. However, the release notes page lists Xcode 10.0 and newer.

MSVC 19.0.24210 (June 2016)

This corresponds to "Visual Studio 2015 Update 3", the latest and last release for Visual Studio 2015. This is just an interim update before we drop support for VS 2015 entirely with CXX-3215 (EOL on Oct 2025). The bump from Update 1 to Update 3 includes:

• Update 2:
  • "Enhanced support" for C++11.
  • "More than 300 compiler bugs" fixed.
  • Full implementation of C++11 relative to N4567 (Nov 2015).
• Update 3:
  • Some C++11 conformance improvements (trivial copy/move ctors, std::is_convertible).

The next bump would be up to MSVC 19.10.25017 (Visual Studio 15.0 2017). Aside from some improvements to expression SFINAE and two-phase name lookup in MSVC 19.14 (Visual Studio 15.7 2017), I do not think there any need to raise the minimum any higher until the minimum required C++ standard is raised to C++14 or newer.

[kevinAlbs]

The thorough research is much appreciated. LGTM.

[eramongodb]

Added a missing import (followup to #1413) to address EVG config generator errors. Included a temporarily disabling of RHEL 7.9 tasks to avoid task failures until DEVPROD-18187 is resolved.