CXX-3300 update build-from-source minimum supported compiler versions #1415
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This PR proposes updating our minimum compiler version requirements:
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:
*this
" despite current usage.src/stdx/optional.hpp
.src/third_party/catch/include/catch.hpp
.src/bsoncxx/include/bsoncxx/v_noabi/bsoncxx/stdx/optional.hpp
.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 eitherCMAKE_CXX_STANDARD_REQUIRED=ON
orCMAKE_CXX_EXTENSIONS=OFF
(cmake/cmake#17068). The set of/Zc:
flags which are applied by default without/permissive-
(which togglesallmost 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:
rhel7.9-latest
.rhel80
.macos-14-arm64
.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:
and the libstdc++ doc's "Implementation Status" section states:
However, GCC 5 release notes state:
Note
As an aside, GCC 5 satisfies the C Driver's C99 conformance requirement:
GCC 6 is the first release whose notes declare full support for the C++11 standard:
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:
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:
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:
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:
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:
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.