how should _GLIBCXX_USE_CXX11_ABI be set for manylinux2014 and manylinux2010 wheels? For manylinux1 wheels the common wisdom was to set it to 0 as far as I know (but not sure if that was ever formally specified). According to PEP571 and PEP599, manylinux1 wheels are considered manylinux2010 wheels, which are considered manylinux2014 wheels. This seems to suggest that _GLIBCXX_USE_CXX11_ABI should also be 0 for those wheels or we might risk problems.
There was some discussion in https://github.com/pytorch/pytorch/issues/51039 where folks also had this interpretation and TensorFlow is also setting it to 0. My understanding is that Apache Arrow is setting it to 1 but I’m not sure about that. I hope to get clarity from you all on what the expectation is to make sure the Python community is producing wheels that are compatible with each other
Of course if the answer is _GLIBCXX_USE_CXX11_ABI=0, it would be great to have a plan to migrate to the modern ABI at some point.
My first reaction would be that I’m not sure if there is a need for a community convention. Is it a problem if different wheels use a different setting?
That’s a very good question! In the past, we have seen subtle incompatibilities for different toolchains, some of these were summarized very well in How we build Apache Arrow’s manylinux wheels | Uwe’s Blog (including problems around _GLIBCXX_USE_CXX11_ABI).
As I commented elsewhere, a manylinux2010- or manylinux2014-compliant wheel must use _GLIBCXX_USE_CXX11_ABI=0. However manylinux2_24 and up can support c++11. Unfortunately manylinux2_24 is stalled on building a modern gcc. Help there is welcome. For an overview of what glibc is supported on what distro, and what manylinux can use, see the PEP 600 compliance table.
Thanks a lot for the pointer. Your phrasing seems a bit misleading, though. A manylinux201x-compliant wheel can actually use whatever setting it wants for that variable, because the compiler in the official build image will simply ignore the setting and use the old ABI.
The question asked here is a bit different, though. Imagine one circumvents the Redhat/CentOS issue that prevents from using that flag, which value may be preferred, and are there any runtime issues with either?
These have to do with a non-standard usage of wheels, though: when people try to link their own C++ code against the C++ libraries shipped in a binary wheel. While it is nice to be able to do this, it’s certainly a non-goal for the manylinux specs.
This probably also ties into the PEP 600 “play well with others” rule, manylinux wheels are expected to take a most-compatible-possible approach to questions like this. But I have no idea what that would mean in practice…
NumPy, Tensorflow, PyTorch, OpenCV all ship libraries in the wheels that are explicitly meant to be linked to by downstream code. Any shared object in linux can be a link target, so any c-extension module could be linked into other code. The manylinux1 policy expressly lists libstdc++.so.6, so I would assume that is the version of libstdc++.so.6 that ships with the base distros of the manylinux1 image, which does not support c11.
are there any runtime issues
Yes. A wheel compiled with c11 will not load on a system that does not support it, the user will see an error like c10::Error::Error(std::__cxx11::basic_string....
The Numpy API is a C API. Binary interoperability of C libraries is a feature of manylinux wheels by construction, since wheels have to compile and link with the CPython C API. The same cannot be said of C++ libraries.
Isn’t this topic about manylinux2010 and manylinux2014? manylinux1 is obsolete at this point, and I don’t think there’s much point in discussing it.
Again, this is a bit imprecise and confusing. Surely you mean “a wheel compiled with the new libstdc++ ABI enabled”. But that’s not possible using standard tools, AFAICT, since it’s forcefully disabled by the CentOS 7 devtoolset.
You can very much use C++11 in a manylinux wheel, though, and many packages do so.
