Find and copy needed dynamic libraries into python wheels
matthew-brett, updated
🕥
2023-01-30 11:42:37
.. image:: https://img.shields.io/pypi/v/delocate :target: https://pypi.org/project/delocate/ .. image:: https://travis-ci.org/matthew-brett/delocate.svg?branch=master :target: https://travis-ci.org/matthew-brett/delocate .. image:: https://codecov.io/gh/matthew-brett/delocate/branch/master/graph/badge.svg?token=wvAWRBK5Di :target: https://codecov.io/gh/matthew-brett/delocate
Delocate
macOS utilities to:
- find dynamic libraries imported from python extensions
- copy needed dynamic libraries to directory within package
- update macOS
install_namesandrpathto cause code to load from copies of libraries
Provides scripts:
delocate-listdeps-- show libraries a tree depends ondelocate-path-- copy libraries a tree depends on into the tree and relinkdelocate-wheel-- rewrite wheel having copied and relinked library dependencies into the wheel tree.delocate-fuse-- combine two wheels with different architectures into one wheel with dual architecture binaries.
Auditwheel <https://github.com/pypa/auditwheel>_ is a similar tool for Linux.
Auditwheel started life as a partial fork of Delocate.
The problem
Let's say you have built a wheel somewhere, but it's linking to dynamic libraries elsewhere on the machine, so you can't distribute it, because others may not have these same libraries. Here we analyze the dependencies for a Scipy wheel::
$ delocate-listdeps scipy-0.14.0b1-cp34-cp34m-macosx_10_6_intel.whl
/usr/local/Cellar/gfortran/4.8.2/gfortran/lib/libgcc_s.1.dylib
/usr/local/Cellar/gfortran/4.8.2/gfortran/lib/libgfortran.3.dylib
/usr/local/Cellar/gfortran/4.8.2/gfortran/lib/libquadmath.0.dylib
By default, this does not include libraries in /usr/lib and /System.
See those too with::
$ delocate-listdeps --all scipy-0.14.0-cp34-cp34m-macosx_10_6_intel.whl
/System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
/usr/lib/libSystem.B.dylib
/usr/lib/libstdc++.6.dylib
/usr/local/Cellar/gfortran/4.8.2/gfortran/lib/libgcc_s.1.dylib
/usr/local/Cellar/gfortran/4.8.2/gfortran/lib/libgfortran.3.dylib
/usr/local/Cellar/gfortran/4.8.2/gfortran/lib/libquadmath.0.dylib
The output tells me that Scipy has picked up dynamic libraries from my
Homebrew installation of gfortran (as well as the system libs).
You can get a listing of the files depending on each of the libraries,
using the --depending flag::
$ delocate-listdeps --depending scipy-0.14.0-cp34-cp34m-macosx_10_6_intel.whl
/usr/local/Cellar/gfortran/4.8.2/gfortran/lib/libgcc_s.1.dylib:
scipy/interpolate/dfitpack.so
scipy/special/specfun.so
scipy/interpolate/_fitpack.so
...
A solution
We can fix like this::
$ delocate-wheel -w fixed_wheels -v scipy-0.14.0-cp34-cp34m-macosx_10_6_intel.whl
Fixing: scipy-0.14.0-cp34-cp34m-macosx_10_6_intel.whl
Copied to package .dylibs directory:
/usr/local/Cellar/gfortran/4.8.2/gfortran/lib/libgcc_s.1.dylib
/usr/local/Cellar/gfortran/4.8.2/gfortran/lib/libgfortran.3.dylib
/usr/local/Cellar/gfortran/4.8.2/gfortran/lib/libquadmath.0.dylib
The -w flag tells delocate-wheel to output to a new wheel directory
instead of overwriting the old wheel. -v (verbose) tells you what
delocate-wheel is doing. In this case it has made a new directory in the
wheel zipfile, named scipy/.dylibs. It has copied all the library
dependencies that are outside the macOS system trees into this directory, and
patched the python .so extensions in the wheel to use these copies instead
of looking in /usr/local/Cellar/gfortran/4.8.2/gfortran/lib.
Check the links again to confirm::
$ delocate-listdeps --all fixed_wheels/scipy-0.14.0-cp34-cp34m-macosx_10_6_intel.whl
/System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
/usr/lib/libSystem.B.dylib
/usr/lib/libstdc++.6.0.9.dylib
@loader_path/../../../../.dylibs/libgcc_s.1.dylib
@loader_path/../../../../.dylibs/libgfortran.3.dylib
@loader_path/../../../../.dylibs/libquadmath.0.dylib
@loader_path/../../../.dylibs/libgcc_s.1.dylib
@loader_path/../../../.dylibs/libgfortran.3.dylib
@loader_path/../../../.dylibs/libquadmath.0.dylib
@loader_path/../../.dylibs/libgcc_s.1.dylib
@loader_path/../../.dylibs/libgfortran.3.dylib
@loader_path/../../.dylibs/libquadmath.0.dylib
@loader_path/../.dylibs/libgcc_s.1.dylib
@loader_path/../.dylibs/libgfortran.3.dylib
@loader_path/../.dylibs/libquadmath.0.dylib
@loader_path/libgcc_s.1.dylib
@loader_path/libquadmath.0.dylib
So - system dylibs the same, but the others moved into the wheel tree.
This makes the wheel more likely to work on another machine which does not have the same version of Gfortran installed - in this example.
Checking required architectures
Current Python.org Python and the macOS system Python (/usr/bin/python)
are both dual architecture binaries. For example::
$ lipo -info /usr/bin/python
Architectures in the fat file: /usr/bin/python are: x86_64 arm64e
Note: you can compile ARM binaries for basic ARM (arm64), or to use
some extended ARM capabilities (arm64e) - see this SO post
<https://stackoverflow.com/questions/52624308/xcode-arm64-vs-arm64e>_. Both
types of binaries work on Mac M1 and M2 machines, so we will use arm64 to
refer to either arm64 or arm64e.
The Big Sur macOS Python above has both x86_64 and arm64 (M1) versions
fused into one file. Earlier versions of macOS had dual architectures that
were 32-bit (i386) and 64-bit (x86_64).
For full compatibility with system and Python.org Python, wheels built for
Python.org Python or system Python should have the corresponding architectures
— e.g. x86_64 and arm64 versions of the Python extensions and their
libraries. It is easy to link Python extensions against single architecture
libraries by mistake, and therefore get single architecture extensions and /
or libraries. In fact my Scipy wheel is one such example, because I
inadvertently linked against the Homebrew libraries, which were x86_64
only. To check this you can use the --require-archs flag::
$ delocate-wheel --require-archs=intel scipy-0.14.0-cp34-cp34m-macosx_10_6_intel.whl
Traceback (most recent call last):
File "/Users/mb312/.virtualenvs/delocate/bin/delocate-wheel", line 77, in <module>
main()
File "/Users/mb312/.virtualenvs/delocate/bin/delocate-wheel", line 69, in main
check_verbose=opts.verbose)
File "/Users/mb312/.virtualenvs/delocate/lib/python2.7/site-packages/delocate/delocating.py", line 477, in delocate_wheel
"Some missing architectures in wheel")
delocate.delocating.DelocationError: Some missing architectures in wheel
Notice that this command was using an earlier version of Delocate that supported Python 2; we now support Python 3 only.
The intel argument to --require-arch above requires dual 32- and 64-
bit architecture extensions and libraries. You can see which extensions are at
fault by adding the -v (verbose) flag::
$ delocate-wheel -w fixed_wheels --require-archs=intel -v scipy-0.14.0-cp34-cp34m-macosx_10_6_intel.whl
Fixing: scipy-0.14.0-cp34-cp34m-macosx_10_6_intel.whl
Required arch i386 missing from /usr/local/Cellar/gfortran/4.8.2/gfortran/lib/libgfortran.3.dylib
Required arch i386 missing from /usr/local/Cellar/gfortran/4.8.2/gfortran/lib/libquadmath.0.dylib
Required arch i386 missing from scipy/fftpack/_fftpack.so
Required arch i386 missing from scipy/fftpack/convolve.so
Required arch i386 missing from scipy/integrate/_dop.so
...
I need to rebuild this wheel to link with dual-architecture libraries.
Making dual-architecture binaries
Modern Mac wheels can be either arm64 (M1/M2 ARM), x86_64 (64-bit
Intel) or both (universal2).
Building an entire Python wheel as dual-architecture can be difficult, perhaps
because you need to link different libraries in the two cases, or you need
different compiler flags, or because you build for arm64 on one continuous
integration platform (such as - at time of writing - Cirrus CI), and x86_64
on another.
One solution to this problem is to do an entire arm64 wheel build, and then
an entire x86_64 wheel build, and fuse the two wheels into a universal
wheel.
That is what the delocate-fuse command does.
Let's say you have built an ARM and Intel wheel, called, respectively:
scipy-1.9.3-cp311-cp311-macosx_11_0_arm64.whlscipy-1.9.3-cp311-cp311-macosx_10_9_x86_64.whl
Then you could create a new fused (universal2) wheel in the tmp
subdirectory with::
delocate-fuse scipy-1.9.3-cp311-cp311-macosx_12_0_arm64.whl scipy-1.9.3-cp311-cp311-macosx_10_9_x86_64.whl -w tmp
The output wheel in that case would be:
tmp/scipy-1.9.3-cp311-cp311-macosx_12_0_arm64.whl
Note that we specified an output directory above with the -w flag. If we
had not done that, then we overwrite the first wheel with the fused wheel. And
note that the wheel written into the tmp subdirectory has the same name as
the first-specified wheel.
In the new wheel, you will find, using lipo -archs - that all binaries with
the same name in each wheel are now universal (x86_64 and arm64).
To be useful, you should rename the output wheel to reflect the fact that it is now a universal wheel - in this case to:
tmp/scipy-1.9.3-cp311-cp311-macosx_12_0_universal2.whl
Troubleshooting
DelocationError: "library does not exist"
When running delocate-wheel or its sister command delocate-path, you
may get errors like this::
delocate.delocating.DelocationError: library "<long temporary path>/wheel/libme.dylib" does not exist
This happens when one of your libraries gives a library dependency with a
relative path. For example, let's say that some file in my wheel has this for
the output of otool -L myext.so::
myext.so:
libme.dylib (compatibility version 10.0.0, current version 10.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 60.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
The first line means that myext.so expects to find libme.dylib at
exactly the path ./libme.dylib - the current working directory from which
you ran the executable. The output should be something like::
myext.so:
/path/to/libme.dylib (compatibility version 10.0.0, current version 10.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 60.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
To set the path to the library, the linker is using the install name id_ of
the linked library. In this bad case, then otool -L libme.dylib will give
something like::
libme.dylib (compatibility version 10.0.0, current version 10.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
where the first line is the install name id that the linker picked up when
linking myext.so to libme.dylib. Your job is to fix the build process
so that libme.dylib has install name id /path/to/libme.dylib.
This is not a problem specific to Delocate; you will need to do this to
make sure that myext.so can load libme.dylib without libme.dylib
being in the current working directory. For CMAKE builds you may want to
check out CMAKE_INSTALL_NAME_DIR.
Code
See https://github.com/matthew-brett/delocate
Released under the BSD two-clause license - see the file LICENSE in the
source distribution.
travis-ci <https://travis-ci.org/matthew-brett/delocate>_ kindly tests the
code automatically under Python 3.6 through 3.9.
The latest released version is at https://pypi.python.org/pypi/delocate
Support
Please put up issues on the Delocate issue tracker
<https://github.com/matthew-brett/delocate/issues>_.
.. _install name id: http://matthew-brett.github.io/docosx/mac_runtime_link.html#the-install-name .. _CMAKE_INSTALL_NAME_DIR: http://www.cmake.org/cmake/help/v3.0/variable/CMAKE_INSTALL_NAME_DIR.html
Issues
`delocate-fuse` merge strategies if file contents differ
opened on 2023-03-21 11:31:55 by rgommersIn https://github.com/pypackaging-native/pypackaging-native/pull/27#discussion_r1142744075, @freakboy3742 pointed out a potential problem with delocate-fuse: when two files (.py, .h, or any other file type other than the binaries that actually need fusing) differ, it is unclear what to do.
At the moment, delocate-fuse doesn't check and just keeps one of the two files. For reproducible builds this is fine, but if you have for example a generated header file which depends on the architecture (e.g., contains size of long double, a real bug we had in numpy), there is a problem. There are a few possible merge strategies possible:
- error out
- pick one file at random
- pick the files from the first wheel that was fed to delocate-fuse
The safest bet would be to error out, and allow users to specify a list of files that are known to differ between x86-64 and arm64, with the specification of which to pick. This is likely to catch some bugs, and improve the reproducibility of wheel builds.
Facing problem in building wheels using github actions
opened on 2023-02-27 05:12:44 by EarammakDescribe the bug
This is regarding we are building a wheels from ci server.
For macos we could see the following error:
+ delocate-wheel --require-archs x86_64 -w /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-uvqi31y6/cp311-macosx_x86_64/repaired_wheel -v /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-uvqi31y6/cp311-macosx_x86_64/built_wheel/ibm_db_wheel-0.0.1-cp311-cp311-macosx_10_15_x86_64.whl
ERROR:delocate.libsana:
/usr/local/lib/gcc/8/libstdc++.6.dylib not found:
Needed by: /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/tmpx3aasy2z/wheel/clidriver/lib/libdb2.dylib
ERROR:delocate.libsana:
/usr/local/lib/gcc/8/libgcc_s.1.dylib not found:
Needed by: /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/tmpx3aasy2z/wheel/clidriver/lib/libdb2.dylib
ERROR:delocate.libsana:
/usr/local/lib/gcc/8/libstdc++.6.dylib not found:
Needed by: /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/tmpx3aasy2z/wheel/clidriver/lib/libdb2.dylib
ERROR:delocate.libsana:/usr/local/lib/gcc/8/libstdc++.6.dylib not found, requested by /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/tmpx3aasy2z/wheel/clidriver/lib/libdb2.dylib
ERROR:delocate.libsana:
/usr/local/lib/gcc/8/libgcc_s.1.dylib not found:
Needed by: /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/tmpx3aasy2z/wheel/clidriver/lib/libdb2.dylib
ERROR:delocate.libsana:/usr/local/lib/gcc/8/libgcc_s.1.dylib not found, requested by /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/tmpx3aasy2z/wheel/clidriver/lib/libdb2.dylib
ERROR:delocate.libsana:
/usr/local/lib/gcc/8/libstdc++.6.dylib not found:
Needed by: /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/tmpx3aasy2z/wheel/clidriver/lib/libdb2clixml4c.dylib
ERROR:delocate.libsana:
/usr/local/lib/gcc/8/libgcc_s.1.dylib not found:
Needed by: /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/tmpx3aasy2z/wheel/clidriver/lib/libdb2clixml4c.dylib
ERROR:delocate.libsana:
/usr/local/lib/gcc/8/libstdc++.6.dylib not found:
Needed by: /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/tmpx3aasy2z/wheel/clidriver/lib/libdb2clixml4c.dylib
ERROR:delocate.libsana:/usr/local/lib/gcc/8/libstdc++.6.dylib not found, requested by /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/tmpx3aasy2z/wheel/clidriver/lib/libdb2clixml4c.dylib
ERROR:delocate.libsana:
/usr/local/lib/gcc/8/libgcc_s.1.dylib not found:
Needed by: /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/tmpx3aasy2z/wheel/clidriver/lib/libdb2clixml4c.dylib
ERROR:delocate.libsana:/usr/local/lib/gcc/8/libgcc_s.1.dylib not found, requested by /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/tmpx3aasy2z/wheel/clidriver/lib/libdb2clixml4c.dylib
ERROR:delocate.libsana:
/usr/local/opt/[email protected]/lib/gcc/8/libstdc++.6.dylib not found:
Needed by: /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/tmpx3aasy2z/wheel/clidriver/security64/plugin/IBM/client/IBMIAMauth.dylib
ERROR:delocate.libsana:
/usr/local/lib/gcc/8/libgcc_s.1.dylib not found:
Needed by: /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/tmpx3aasy2z/wheel/clidriver/security64/plugin/IBM/client/IBMIAMauth.dylib
ERROR:delocate.libsana:
/usr/local/opt/[email protected]/lib/gcc/8/libstdc++.6.dylib not found:
Needed by: /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/tmpx3aasy2z/wheel/clidriver/security64/plugin/IBM/client/IBMIAMauth.dylib
ERROR:delocate.libsana:/usr/local/opt/[email protected]/lib/gcc/8/libstdc++.6.dylib not found, requested by /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/tmpx3aasy2z/wheel/clidriver/security64/plugin/IBM/client/IBMIAMauth.dylib
ERROR:delocate.libsana:
/usr/local/lib/gcc/8/libgcc_s.1.dylib not found:
Needed by: /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/tmpx3aasy2z/wheel/clidriver/security64/plugin/IBM/client/IBMIAMauth.dylib
ERROR:delocate.libsana:/usr/local/lib/gcc/8/libgcc_s.1.dylib not found, requested by /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/tmpx3aasy2z/wheel/clidriver/security64/plugin/IBM/client/IBMIAMauth.dylib
Fixing: /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-uvqi31y6/cp311-macosx_x86_64/built_wheel/ibm_db_wheel-0.0.1-cp311-cp311-macosx_10_15_x86_64.whl
Traceback (most recent call last):
File "/private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-uvqi31y6/cp311-macosx_x86_64/build/venv/bin/delocate-wheel", line 8, in <module>
sys.exit(main())
^^^^^^
File "/private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-uvqi31y6/cp311-macosx_x86_64/build/venv/lib/python3.11/site-packages/delocate/cmd/delocate_wheel.py", line 127, in main
copied = delocate_wheel(
^^^^^^^^^^^^^^^
File "/private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-uvqi31y6/cp311-macosx_x86_64/build/venv/lib/python3.11/site-packages/delocate/delocating.py", line 645, in delocate_wheel
copied_libs = delocate_path(
^^^^^^^^^^^^^^
File "/private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-uvqi31y6/cp311-macosx_x86_64/build/venv/lib/python3.11/site-packages/delocate/delocating.py", line 466, in delocate_path
lib_dict = tree_libs_from_directory(
^^^^^^^^^^^^^^^^^^^^^^^^^
File "/private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-uvqi31y6/cp311-macosx_x86_64/build/venv/lib/python3.11/site-packages/delocate/libsana.py", line 380, in tree_libs_from_directory
return _tree_libs_from_libraries(
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-uvqi31y6/cp311-macosx_x86_64/build/venv/lib/python3.11/site-packages/delocate/libsana.py", line 321, in _tree_libs_from_libraries
raise delocate.delocating.DelocationError(
delocate.delocating.DelocationError: Could not find all dependencies.
✕ 41.37s
Error: Command delocate-wheel --require-archs x86_64 -w /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-uvqi31y6/cp311-macosx_x86_64/repaired_wheel -v /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-uvqi31y6/cp311-macosx_x86_64/built_wheel/ibm_db_wheel-0.0.1-cp311-cp311-macosx_10_15_x86_64.whl failed with code 1. None
Platform (please complete the following information): OS version: macOS 12 Delocate version: 0.10.4
Kindly help us in resolving this from github actiond server. Thanks
MRG: Add Kyle to LICENSE
opened on 2023-01-27 10:08:53 by matthew-brett None[delocate-addplat] `parse_wheel_filename` may return wrong package name
opened on 2023-01-26 21:52:29 by duburcqaDescribe the bug
The parse_wheel_filename method that is involved in the CLI command delocate-addplat returns the "canonical" package name as first output argument, i.e. underscores are replaced by dashes if any. This name is then used to defined where to find the dist-info. However, the name that is actually used to prepend dist-info is actually doing the contrary (using dashes in place of underscores), leading to failure.
To Reproduce
Here is an example of such a failure: ``` adding 'jiminy_py/viewer/panda3d/panda3d_widget.py' adding 'jiminy_py-1.7.14.data/data/cmake/jiminyConfig.cmake' adding 'jiminy_py-1.7.14.data/data/cmake/jiminyConfigVersion.cmake' adding 'jiminy_py-1.7.14.dist-info/METADATA' adding 'jiminy_py-1.7.14.dist-info/WHEEL' adding 'jiminy_py-1.7.14.dist-info/entry_points.txt' adding 'jiminy_py-1.7.14.dist-info/top_level.txt' adding 'jiminy_py-1.7.14.dist-info/RECORD' removing build/bdist.macosx-10.15-x86_64/wheel
[...]
Fixing: /Users/runner/work/jiminy/jiminy/build/pypi/dist/jiminy_py/jiminy_py-1.7.14-cp38-cp38-macosx_10_15_x86_64.whl Copied to package .dylibs directory: /Users/runner/work/jiminy/jiminy/install/lib/libboost_numpy38.dylib /Users/runner/work/jiminy/jiminy/install/lib/libboost_python38.dylib /Users/runner/work/jiminy/jiminy/install/lib/libeigenpy.dylib /Users/runner/work/jiminy/jiminy/install/lib/libhpp-fcl.dylib /Users/runner/work/jiminy/jiminy/install/lib/libpinocchio.2.6.7.dylib
[...]
Setting platform tags macosx_10_14_universal2 for wheel /Users/runner/work/jiminy/jiminy/build/wheelhouse/jiminy_py-1.7.14-cp38-cp38-macosx_10_15_x86_64.whl
Traceback (most recent call last):
File "/Users/runner/hostedtoolcache/Python/3.8.16/x64/bin/delocate-addplat", line 8, in
The complete log file is available here.
Expected behavior
The package names used to create and search dist-info should be consistent.
Wheels used
Could be added if necessary
Platform (please complete the following information): - OS version: macOS 10.9 - Delocate version: 0.10.4
Additional context
It was working just find before this MR https://github.com/matthew-brett/delocate/pull/141
it would be nice if delocate-fuse would rename its output
opened on 2023-01-26 05:42:04 by glyphIs your feature request related to a problem? Please describe.
delocate-fuse creates a universal2 wheel (which is amazing) but gives it the wrong tag
Describe the solution you'd like Do not rewrite the input in place, instead, put a wheel next to it with a modified tag name.
Describe alternatives you've considered It is not clear to me what other behavior would be correct :)
Additional context I'm not sure if this is a feature or a bug. It strikes me as incorrect behavior to write an x86_64 tagged wheel that has arm64 code in it, but I am filing it as an enhancement as I assume the existing behavior has some reason for existing.
Building error: Already planning to copy library with same basename as: libstdc++.6.dylib
opened on 2022-10-28 20:54:18 by MartinPdeSHello, I would like to report this problem I am having. I am trying to build my code (python api wrapping c++ and fortran core) and I am facing this error message (at the end of message) that doesn't help me at all. I have been reading through a lot of documentation and forums but couldn't find anything to help. My workflow file is pretty simple:
================================================================
MacOS:
runs-on: macos-latest
strategy:
fail-fast: false
matrix:
cibw_python: ["cp38-macosx_x86_64", "cp39-macosx_x86_64", "cp310-macosx_x86_64"]
steps:
- name: Checkout repository
uses: actions/[email protected]
with:
submodules: 'true'
- name: Provide gfortran and gcc (macOS)
run: |
# https://github.com/actions/virtual-environments/issues/2524
# https://github.com/cbg-ethz/dce/blob/master/.github/workflows/pkgdown.yaml
brew install gcc
sudo ln -s /usr/local/bin/gfortran-11 /usr/local/bin/gfortran
sudo mkdir /usr/local/gfortran
sudo ln -s /usr/local/Cellar/[email protected]/*/lib/gcc/11 /usr/local/gfortran/lib
- name: Build wheels
uses: pypa/[email protected]
env:
CIBW_BEFORE_BUILD: cmake . -DCMAKE_CXX_COMPILER=/usr/local/Cellar/gcc/12.2.0/bin/g++-12 && sudo make install
CIBW_BEFORE_ALL: CC=gcc CXX=g++
CIBW_ARCHS_MACOS: x86_64 arm64
CIBW_BUILD: cp38-* cp39-* cp310-*
- name: Publish a Python distribution to PyPI
uses: pypa/[email protected]
with:
user: __token__
password: ${{ secrets.PYPI_API_TOKEN }}
================================================================
While it may not be a bug but an error from my side, I think the error message is not clear.
I am new at using delocate, so I don't really know what is the expected behavior, but with auditwheel i would expect delocate to produce my repaired wheel file.
Here is the link for the github workflow https://github.com/MartinPdeS/PyMieSim/actions/runs/3348332811/jobs/5547283200
Many thanks
```
+ delocate-wheel --require-archs x86_64 -w /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-q96w162q/cp38-macosx_x86_64/repaired_wheel -v /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-q96w162q/cp38-macosx_x86_64/built_wheel/PyMieSim-0.6.29-cp38-cp38-macosx_10_9_x86_64.whl
Fixing: /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-q96w162q/cp38-macosx_x86_64/built_wheel/PyMieSim-0.6.29-cp38-cp38-macosx_10_9_x86_64.whl
Traceback (most recent call last):
File "/private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibw-run-q96w162q/cp38-macosx_x86_64/build/venv/bin/delocate-wheel", line 8, in
Error: Process completed with exit code 1. ```