actions / setup-python

Set up your GitHub Actions workflow with a specific version of Python
MIT License
1.74k stars 551 forks source link

Python 3.7 broken on macos-13 due to `ImportError: dlopen(...): Library not loaded: /usr/local/opt/zlib/lib/libz.1.dylib` #964

Open haampie opened 1 month ago

haampie commented 1 month ago

Description:

The Python 3.7.17 binaries for macos-13 on x86-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:

    import binascii
ImportError: dlopen(/Users/runner/hostedtoolcache/Python/3.7.17/x64/lib/python3.7/lib-dynload/binascii.cpython-37m-darwin.so, 0x0002): Library not loaded: /usr/local/opt/zlib/lib/libz.1.dylib

Indeed this Python library encodes a path to a non-existent libz.1.dylib:

$ wget -q https://github.com/actions/python-versions/releases/download/3.7.17-5356448435/python-3.7.17-darwin-x64.tar.gz                                                                                                                              

$ tar xf python-3.7.17-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/local/opt/zlib/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.13)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.0.0)

$ file /usr/local/opt/zlib/lib/libz.1.dylib
/usr/local/opt/zlib/lib/libz.1.dylib: cannot open `/usr/local/opt/zlib/lib/libz.1.dylib' (No such file or directory)

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 the setup-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/*

haampie commented 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.

priyagupta108 commented 1 month ago

Hi @haampie 👋, Thank you for your report. We'll investigate the issue and get back to you with the details!

aparnajyothi-y commented 3 weeks ago

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.

Screenshot 2024-10-24 at 8 10 59 PM
haampie commented 3 weeks ago

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.

aparnajyothi-y commented 1 week ago

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.

haampie commented 1 week ago

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.