Open andreas-el opened 2 months ago
Can you try setting the environment variable MACOSX_DEPLOYMENT_TARGET=11.0
(set it to whichever version you're trying to target) before running delocate-wheel
?
Which dependencies are forcing 13.6? If those are built locally then maybe set MACOSX_DEPLOYMENT_TARGET=11.0
for the entire workflow.
Can you try setting the environment variable
MACOSX_DEPLOYMENT_TARGET=11.0
(set it to whichever version you're trying to target) before runningdelocate-wheel
?
Thanks for the quick replies.
We have already set this variable, but in the case of macos-14-large
this does not work when using delocate 0.11.0
.
Fixing: /tmp/carolina_dist_unfixed/carolina-1.0.16.dev3+gfb7b791-cp312-cp312-macosx_11_0_x86_64.whl
File "/Users/runner/hostedtoolcache/Python/3.12.2/x64/bin/delocate-wheel", line 8, in <module>
sys.exit(main())
^^^^^^
File "/Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/site-packages/delocate/cmd/delocate_wheel.py", line 110, in main
copied = delocate_wheel(
^^^^^^^^^^^^^^^
File "/Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/site-packages/delocate/delocating.py", line 1004, in delocate_wheel
out_wheel_fixed = _check_and_update_wheel_name(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/site-packages/delocate/delocating.py", line 839, in _check_and_update_wheel_name
raise DelocationError(
delocate.libsana.DelocationError: Library dependencies do not satisfy target MacOS version 11.0:
/private/var/folders/02/qm7jv9vx7_ld2jykcqjpgkgw0000gn/T/tmp_kontn8r/wheel/carolina.dylibs/libboost_serialization.dylib has a minimum target of 14.0
/private/var/folders/02/qm7jv9vx7_ld2jykcqjpgkgw0000gn/T/tmp_kontn8r/wheel/carolina.dylibs/libsoga.dylib has a minimum target of 14.0
/private/var/folders/02/qm7jv9vx7_ld2jykcqjpgkgw0000gn/T/tmp_kontn8r/wheel/carolina.dylibs/libdream.dylib has a minimum target of 14.0
/private/var/folders/02/qm7jv9vx7_ld2jykcqjpgkgw0000gn/T/tmp_kontn8r/wheel/carolina.dylibs/libjega.dylib has a minimum target of 14.0
/private/var/folders/02/qm7jv9vx7_ld2jykcqjpgkgw0000gn/T/tmp_kontn8r/wheel/carolina.dylibs/libteuchoscomm.13.0.dylib has a minimum target of 14.0
/private/var/folders/02/qm7jv9vx7_ld2jykcqjpgkgw0000gn/T/tmp_kontn8r/wheel/carolina.dylibs/libconmin.dylib has a minimum target of 14.0
...
https://github.com/equinor/Carolina/actions/runs/8611588703/job/23599070801?pr=105
This has me a bit stumped though (why does the error indicate it needs target 14.0 ?)
# When exporting MACOSX_DEPLOYMENT_TARGET=11.0 for macos-14-large (x86_64)
/private/var/folders/02/qm7jv9vx7_ld2jykcqjpgkgw0000gn/T/tmp_kontn8r/wheel/carolina.dylibs/libteuchoscomm.13.0.dylib has a minimum target of 14.0
This does not affect macOS-14 arm64-builds where we had to specify 13.0
as target.
# When exporting MACOSX_DEPLOYMENT_TARGET=13.0 for macos-14 (arm64)
INFO:delocate.delocating:Modifying install name in carolina.dylibs/libteuchoscomm.13.0.dylib from @rpath/libteuchosparameterlist.13.dylib to @loader_path/libteuchosparameterlist.13.0.dylib
Using the following setup works fine:
macos-14-large
...
INFO:delocate.delocating:Modifying install name in carolina.dylibs/libteuchoscomm.13.0.dylib from @rpath/libteuchoscore.13.dylib to @loader_path/libteuchoscore.13.0.dylib
...
Output new carolina wheel to /tmp/carolina_dist
total 35704
-rw-r--r-- 1 runner wheel 17M Apr 9 07:20 carolina-1.0.16.dev4+g72314b7-cp312-cp312-macosx_11_0_x86_64.whl
Please note that I am using the same build-files when assembling this wheel.
Meaning that both boost and Dakota were pre-built in during another step in the workflow. I have yet to test exporting the MACOSX_DEPLOYMENT_TARGET
variable when performing the actual build.
I'll clarify that Delocate 0.11.0 has PR #198 applied which is the cause of the "error". For other devs, this was able to reveal compatibility issues unknown before the release of Delocate 0.11.0. Delocate 0.10.7 does not verify MacOS version compatibility, Delocate 0.11.0 does and will error on any detected compatibility issues.
It's possible that the wheels being fixed by Delocate 0.10.7 are not compatible with MacOS 11.5 and are mislabeled (because Delocate 0.10.7 does not verify MacOS versions). It's possible libraries on a macos-14-large
runner are not compatible with earlier versions of MacOS.
A libraries minimum MacOS version is determined from that libraries LC_BUILD_VERSION
.
I'm not experienced enough to explain why the libraries from macos-14-large
have strange minimum versions for its libraries compared to macos-14
.
I'll clarify that Delocate 0.11.0 has PR #198 applied which is the cause of the "error". For other devs, this was able to reveal compatibility issues unknown before the release of Delocate 0.11.0. Delocate 0.10.7 does not verify MacOS version compatibility, Delocate 0.11.0 does and will error on any detected compatibility issues.
It's possible that the wheels being fixed by Delocate 0.10.7 are not compatible with MacOS 11.5 and are mislabeled (because Delocate 0.10.7 does not verify MacOS versions). It's possible libraries on a
macos-14-large
runner are not compatible with earlier versions of MacOS.A libraries minimum MacOS version is determined from that libraries
LC_BUILD_VERSION
.I'm not experienced enough to explain why the libraries from
macos-14-large
have strange minimum versions for its libraries compared tomacos-14
.
I just wanted to stress that the list provided by the tool regarding compatible tags does not include the one it ends up inserting into the filename. I've assumed this is a list of compatible tags for the wheel in question.
Compatible tags: 1835
cp38-cp38-macosx_13_0_x86_64
cp38-cp38-macosx_13_0_intel
cp38-cp38-macosx_13_0_fat64
cp38-cp38-macosx_13_0_fat32
cp38-cp38-macosx_13_0_universal2
cp38-cp38-macosx_13_0_universal
...
Which tool/command gives a list of compatible tags?
I realise i mistook the origin of that output, wrongfully thinking it came from delocate-listdeps
, but it origin is actually python -m build --wheel . --outdir /tmp/carolina_dist_unfixed
.
Sorry about that.
I still don't understand why the wheels actually work when I rename them. Most tags I've seen used for wheels are on the format of 12_0, 13_0, 14_0 just indicating the major version.
If the wheels fixed by Decloate in macos-14-large
output with a later version of MacOS but still work on earlier versions then the libraries provided by that runner have an incorrect target version (LC_BUILD_VERSION
is wrong and should be lower). That's my conclusion when I follow the logic at the moment.
The libraries in macos-14-large
should have the same targets as macos-14
but don't. I think this because in the CI run you've posted the macos-14
builds manage to pass and this is my only explanation for why.
same issue here, my wheel gets renamed with an unsupported tag: macosx_13_6_x86_64
same issue here, my wheel gets renamed with an unsupported tag: macosx_13_6_x86_64
What was the tag you expected? And did you set MACOSX_DEPLOYMENT_TARGET
?
I was expecting macosx_13_0_x86_64
Now if I set MACOSX_DEPLOYMENT_TARGET=13.0 I see the reason ; it flags all my python extensions modules as incompatible (but not my c++ library on which they depend):
delocate.libsana.DelocationError: Library dependencies do not satisfy target MacOS version 13.0:
memoryview.cpython-310-darwin.so has a minimum target of 13.6
...
_statistics.cpython-310-darwin.so has a minimum target of 13.6
note that it does not happen on arm64
I was expecting macosx_13_0_x86_64
Now if I set MACOSX_DEPLOYMENT_TARGET=13.0 I see the reason ; it flags all my python extensions modules as incompatible (but not my c++ library on which they depend):
Was that Python installation built locally? Perhaps with MACOSX_DEPLOYMENT_TARGET=13.6
in the environment?
no, I'm using Python from homebrew but its not even linked to Python explicitely:
otool -L openturns/memoryview.cpython-38-darwin.so
openturns/memoryview.cpython-38-darwin.so:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1336.0.0)
How does one affect the MACOSX_DEPLOYMENT_TARGET
or MacOS.version
of a program built by brew? I'm not experienced with it and I don't have the platform to mess around with it.
It turns out it was cmake that decided set the min osx version, I worked around it with:
-DCMAKE_OSX_DEPLOYMENT_TARGET=13.0
https://cmake.org/cmake/help/latest/variable/CMAKE_OSX_DEPLOYMENT_TARGET.html
My understanding is that for any version of macos > 10, pip
and packaging
will only accept macosx_X_0
wheels, where X
is the platform major version. So a wheel named carolina-1.0.16-cp311-cp311-macosx_13_6_x86_64.whl
will always be rejected, and it should instead be named carolina-1.0.16-cp311-cp311-macosx_13_0_x86_64.whl
.
See this comment and subsequent replies for discussion.
Describe the bug Tool
delocate-wheel
alters tag in wheel name to seemingly invalid tag/number We are using GitHub-runners to generate som large macOS wheels for repositoryCarolina
To Reproduce
The wheel before we use
delocate
:Running
delocate-wheel
:I see that there are dependencies that would indicate this to be set to
13_x
, but as far as I can tell the wheel won't work when13_6
is used. If I rename the file I can install it locally. The same is true for11_0
.Wheels used/generated
carolina-1.0.16.dev3+g42cf9bc-cp311-cp311-macosx_13_6_x86_64.whl.tar.gz
carolina-1.0.16.dev2+g9c153fd-cp311-cp311-macosx_11_0_x86_64.whl.tar.gz
Platform (please complete the following information):
Additional context Works with previous release, 0.10.7