Open Jake-Moss opened 4 months ago
Looks like exclusion is performed too late in the process of finding a library. It's done after rpaths are resolved which causes the error seen here.
I think copy_filt_func
should probably be called in the tree_libs
or get_dependencies
function. In fact, it should probably be moved there entirely.
We may have come across this in scipy. We have this situation:
arpack
) use both fortran code and openblas code.-exclude
"solves" the complaint, but does not properly -change
the dylib loader command in arpack
: it leaves the full build path of libgfortran in place. While dlocate
does pack a libgfortran into the .dylibs
directory of the wheel, the arpack
shared object does not see that one.I think copy_filt_func should probably be called in the tree_libs or get_dependencies function. In fact, it should probably be moved there entirely.
I don't know the code base. Is this something I could easily try?
A "bare" call of delocate complains that these shared objects use two libgfortran shared objects: the one from the gfortran compiler and the one from openblas.
Using
-exclude
"solves" the complaint, but does not properly-change
the dylib loader command inarpack
: it leaves the full build path of libgfortran in place. Whiledlocate
does pack a libgfortran into the.dylibs
directory of the wheel, thearpack
shared object does not see that one.
This sounds like a complex case slightly unrelated to this issue. It sounds correct that --exclude
would skip the libgfortran
dylib and then not know how to deal with the path to it afterwards. What is your expectation for this situation?
If the extra paths you're referring to are rpaths then --sanitize-rpaths
will remove any absolute and relative paths from arpack
and any other bundled dylibs, leaving only the special @loader_path
paths. This might resolve the issue when combined with --exclude
, but I'm not completely sure.
Otherwise the dylibs need to link to the same libgfortran
before they are delocated. Either by compiling them to point to a single library in the first place or by modifying the dylibs with install_name_tool
before running Delocate.
What is your expectation for this situation?
Right, when trying to write in words the algorithm, I came to the conclusion that you are correct: -exclude
is not the right option for the scipy use case.
modifying the dylibs with
install_name_tool
before running Delocate
This was the solution we chose.
Sorry for hijacking this issue.
I am still willing to try to make a PR to solve this issue, if help is needed.
Describe the bug When providing the
--exclude
argument to excludelibarrow
andlibarrow_python
from the wheeldelocate.libsana
still claims it is unable to find the library instead of ignoring it.To Reproduce This fails within our CI using
pypa/cibuildwheel@v2.16.5
, specifically ourrepair-wheel-command
isI've tried plenty of variations of
--exclude arrow
,--exclude libarrow --exclude libarrow_python
and such, the docs and #106 lead me to believe that this should be excluding based on substring presence.Expected behavior Similarly to
auditwheel
, thelibarrow
andlibarrow_python
should be excluded from the repair attempt.Wheels used I don't have access to a MacOs system to recreate the wheel but the relevant branch is https://github.com/AequilibraE/aequilibrae/pull/510/ We're attempting to link against the pyarrow Cython and arrow C++ APIs using Cython.
Platform:
Additional context I've attached the full logs of a failed CI run, the relevant section is
Build wheels
or theBuild wheels on macos-latest/4_Build wheels.txt
file. Here's a small section as welllogs_11438.zip