manylinux VS auditwheel

I use manylinux containers as the OS for compilation. It tries to ensure as much cross-os / libc / etc.. as much as possible for precompiled libraries. https://github.com/pypa/manylinux

Just to clarify for anyone who isn't aware, the "compiling issues", at least historically, have been that that Alpine uses musl, and PyPI's manylinux wheels are built against old glibc versions. So stuff like numpy that would trivially and quickly install from whl on glibc distros (like a bare-bones Ubuntu image) trigger compilations and the installation of build-only dependencies on Alpine.

That said, it looks like as of late-2021, at least some projects are offering musllinux wheels as well, per the discussion here: https://github.com/pypa/manylinux/issues/37 (not numpy, though: https://pypi.org/project/numpy/#files)

It's very hard. Incompatible glibc ABIs make this nigh impossible, there's a reason Steam installs a vcredistributable.dll for pretty much every game on Windows.

Look no further than the hoops you need jump through to distribute a Linux binary on PyPI [1]. Despite tons of engineering effort, and tons of hoop jumping from packagers, getting a non-trivial binary to run across all distros is still considered functionally impossible.

[1]: https://github.com/pypa/manylinux

As a user, if you build every python package from source, it's ok. But if you a maintainer of an OSS project and you need to publish binary packages for it, then you will hit the trouble. Binaries built on Ubuntu 20.04 can only support Ubuntu 20.04 and newer. So you'd better to choose an older Linux release to target broader users. Now most python packages choose CentOS 6 or 7. See https://github.com/pypa/manylinux/issues/1012 for more details. They need help!

I recently learned that Clang supports this kind of cross-compiling out of the box. https://mcilloni.ovh/2021/02/09/cxx-cross-clang/

The main difference is that Clang does not ship with headers/libraries for different platforms, as Zig appears to do. You need to give Clang a "sysroot" -- a path that has the headers/libraries for the platform you want to compile for.

If you create a bunch of sysroots for various architectures, you can do some pretty "easy" cross-compiling with just a single compiler binary. Docker can be a nice way of packaging up these sysroots (especially combined with Docker images like manylinux: https://github.com/pypa/manylinux). Gone are the days when you had to build a separate GCC cross-compiler for each platform you want to target.

Now you come and use manylinux to build. (https://github.com/pypa/manylinux) so you are based on the CentOS 7 toolchain (at best if you use manylinux2014) or Debian 9 toolchain (if you use manylinux_2_24).

I think the generally accepted way to do that would be a container image running a relatively old distribution. This is exactly what python packages do when they need to distribute binary packages on linux [0]. You are supposed to compile the package in a container (or VM) that runs CentOS 7 (or older if you want broader support), although now the baseline is moving gradually to Debian 9.

[0]: https://github.com/pypa/manylinux

Hi there! I've recently spent a lot of time figuring out how to distribute tools written in Python as standalone, self-contained executables, that will works on most of the linux distribution without special environment (including python itself). Decided to write this post to share and discuss my approach. I'd be grateful for any feedback and help on that topic! Here are a few simple steps I've come up with to make this trick: 1) This first is very obvious - use special tooling that can make such an executable, like Nuitka, Pyoxidizer, PyInstaller, python-appimage, etc. 2) Build your application against old enough glibc. You can do this using some old Linux distribution or just be setting up such toolchain manually. Its matters for c extensions, tools like nuitka/pyoxidizer and the python itself. 3) Last but not least - don't forget about dependencies and the dependencies of your dependencies. All Python wheels should have either an `any` [platform tag](https://packaging.python.org/en/latest/specifications/platform-compatibility-tags/) or one of the [manylinux](https://peps.python.org/pep-0600/) tags that suits your requirements. You can check tags and repair the bad ones with [auditwheel](https://github.com/pypa/auditwheel). But fortunately, in the last 5-10 years, most of the mainstream packages have received manylinux wheels. Of course, there will be issues with PyOxidizer/Nuitka/pyinstaller/etc pitfalls, especially with big projects, so you need some e2e tests in every Linux you want to support. For educational purposes, I made [this little repo](https://github.com/asapelkin/overpackaged). It includes: 1) A sample app with bad dependencies and a C extension. 2) A script to create a 'wheelhouse' with compatible wheels only (`manylinux*` and `any`). 3) Scripts to build executables using Nuitka, PyOxidizer, Appimage, pex. 4) Portability tests (run executables in different linux distros) and performance benchmarks. 5) Readme and Makefile to run any step with single command. It's obviously not a very useful repo, but at least it helped me to explore this topic a little, maybe it could help to demonstrate my approach to the topic.

In a similar vein: Python projects can use `auditwheel` to automatically relocate (fixup RPATHs) and vendor their "system" dependencies, such as a specific version of `zlib` or `libffi`[1].

[1]: https://github.com/pypa/auditwheel

I was using manylinux as it was suggested by its example and it gathered the libraries via auditwheel and included them into the package. Up to my knowledge, there is no way to exclude libraries from the package, because it cannot have external dependencies apart from the predefined list of libraries. The linux_*.whl tags cannot be used on PyPI for binary packages.