Cannot build C++14 in docker images

[YannickJadoul]

Hello. I'm in the situation where I have a C++14 extension (using the brilliant (pybind11)[https://github.com/pybind/pybind11] library), but the GCC version installed on the docker images are 4.8 and do not support the C++14 standard.

Is there a way I can get around this, and would still be able to produce manylinux1 wheels?

[njsmith]

Unfortunately there aren't any compilers that both support c++14 and can generate manylinux1-compatible (= centos 5 compatible) builds.

However, there is a plan to define manylinux2 and manylinux3 standards based on centos6 and centos7, respectively. That's the most likely path to getting c++14 support. Currently there's no one actively working on this, because we're a volunteer run project and none of the existing contributors have the time right now, but it would be a pretty straightforward thing for someone to help with if you want. There's a rough checklist of what needs to happen in this email.

[YannickJadoul]

Thank you for this quick reply.
Hmm, given that I've been learning quite a lot about all this, over the last few days, I would indeed find it interesting to help (after digging into the internals of the first manylinux).

Meanwhile, while lacking such a newer standard, what would be the best way forward, on the short term? 'Downgrading' my C++14 code to 11, or building on another system (e.g., Travis CI's Ubuntu 12.04 (precise))?

[njsmith]

If you can downgrade your code to c++11, then that'll be the most reliable option, yeah. If you build on another system, then your wheels won't be manylinux1 compatible, and only manylinux1 wheels are allowed on pypi currently. Technically I suppose you could lie and label your wheels as being manylinux1-compatible when they aren't, but (a) that would be naughty, and (b) since pip uses the platform tag to determine which systems are compatible with which wheels, lying to it sets up a situation where some of your users may get broken installs. (Of course if you're not distributing these wheels publicly on pypi, then this matters much less.)

I think the manylinux2/3 to-do list is actually pretty approachable if you want to go that way; most of it should be possible to copy directly from the manylinux1 equivalents.

In any case, good luck!

[rmcgibbo]

If you're really careful, it might be possible to use a newer version of g++ with tricks like http://archive.is/wkKoy#selection-129.0-144.0 to generate manylinux1-compatible code, but it requires a pretty high degree of compiler kung fu.

[mpharrigan]

Can't you (1) install a new gcc in the docker container and then (2) just vendor libstdc++

[YannickJadoul]

@rmcgibbo Thanks, not sure how easy that is (though I'll pay around a little bit, next week), but it's a very nice read on the actual problem!

@mpharrigan The problem is that I can't find a GCC >= 5 for CentOS 5, so are you suggesting to build from source?

[njsmith]

Building a recent toolchain and then vendoring libstdc++ would indeed work AFAIK, though I don't know how easy it is.

[mpharrigan]

are you suggesting to build from source?

Yeah

[YannickJadoul]

Right, I'll give these different options a shot, over the course of the next week, and see what works best in my case.

[squeaky-pl]

I've built multilib GCC 6.3 for Centos 5 for Porable PyPy project: https://github.com/squeaky-pl/centos-devtools/releases

If you manage to convince manylinux docker image to use this compiler instead it might work.

You would need to untar it to your root and then use /opt/devtools-6.3/bin/<whatever>, possibly by tweaking PATH:

wget https://github.com/squeaky-pl/centos-devtools/releases/download/6.3/gcc-6.3.0-binutils-2.27-x86_64.tar.bz2 -O - | tar -C / -xj

[rmcgibbo]

@squeaky-pl: that's impressive. i'm eager to hear if it works for the manylinux case. if so, that would be fantastic.

[YannickJadoul]

Wow, this is brilliant! Unpacking and compiling seems to be working like a charm, on my local docker image.

However, I'm still running into a problem with auditwheel

[root@e46be390efb1 dist]# auditwheel show praat_parselmouth-0.1.0-cp27-cp27m-linux_x86_64.whl 

praat_parselmouth-0.1.0-cp27-cp27m-linux_x86_64.whl is consistent with
the following platform tag: "linux_x86_64".

The wheel references external versioned symbols in these system-
provided shared libraries: libgcc_s.so.1 with versions {'GCC_3.3.1',
'GCC_3.0'}, libstdc++.so.6 with versions {'CXXABI_1.3.5',
'CXXABI_1.3.9', 'CXXABI_1.3', 'GLIBCXX_3.4', 'GLIBCXX_3.4.18',
'GLIBCXX_3.4.20', 'CXXABI_1.3.3', 'GLIBCXX_3.4.21'}, libm.so.6 with
versions {'GLIBC_2.2.5'}, libpthread.so.0 with versions
{'GLIBC_2.2.5', 'GLIBC_2.3.2'}, libc.so.6 with versions
{'GLIBC_2.2.5'}

This constrains the platform tag to "linux_x86_64". In order to
achieve a more compatible tag, you would to recompile a new wheel from
source on a system with earlier versions of these libraries, such as
CentOS 5.

So, @squeaky-pl, is your GCC 6.3 also using a more recent version of CXXABI than the standard one on the manylinux1 CentOS 5?

[squeaky-pl]

I am not quite sure because I don't work with C++ at all. The compiler was compiled itself on Centos 5 but of course C++ standard library evolved quite a lot since GCC 4.8.

The PEP itself says:

GLIBC <= 2.5 <-- fine
CXXABI <= 3.4.8 <-- fine
GLIBCXX <= 3.4.9 <-- this looks violated
GCC <= 4.2.0 <-- fine

So probably this is libstdc++.so.6 that needs to be shipped somehow because it's tightly coupled with compiler/C++ standard version I guess, and probably the resulting wheel references libstdc++.so.6 from that /opt/devtools-6.3 subdir.

[squeaky-pl]

@YannickJadoul what about feeding -static-libstdc++ to the compiler/linker?

[YannickJadoul]

Hmmm, I don't know, but I can give that a shot tomorrow. But I'm guessing there's a reason this isn't that standard approach, or not? Any experience with what the size increase of the wheel would be?