构建 manylinux Python 轮子

有许多基于 GNU/Linux 代码库构建的操作系统；这些被称为“发行版”。用户喜欢（或有时不太喜欢）谈论“发行版战争”：通常在互联网上进行的关于哪个发行版最好的激烈争论。

每个发行版的社区都会自行决定包含哪些库版本以及支持多长时间。这对于只想分发包含本机代码的 Python 库的人来说是一个挑战。为 Red Hat、SUSE、Ubuntu 和 Debian 构建单独的二进制文件将是一项繁重的工作——为每个受支持的版本构建单独的二进制文件更是如此！

幸运的是，有一种方法可以使二进制文件与大多数（但不是全部）Linux 发行版兼容。它依赖于大多数发行版（包括上述所有发行版）都使用 GNU C 库这一事实。GNU C 库使用一种特殊的二进制兼容性方法，通过在 ELF libc.so 动态库内部保留符号的所有版本。

Python 的 manylinux 方法通过有意在旧版本的发行版上构建二进制可再发行包（又名 wheel）来利用这一点。为了实现最大的兼容性，它使用了支持时间最长的免费可分发 Linux 版本：CentOS。

目前，manylinux 构建于 CentOS 5 之上，这意味着它支持主要发行版的每个非生命周期结束版本。它通过使用专门的 Docker 镜像 manylinux1 镜像来实现这一点。Python 的次要版本仍然需要单独的二进制文件：对于大多数库来说，这意味着 3.5、3.6 和 3.7。从理论上讲，我们还需要针对不同的 CPU 字长 提供单独的二进制文件，但实际上，仅支持 64 位可能就足够了。同样，从理论上讲，对于构建 Unicode 支持的不同方式，也需要不同的二进制文件；但在实践中，主要的 Linux 发行版始终以“宽 Unicode”构建 Python。

Docker 镜像可在 quay.io/pypa/manylinux1_x86_64 上获取。它在 /opt/python 中有 Python 版本。具有宽 Unicode 的版本是名称以 mu 结尾的版本：例如，/opt/python/cp36-36mu。这些 Python 版本已经安装了 pip 以及 wheel 构建支持。这意味着如果代码被挂载或复制到 Docker 容器的 /src 中，

mkdir /output
/opt/python/cp36-36mu/pip wheel /src -w output

将在 /output 中生成一个二进制 wheel。但是，这仍然不会是一个 manylinux wheel，因为它有可能构建意外依赖于其他库的 wheel。

auditwheel 工具将获取该 wheel，对其进行审核，并将其复制到 manylinux 名称

auditwheel repair /output/mylibrary*whl -w /output

repair 模式还将任何其他库捆绑到 wheel 中，以确保它可以移植到任何需要的发行版。现在可以安全地将 /output/mylibrary*manylinux*whl 从 Docker 容器中复制出来并上传到 PyPI。请注意，PyPI 会拒绝特定于发行版的二进制 wheel，但会很高兴地允许上传 manylinux wheel。如果您使用的是私有索引，情况可能也是如此，尽管您可能需要与管理员确认。