search

pypa / auditwheel

Auditing and relabeling cross-distribution Linux wheels.
Other
443 stars 145 forks source link

modules statically linked to libpythonx.y.a are show as compliant #23

Open blowekamp opened 8 years ago

blowekamp commented 8 years ago

Please consider checking that a module library has undefined python symbols to verify that it has not been statically linked against libpython.a

I am using CMake as a build tool so it's a bit more manual than distutils for linking. I had previously been linking my module to libpython as a shared library. In testing with the recent manylinux docker images, I created a 32-bit wheel what was linked against it's static libpyton. When I ran audit wheel is said it was compliant.

I think that if the module is statically linked it should raise a flag with auditwheel.

rmcgibbo commented 8 years ago

This could be a good idea. I'm going to consider it relatively low priority for me to implement (although PRs are welcome) because I think the majority of the use-cases for auditwheel involve workflows that use distutils as the build tool, which will never do this.

njsmith commented 8 years ago

It's separate from the auditwheel issue, but I also wonder if there are any valid use cases for libpython.a in the docker image -- maybe we should just not provide it at all.

rmcgibbo commented 8 years ago

That's a fair point too.

blowekamp commented 8 years ago

Thank you for your consideration of the "feature".

Removing the libraries would create some more difficulties for me. Even if I don't link to the library, using CMake's FindPythonLibs[1] is the standard for finding the Python include directories, which also searches for the libraries. Removing the library with make the results from this CMake module be marked as "not found".

[1] https://cmake.org/cmake/help/v3.0/module/FindPythonLibs.html

njsmith commented 8 years ago

I guess we could replace libpython.a with an empty library...