解决auditwheel repair过程rpath被修改的问题
在开源Python项目中，如果使用到了Cython或者CUDA C++等需要编译的后端技术，那么要传到pypi上就需要经过一个PEP标准的审查。要通过审查，就要经过多个版本的Python的构建，以及auditwheel修复的过程。本文解决了一个auditwheel修复过程中有可能出现的rpath路径索引问题。
问题背景
AuditWheel是一个用于修复Python的whl包的工具，例如在这个CyFES开源库中，因为使用到了Cython和CUDA编译动态链接库的技术，方便Python调用。但是在编译CUDA算子时如果使用到了运行时库，那么在第一步构建whl包的时候不会自动包含运行时库，而第二步使用auditwheel进行whl包修复的时候，会自动把运行时库相关的动态链接库拷贝到whl包中。首先看一下修复前的whl包的目录树：
$ unzip -l dist/CyFES-2.7-cp37-cp37m-linux_x86_64.whl
Archive: dist/CyFES-2.7-cp37-cp37m-linux_x86_64.whl
Length Date Time Name
--------- ---------- ----- ----
2071 2024-09-02 07:54 CyFES-2.7.data/data/cyfes/FES.cuh
1731 2024-08-27 02:47 CyFES-2.7.data/data/cyfes/FES_f32.cuh
692112 2024-09-02 09:38 CyFES-2.7.data/data/cyfes/libcufes.1.so
55472 2024-09-02 09:38 CyFES-2.7.data/data/cyfes/libcufes.so
1628 2024-09-02 07:54 cyfes/__init__.py
6117 2024-09-02 07:54 cyfes/__main__.py
3632 2024-08-16 06:52 cyfes/utils.py
1457723 2024-09-02 09:38 cyfes/wrapper.c
1545248 2024-09-02 09:38 cyfes/wrapper.cpython-37m-x86_64-linux-gnu.so
1245635 2024-09-02 09:38 cyfes/wrapper_f32.c
1213984 2024-09-02 09:38 cyfes/wrapper_f32.cpython-37m-x86_64-linux-gnu.so
2071 2024-09-02 07:54 cyfes/kernels/FES.cuh
1731 2024-08-27 02:47 cyfes/kernels/FES_f32.cuh
0 2024-08-29 07:45 cyfes/kernels/__init__.py
1063 2024-09-02 09:38 CyFES-2.7.dist-info/LICENSE
5588 2024-09-02 09:38 CyFES-2.7.dist-info/METADATA
104 2024-09-02 09:38 CyFES-2.7.dist-info/WHEEL
6 2024-09-02 09:38 CyFES-2.7.dist-info/top_level.txt
1569 2024-09-02 09:38 CyFES-2.7.dist-info/RECORD
--------- -------
6237485 19 files
这里只有动态编译构建过程中生成的libcufes.so和wrapper动态链接库文件。再看看使用auditwheel repair修复之后的whl包目录树结构：
$ unzip -l fix-dist/CyFES-2.7-cp37-cp37m-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
Archive: fix-dist/CyFES-2.7-cp37-cp37m-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
Length Date Time Name
--------- ---------- ----- ----
0 2024-09-02 09:39 cyfes/
0 2024-09-02 09:39 CyFES-2.7.data/
0 2024-09-02 09:39 CyFES-2.7.dist-info/
0 2024-09-02 09:39 CyFES.libs/
0 2024-09-02 09:39 cyfes/kernels/
1457723 2024-09-02 09:39 cyfes/wrapper.c
1213984 2024-09-02 09:39 cyfes/wrapper_f32.cpython-37m-x86_64-linux-gnu.so
6117 2024-09-02 09:39 cyfes/__main__.py
1564760 2024-09-02 09:39 cyfes/wrapper.cpython-37m-x86_64-linux-gnu.so
1628 2024-09-02 09:39 cyfes/__init__.py
3632 2024-09-02 09:39 cyfes/utils.py
1245635 2024-09-02 09:39 cyfes/wrapper_f32.c
0 2024-09-02 09:39 cyfes/kernels/__init__.py
2071 2024-09-02 09:39 cyfes/kernels/FES.cuh
1731 2024-09-02 09:39 cyfes/kernels/FES_f32.cuh
0 2024-09-02 09:39 CyFES-2.7.data/data/
0 2024-09-02 09:39 CyFES-2.7.data/data/cyfes/
63696 2024-09-02 09:39 CyFES-2.7.data/data/cyfes/libcufes.so
692112 2024-09-02 09:39 CyFES-2.7.data/data/cyfes/libcufes.1.so
2071 2024-09-02 09:39 CyFES-2.7.data/data/cyfes/FES.cuh
1731 2024-09-02 09:39 CyFES-2.7.data/data/cyfes/FES_f32.cuh
150 2024-09-02 09:39 CyFES-2.7.dist-info/WHEEL
1063 2024-09-02 09:39 CyFES-2.7.dist-info/LICENSE
1784 2024-09-02 09:39 CyFES-2.7.dist-info/RECORD
6 2024-09-02 09:39 CyFES-2.7.dist-info/top_level.txt
5588 2024-09-02 09:39 CyFES-2.7.dist-info/METADATA
523312 2024-09-02 09:39 CyFES.libs/libcudart-80664282.so.10.2.89
168192 2024-09-02 09:39 CyFES.libs/libgomp-a34b3233.so.1.0.0
--------- -------
6956986 28 files
在这个新的结构中，auditwheel自动把依赖的cudart运行时库和omp分布式库拷贝到了whl包中。这样在本地安装之后，会在site-packages路径下找到一个CyFES.libs的目录，其中就存储了相关的两个动态链接库。那么接下来问题就出现了，在使用$ python3 setup.py sdist bdist_wheel --universal构建的时候，动态链接库libcufes.so是有rpath的，但是使用auditwheel修复之后，rpath消失了：
$ python3 -m auditwheel lddtree build/cyfes/libcufes.so
INFO:auditwheel.main_lddtree:{
"interp": null,
"path": "build/cyfes/libcufes.so",
"realpath": "build/cyfes/libcufes.so",
"needed": [
"libcudart.so.10.2",
"librt.so.1",
"libpthread.so.0",
"libdl.so.2",
"libstdc++.so.6",
"libm.so.6",
"libgcc_s.so.1",
"libc.so.6"
],
"rpath": [],
"runpath": [],
或者也可以使用$ patchelf --print-rpath xxx.so来查看动态链接库的rpath路径。
解决方案
首先我们梳理一下思路。如果这个问题不修复，那么导致的直接结果是，使用$ python3 -m pip install xxx.whl之后，安装过程不报错，但是调用相关函数时会出现段错误的报错。出现这个错误的根本原因是找不到相应的cudart和omp动态链接库。如果不使用auditwheel修复的话，这个包是不完整的，应用在不同版本的cuda上有可能报错。那么解决问题的方向应该是，让libcufes.so能够准确的找到auditwheel拷贝cudart和omp动态链接库文件的位置，也就是site-packages/CyFES.libs/。有了思路再看怎么实现的问题，首先是可以通过Makefile配置相关的运行时路径。换句话说，就是运行或者调用libcufes.so文件时会索引到的路径，只要把这个路径配置到cudart和omp所在路径，就可以索引到相关的库，也就不会报错。还有一种解决方案是，在编译构建完成后，通过patchelf工具直接修改libcufes.so动态链接库的rpath。
因为CyFES毕竟是一个Python库，综合考虑下来，在setup.py文件中配置patchelf命令是一个不错的选项。还有三个需要注意的点：
- 不同的Python版本，site-packages路径是不一样的；
- 不能使用绝对路径配置rpath；
- auditwheel修复whl包时会同时修改目标文件的rpath列表中的第一个路径。
针对于第一个问题，我们只要把支持的几个Python路径都配置上就可以了，例如把rpath配置为/lib/python3.7/site-packages/CyFES.libs:/lib/python3.8/site-packages/CyFES.libs，这样就支持了两个版本的Python路径。对于第二个问题，我们可以在rpath中使用$ORIGIN相对路径，也就是文件所在的当前位置。在安装cyfes时，会产生三个路径下的文件，分别存放data、lib和核心文件。其中lib与核心文件目录都在site-packages/路径下。因而彼此之间的相对路径索引形式是固定的，也就可以固定写在setup.py中进行配置。第三个问题，也很容易解决，只要在rpath的第一个位置放一个无用路径，随便它怎么改。最终形成的指令是这样的：
$ patchelf --set-rpath $ORIGIN:$ORIGIN/../lib/python3.7/site-packages/CyFES.libs:$ORIGIN/../lib/python3.8/site-packages/CyFES.libs:$ORIGIN/../lib/python3.9/site-packages/CyFES.libs:$ORIGIN/../lib/python3.10/site-packages/CyFES.libs libcufes.so
这样就可以解决libcufes.so动态链接库的rpath被auditwheel修改的问题，经过测试可以正常索引到相关的CUDA运行时和omp的动态链接库。
总结概要
在开源Python项目中，如果使用到了Cython或者CUDA C++等需要编译的后端技术，那么要传到pypi上就需要经过一个PEP标准的审查。要通过审查，就要经过多个版本的Python的构建，以及auditwheel修复的过程。本文解决了一个auditwheel修复过程中有可能出现的rpath路径索引问题。
版权声明
本文首发链接为：https://www.cnblogs.com/dechinphy/p/auditwheel.html
作者ID：DechinPhy
更多原著文章：https://www.cnblogs.com/dechinphy/
请博主喝咖啡：https://www.cnblogs.com/dechinphy/gallery/image/379634.html
