Building Linux binaries in non-manylinux containers?

Python Help
1

The manylinux/musllinux Docker containers don’t really match my needs.

details for the curious

  • Our binaries aren’t linked against the Python ABI so I only need one Python installation. The other 9 + uv are all just a very large dead weight.
  • The Red Hat Developer Toolset in combination with qemu keeps breaking in strange ways. Currently the ppc64le variants can’t even compile a hello world C program! (This is compounded by the image size since the first thing I normally try is upgrading the base image.)
  • The use of a custom compiler prefix means that installing extra C libraries is a lot harder than a vanilla package_manager install zlib-dev.

I’d like to switch to more vanilla base images of equivalent libc vintages. For example, we currently target manylinux2014 (contains glibc 2.17) and musllinux_1_1 (based on Alpine 3.12) so I’d switch to using ubuntu:18.04 (which also contains glibc 2.17) and alpine:3.12 as base images.

I was wondering if anyone sees anything I’d be losing by doing this (mostly interested in security implications)? I know that without the Red Hat Developer Toolset I’d be using an old version of gcc but I don’t see why that really matters? Our code is C90 compatible and it’s not bottleneck code so it doesn’t bother me if we miss out on some newer compiler optimisations. There’s a defaults switch from -pie to -no-pie we’re watching out for but that’s easily solvable…

2

I can’t think of any security issues (code that doesn’t run at all is perfectly secure!). I think the issues from not using manylinux will be lack of cross linux distro compatibility.

If you provide your binaries in the docker containers they’re built in, and intended to be run in, that’s not necessarily a problem. But it limits your potential user base. And increases the potential for nuisance bug reports from users on incompatible distros, in future.

The nitty gritty problems with c libraries and compiler versions do lead me to suspect code smells, however. Ones that could be easily mitigated be shipping in docker container. But maybe that’s a sticking plaster, and those smells just shouldn’t be there in the first place.

3

That shouldn’t be an issue if I choose base images with libc versions matching the current manylinux ones?

4

“Shouldn’t”

I’m sure it’s possible to get away with it. But I thought some guarantee of compatibility, was the entire point of building in a manylinux image.

5

Well I guess that’s partly my question: what exactly are do the various aspects of the manylinux images bring to make them special? My understanding of them is:

  • The old LTS base image prevents you from linking against too new libraries
  • The umpteen copies of Python enable Python extension module builders to easily build for all Python versions
  • The RH Toolset gives modern (ish) build tools because… we can? … because we expect some projects to unbuildable with gcc 4?
  • That’s it?

Is that accurate?

1 Like