Open haampie opened 1 month ago
It seems like 3.7.16 is NOT affected by this issue:
$ wget -q https://github.com/actions/python-versions/releases/download/3.7.16-4343262312/python-3.7.16-darwin-x64.tar.gz
$ tar xf python-3.7.16-darwin-x64.tar.gz
$ otool -L ./lib/python3.7/lib-dynload/binascii.cpython-37m-darwin.so
./lib/python3.7/lib-dynload/binascii.cpython-37m-darwin.so:
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)
it records system libz.1.dylib by path.
My guess is lack of build isolation from homebrew binaries when you build Python.
Hi @haampie 👋, Thank you for your report. We'll investigate the issue and get back to you with the details!
Hello, Thank you of once again for creating this issue. We have tested it on macOS-13 and were unable to reproduce the issue from our end. Please find the screenshots for reference. If the issue persists on your end with macOS-13, kindly provide a repro link so we can assist you further.
Feel free to reach out if you need further clarifications.
Here's a similar minimal working example with readline:
https://github.com/haampie/macos-13-setup-python-repro
fails on 3.7.17, fine on 3.7.16
The same thing happens with libz under certain circumstances.
Hello @haampie, Thank you for providing the repro links. Upon investigation, the issue with Python 3.7.17 on macOS 13 is caused by a dependency issue related to zlib. Python 3.7.17 was compiled with a dependency on Homebrew’s zlib, but macOS 13 no longer ships with zlib by default. As a result, Python fails when attempting to load libz.1.dylib.
This issue does not occur with Python 3.7.16 because it does not rely on Homebrew's zlib. Instead, Python 3.7.16 is likely using the system’s libSystem library, which includes zlib by default. As a result, Python 3.7.16 can use the system version of zlib without issue, thereby avoiding the problem you're encountering on macOS 13.
Since Python 3.7.17 is EOL (End of Life) and no longer receives updates, we recommend upgrading to a newer version of Python that does not rely on these missing dependencies and is fully compatible with macOS 13.
Please let us know if you have any further questions or support needed.
Upon investigation
That was all what I told you when I opened the issue.
I don't see the point of setup-python if old versions are broken. You could just patch the binaries and re-upload.
EOL does not mean there are suddenly no users.
Description:
The
Python 3.7.17
binaries formacos-13
onx86-64
are broken: they depend on Homebrew's libz.1.dylib, but it's not installed by default. This probably should have been system zlib instead.It causes failure of certain scripts, depending on import order, like this:
Indeed this Python library encodes a path to a non-existent
libz.1.dylib
:I've seen this issue so far only with the latest Python 3.7
3.7.17
, not with other Python versions. (I only checked the last 3.6 release: it correctly refers to system libz.1.dylib.)The workaround is to
brew install zlib
before using Python from thesetup-python
action. But that is bizarre.Action version: Specify the action version
Platform:
Runner type:
Tools version: Python 3.7.17
Repro steps:
Haven't managed to get a small MWE yet: it is load order dependent, and you have to let python
import base64
before it has loaded system libz.1.dylib through another code path. I think the error triggers using multiprocessing in spawn mode.Expected behavior: Python loads libz.dylib from the system.
Actual behavior: Python fails to load libz.dylib because it tries refers to a non-existing path
/usr/local/lib/*