How to handle C++?

[gqmelo]

First of all I think this initiative is amazing and really hope this will make portable Linux binaries trivial.

I've had some experience with this on the company I work for. Basically we came up with the same solution, except that we compile under a CentOS 5 chroot.

But one of the problems we faced was libstdc++. We also use gcc 4.8.5, which means the libstdc++ version is 3.4.19.

CentOS default libstdc++ is 3.4.12, therefore if you are compiling C++ code using this approach, you might have to run the executable only on CentOS 7 and earlier.

So the most obvious solution would be to just ship libstdc++. This is what we did, but then we got missing symbols on recent Linux distributions because they have a libstdc++ newer than 3.4.19, and some crucial system libraries (specially OpenGL implementations) were linked against it.

Not the most beautiful solution, but we ended up having to create an initialization script that would check which version is newer (the shipped or system one), and set LD_LIBRARY_PATH to the shipped one if necessary.

I know that most of base libraries are written in C, but even though I think this is an important issue, specially if someone is using OpenGL (I know that at least Mesa and Nvidia proprietary implementation use C++).

So have anyone else thought about this problem?

[njsmith]

So have anyone else thought about this problem?

Luckily, it turns out that Redhat have thought about this quite a bit!

The default compiler on the manylinux docker image is (a third-party rebuild of) the Redhat "developer toolset", which is a version of gcc 4.8 that's been modified to produce binaries that run against libstdc++.6.0.8 or later; so they work on RH/CentOS 5 and anything newer than that (which is basically everything).

(I'm not sure what these 3.4.* version numbers are?)

The way this works internally is some sort of arcane hackage where the linker decides for each symbol whether it's an old symbol that's available everywhere so it can be dynamically linked, or a new symbol that isn't available everywhere in which case it statically links that symbol. It's possible that this trickiness might cause some problems in some edge cases, but it's definitely what I'd try first.

[gqmelo]

The default compiler on the manylinux docker image is (a third-party rebuild of) the Redhat "developer toolset", which is a version of gcc 4.8 that's been modified to produce binaries that run against libstdc++.6.0.8

Great! I did not know that. Normally is not easy to make gcc use a different libstdc++.
Then the only problem would be C++ code that need some newer C++ features, but I think this would be even rarer, so I will close the issue for now.

I'm not sure what these 3.4.* version numbers are?

These are just the internal version used by libstdc++ symbols according to GCC ABI Policy

[njsmith]

GCC 4.8 gets you to c++11. If you need c++14 then things get trickier. There are later versions of the devtoolset compilers, but they only target centos/rh 6. But centos/rh 5 is getting eoled in less than a year, so moving to 6 as a minimum baseline is probably your best bet.

FYI the wheel-builders mailing list at Python.org is probably a better place for such discussions -- I'm mostly summarizing things discussed there, and there are more people paying attention.

[gqmelo]

Thank you, I'll take a look at the mailing list.