Status of pip wheels with _GLIBCXX_USE_CXX11_ABI=1

[elias-work]

#17492 shows the history of this issue but it has been closed and buried for a long time. Torch pip wheels are compiled with _GLIBCXX_USE_CXX11_ABI=0, resulting in incompatibility with other libraries.

Is there any sort of status on this?

(Personal motivation: Our project takes many hours to compile because of needing to compile torch + dependencies from source. We can't link with the libraries from the pip wheel because of this issue, and forcing everything else to use _GLIBCXX_USE_CXX11_ABI=0 is a huge headache itself that will only result in more problems over time. Having _GLIBCXX_USE_CXX11_ABI=1 pip wheels would drastically simplify our, and I'm sure many others', builds).

cc @ezyang @gchanan @zou3519 @bdhirsh @jbschlosser @seemethere @malfet @walterddr @yf225 @glaringlee

[bdhirsh]

marking hi-pri due to user activity in the previous issue (which still seems unresolved)

[malfet]

I think the core problem is that _GLIBCXX_USE_CXX11_ABI=1 is not supported by compiler that is recommended by PEP513, see https://github.com/pypa/manylinux

[seemethere]

This is actually a bug that's been reported for RHEL / CentOS 7 (devtoolset-7): https://bugzilla.redhat.com/show_bug.cgi?id=1546704

Unfortunately if we want to provide manylinux support, which are binaries built on CentOS 7, then we can't support _GLIBCXX_USE_CXX11_ABI=1 in our wheels.

[elias-work]

My understanding is this is mostly an issue when you need to use torch with both python and C simultaneously. Is there a recommended "official/standard" way to get this setup work other than by building from source or wheel? It sounds like the only options are

• Special non-standard _GLIBCXX_USE_CXX11_ABI=1 wheels
• Conda package? (I heard some people say it has this flag, but I haven't tested yet).
• Build from source
• Install and use both libtorch and Python package (don't think it will work for us)

[mattip]

To add another clarification on top of the previous clarifications: even moving to the manylinux2014 spec would not work around the hard limitation mentioned above. The upcoming PEP 600 perennial multibuild standard might be the first that would support this, since it would move past CentOS7 (so obviously the wheels would not be expected to work on CenOS7). All the infrastructure is in place for a manylinux_2_24 standard based on glibc 2.24 (debian stretch). The work needed to build the docker images is currently in progress, here is one of the active tracking issues pypa/manylinux#877

[EricSteinberger]

What's the best workaround at the moment? I'm not familiar with building pytorch from source, but will of course dive into it if needed. I'm exporting a C++ .so library hoping to import it in Python. Works well on mac but running into this issue on Linux machines. Any tips on workarounds?

[mattip]

Would using the conda builds solve this problem?