Plans to support C++20?

[motiwari]

Hi, are there any plans for cibuildwheel to support extensions written in C++20? I searched this repository as well as the documentation, but the "Modern C++ Standards" page only references C++17

[henryiii]

cibuildwheel doesn't "support" C++ standards, technically. It depends on the OS:

• Windows: This depends on what version of MSVC you use. We do mention caveats to watch for, but there shouldn't really be much related to C++ version.
• macOS: This depends on the minimum macOS you target. 10.12-10.14 was were most C++17 support was added, so I'd suspect +3, that is, 10.15-12 would be the minimum for C++20, but C++20 was much larger than 17, so it's probably larger than that (and Apple's been busy with other things).
• Linux: This depends on manylinux, see below.

You can see pypa/manylinux for the manylinux one, but the current status is manylinux1 has gcc 4.8 (C++11), manylinux2010 has gcc 8 (C++17), manylinux2014 has gcc 10 (C++17), and manylinux_2_24 has gcc 6 (C++14). Due to the loss of CentOS LTS releases, manylinux_2_24 uses Debian, so it does not have access to the RedHat Developer Toolkit, which backported modified GCC versions to older glibc. So we are loosing C++17 rather than gaining C++20 there.

(NumPy was really pushing for manylinux_2_24 for better glibc special architecture support, but then found that that the downgrade to GCC 6 couldn't support what they needed on those architectures!)

[henryiii]

Also, I'm not sure when RedHat stops updating GCC for RHEL 7, it might still get an update to 11 or 12, which I think is roughly C++20. But that's going to be manylinux2014, not manylinux_2_24 and beyond.

[motiwari]

Thanks @henryiii for the detailed response! To make sure I understand correctly: cibuildwheel is not responsible for what C++ standards can be supported in the source code, rather, it's the compiler and OS used for the cibuildwheel commands that must support the relevant C++ standard. Support for building a wheel for code written in C++20 varies across build OS, is rather limited in Linux, and may restrict target OSes because the target OS will need C++20-compatible versions of all dynamically linked libraries. Is that all correct?

[henryiii]

Close. Each OS is different. Your discription is correct for Windows. Build on a newer compiler, use newer features. They are careful (for the most part, you can see our FAQ's for an exception) to only require the same linked library (since MSVC 2013 or something like that).

For macOS, people usually build with the latest Xcode (+/- a year, perhaps), but you have to set a target minimum macOS version, and that controls what linked features you can use (templated code is generally fine, so some bits of newer standards work). Your compiler will tell you if you use something that links to something not available in the target macOS version - this consistency is one benefit of a single company controlling the toolchain!

But Linux is totally different. There you build on docker images - these are completely controled (https://github.com/pypa/manylinux). You can see exactly what GCC version is available for each image. For the older CentOS based images, RedHat produced special patched versions of GCC that would statically link features that were not available in the original supported GCC version; this was a "best of both worlds" - you could use a newer GCC but still benefit from dynamically linking most of your code, only the new parts were statically linked. We lost that when RedHat acquired CentOS and then killed off LTS support.

If you really want to, you can build a brand new GCC version inside a manylinux container (GCC 8 or 9 was the last version to support CentOS 5 / manylinux1, but the newer ones are likely still supported), then statically link to libstdc++; this will make much larger binaries but should allow you to use anything you want. I think.

[motiwari]

Thank you @henryiii , that's extremely helpful! You also preempted my next question, which is whether it would be possible to build a newer GCC inside manylinux that supports C++20. If I can get this to work, I'll report back here for the community.

[henryiii]

If it helps, see https://github.com/scikit-hep/manylinuxgcc where I've done that with manylinux1 and GCC 9.

[alugowski]

Note that C++ standards aren't all or nothing; it often takes several compiler major versions to "fully" support a standard. cppreference's compiler support table suggests most C++20 features are supported by GCC 10. That suggests manylinux2014 is likely enough.