跨发行版Linux wheels
项目描述
审核和重新标记PEP 600 manylinux_x_y、PEP 513 manylinux1、PEP 571 manylinux2010和PEP 599 manylinux2014 Linux轮文件。
概述
auditwheel是一个命令行工具，用于简化创建Linux（包含预编译的二进制扩展）兼容多种Linux发行版的Python wheel包，符合PEP 600 manylinux_x_y、PEP 513 manylinux1、PEP 571 manylinux2010和PEP 599 manylinux2014平台标记。
auditwheel show：显示轮依赖的外部共享库（超出manylinux策略中包含的库），并检查扩展模块对超出manylinux ABI的符号版本的使用。
auditwheel repair：将这些外部共享库复制到轮文件中，并自动修改适当的RPATH条目，以便在运行时选择这些库。这实现了与将库静态链接相同的效果，而无需修改构建系统。建议打包人员注意，类似于静态链接，打包可能会引发版权问题。
需求
OS：Linux
Python：3.8+
patchelf: 0.14+
仅支持使用基于ELF链接的系统（这应该是几乎所有Linux系统）。
通常，构建manylinux1轮文件需要在CentOS5机器上运行，构建manylinux2010轮文件需要在CentOS6机器上运行，构建manylinux2014轮文件需要在CentOS7机器上运行，因此我们建议使用预构建的manylinux Docker镜像，例如。
$ docker run -i -t -v `pwd`:/io quay.io/pypa/manylinux1_x86_64 /bin/bash
安装
auditwheel可以使用pip安装
$ pip3 install auditwheel示例
检查轮文件
$ auditwheel show cffi-1.5.0-cp35-cp35m-linux_x86_64.whl
cffi-1.5.0-cp35-cp35m-linux_x86_64.whl is consistent with the
following platform tag: "linux_x86_64".
The wheel references the following external versioned symbols in
system-provided shared libraries: GLIBC_2.3.
The following external shared libraries are required by the wheel:
{
"libc.so.6": "/lib64/libc-2.5.so",
"libffi.so.5": "/usr/lib64/libffi.so.5.0.6",
"libpthread.so.0": "/lib64/libpthread-2.5.so"
}
In order to achieve the tag platform tag "manylinux1_x86_64" the
following shared library dependencies will need to be eliminated:
libffi.so.5
修复轮文件。
$ auditwheel repair cffi-1.5.2-cp35-cp35m-linux_x86_64.whl Repairing cffi-1.5.2-cp35-cp35m-linux_x86_64.whl Grafting: /usr/lib64/libffi.so.5.0.6 Setting RPATH: _cffi_backend.cpython-35m-x86_64-linux-gnu.so to "$ORIGIN/.libs_cffi_backend" Previous filename tags: linux_x86_64 New filename tags: manylinux1_x86_64 Previous WHEEL info tags: cp35-cp35m-linux_x86_64 New WHEEL info tags: cp35-cp35m-manylinux1_x86_64 Fixed-up wheel written to /wheelhouse/cffi-1.5.2-cp35-cp35m-manylinux1_x86_64.whl
限制
auditwheel 使用 Python 扩展模块的 DT_NEEDED 信息（类似于 ldd）来确定它们依赖于哪些系统库。使用 ctypes / cffi（来自 Python）或 dlopen（来自 C/C++）在运行时动态加载库的代码不会以可以静态确定的方式包含这些信息，因此通过这些机制加载的依赖项将会被遗漏。
如果程序是在过新的 libc 或 libstdc++ 版本编译和链接的，我们无法对其进行“修复”。这些库（以及一些其他库）使用符号版本化来实现向后兼容性。一般来说，这意味着针对旧版本 glibc 编译的代码在新版本 glibc 系统上可以正常运行，但新系统上编译的代码在旧系统上可能无法运行或可能无法运行。
因此，为了编译广泛兼容的二进制文件，最佳做法是在旧的 Linux 发行版上构建，例如许多 Linux 的 Docker 镜像。
测试
可以使用 nox 运行测试，它将自动安装测试依赖项。
一些集成测试还要求运行并可访问的 Docker 守护进程。如果这些镜像在您的系统上尚未可用，则这些测试将拉取多个 Docker 镜像，但不会更新现有镜像。要手动更新这些镜像，请运行
docker pull python:3.8-slim docker pull quay.io/pypa/manylinux1_x86_64 docker pull quay.io/pypa/manylinux2010_x86_64 docker pull quay.io/pypa/manylinux2014_x86_64 docker pull quay.io/pypa/manylinux_2_28_x86_64
您还可以使用 docker rmi 删除这些镜像。
行为准则
所有与 auditwheel 项目代码库、问题跟踪器、聊天室和邮件列表互动的人士都应遵守 PSF 行为准则。
