Background to the issue
AuditWheel is a tool for fixing Python's whl package, such as in thisCyFES open source libraryThe technique of compiling dynamic link libraries for Cython and CUDA is used to facilitate Python calls. However, if you use runtime libraries when compiling CUDA arithmetic, the runtime libraries will not be automatically included in the first step of building the whl package, while the dynamic link libraries related to the runtime libraries will be automatically copied to the whl package in the second step of whl package repair using auditwheel. First look at the directory tree of the whl package before repair:
$ 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./data/cyfes/
1731 2024-08-27 02:47 CyFES-2./data/cyfes/FES_f32.cuh
692112 2024-09-02 09:38 CyFES-2./data/cyfes/libcufes.
55472 2024-09-02 09:38 CyFES-2./data/cyfes/
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/
1457723 2024-09-02 09:38 cyfes/
1545248 2024-09-02 09:38 cyfes/-37m-x86_64
1245635 2024-09-02 09:38 cyfes/wrapper_f32.c
1213984 2024-09-02 09:38 cyfes/wrapper_f32.cpython-37m-x86_64
2071 2024-09-02 07:54 cyfes/kernels/
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.-info/LICENSE
5588 2024-09-02 09:38 CyFES-2.-info/METADATA
104 2024-09-02 09:38 CyFES-2.-info/WHEEL
6 2024-09-02 09:38 CyFES-2.-info/top_level.txt
1569 2024-09-02 09:38 CyFES-2.-info/RECORD
--------- -------
6237485 19 files
Here only the dynamic compilation of the build process generates thecap (a poem)wrapperDynamic link library files. Look again at the use of theauditwheel repairThe whl package directory tree structure after the fix:
$ 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./
0 2024-09-02 09:39 CyFES-2.-info/
0 2024-09-02 09:39 /
0 2024-09-02 09:39 cyfes/kernels/
1457723 2024-09-02 09:39 cyfes/
1213984 2024-09-02 09:39 cyfes/wrapper_f32.cpython-37m-x86_64
6117 2024-09-02 09:39 cyfes/__main__.py
1564760 2024-09-02 09:39 cyfes/-37m-x86_64
1628 2024-09-02 09:39 cyfes/__init__.py
3632 2024-09-02 09:39 cyfes/
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/
1731 2024-09-02 09:39 cyfes/kernels/FES_f32.cuh
0 2024-09-02 09:39 CyFES-2./data/
0 2024-09-02 09:39 CyFES-2./data/cyfes/
63696 2024-09-02 09:39 CyFES-2./data/cyfes/
692112 2024-09-02 09:39 CyFES-2./data/cyfes/libcufes.
2071 2024-09-02 09:39 CyFES-2./data/cyfes/
1731 2024-09-02 09:39 CyFES-2./data/cyfes/FES_f32.cuh
150 2024-09-02 09:39 CyFES-2.-info/WHEEL
1063 2024-09-02 09:39 CyFES-2.-info/LICENSE
1784 2024-09-02 09:39 CyFES-2.-info/RECORD
6 2024-09-02 09:39 CyFES-2.-info/top_level.txt
5588 2024-09-02 09:39 CyFES-2.-info/METADATA
523312 2024-09-02 09:39 /.10.2.89
168192 2024-09-02 09:39 /.1.0.0
--------- -------
6956986 28 files
In this new structure, auditwheel automatically copies the dependent cudart runtime libraries and omp distributed libraries into the whl package. This way, after a local installation, you will find under the site-packages path adirectory, which stores the two dynamic link libraries in question. So the next problem arises when using the$ python3 sdist bdist_wheel --universalAt build time, the dynamic link libraryThere was an rpath, but after fixing it with auditwheel, the rpath disappeared:
$ python3 -m auditwheel lddtree build/cyfes/
INFO:auditwheel.main_lddtree:{
"interp": null,
"path": "build/cyfes/",
"realpath": "build/cyfes/",
"needed": [
".10.2",
".1",
".0",
".2",
"libstdc++.so.6",
".6",
"libgcc_s.so.1",
".6"
],
"rpath": [],
"runpath": [],
Or you can also use the$ patchelf --print-rpath to see the rpath path of the dynamic link library.
prescription
First let's sort out the ideas. If this issue is not fixed, then the immediate result is that using the$ python3 -m pip install After that, the installation process does not report an error, but a segment error occurs when calling the relevant function. The root cause of this error is that the corresponding cudart and omp libraries cannot be found. If you don't use auditwheel to fix it, the package is incomplete, and it may report errors when applied to different versions of cuda. The direction to solve the problem should be to make it possible to find the exact location where auditwheel copies the cudart and omp libraries, i.e.site-packages//The first thing you can do is to configure the runtime path through the Makefile. With the idea and then look at how to realize the problem, first of all, you can configure the relevant runtime path through the Makefile. In other words, it is the path that will be indexed when running or calling the file, as long as this path is configured to the path where the cudart and omp are located, the relevant libraries can be indexed, and no error will be reported. Another solution is, after the compilation and build is complete, you can add the paths to the libraries via thepatchelfTools for direct modificationThe rpath of the dynamic link library.
on account ofCyFESIt is, after all, a Python library, and all things considered, theConfiguring the patchelf command in the file is a good option. There are three other points to note:
- The site-packages path is different for different Python versions;
- You cannot configure rpath with absolute paths;
- When auditwheel repairs a whl package, it also modifies the first path in the rpath list of the target file.
For the first problem, we just need to configure several of the supported Python paths, e.g., rpath as/lib/python3.7/site-packages/:/lib/python3.8/site-packages/This supports both versions of Python paths. For the second problem, we can use the rpath$ORIGINRelative paths, that is, the current location where the files are located. When cyfes is installed, it generates files under three paths, which hold data, lib, and core files. The lib and core file directories are in thesite-packages/under the path. Thus, the relative path index form each other is fixed, and it can be fixed to write in for configuration. The third problem, also easy to solve, just put a useless path in the first position of the rpath, and change it however you want. The final form of the command is this:
$ patchelf --set-rpath $ORIGIN:$ORIGIN/../lib/python3.7/site-packages/:$ORIGIN/../lib/python3.8/site-packages/:$ORIGIN/../lib/python3.9/site-packages/:$ORIGIN/../lib/python3.10/site-packages/
This will solve the problem that the rpath of the dynamic link library has been modified by auditwheel. After testing, we can index the relevant CUDA runtime and omp dynamic link library normally.
Summary outline
In open source Python projects that use backend technologies that require compilation, such as Cython or CUDA C++, then to pass to pypi it needs to go through a PEP standard review. To pass the review, one has to go through the process of building multiple versions of Python, and auditwheel fixes. This article addresses a possible rpath path indexing problem that can occur during an auditwheel fix.
copyright statement
This article was first linked to:/dechinphy/p/
Author ID: DechinPhy
More original articles:/dechinphy/
Buy the blogger coffee:/dechinphy/gallery/image/