Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
2 of 5 tasks
haampie opened this issue Oct 18, 2024 · 6 comments
Assignees
Labels
bug Something isn't working

Comments

@haampie
Copy link

haampie commented Oct 18, 2024

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:

  • Ubuntu
  • macOS
  • Windows

Runner type:

  • Hosted
  • Self-hosted

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
Copy link
Author

haampie commented Oct 18, 2024

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.

@haampie haampie changed the title Python 3.7 broken on macos-13 Python 3.7 broken on macos-13: ImportError: dlopen(...): Library not loaded: /usr/local/opt/zlib/lib/libz.1.dylib Oct 19, 2024
@haampie haampie changed the title Python 3.7 broken on macos-13: ImportError: dlopen(...): Library not loaded: /usr/local/opt/zlib/lib/libz.1.dylib Python 3.7 broken on macos-13 due to ImportError: dlopen(...): Library not loaded: /usr/local/opt/zlib/lib/libz.1.dylib Oct 19, 2024
@priyagupta108
Copy link
Contributor

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

@aparnajyothi-y
Copy link
Contributor

aparnajyothi-y commented Oct 29, 2024

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
Copy link
Author

haampie commented Oct 29, 2024

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
Copy link
Contributor

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
Copy link
Author

haampie commented Nov 12, 2024

Upon investigation

That's exactly what I shared when opening the issue.

I don't see the point of a setup-python action with bit-rotten old python versions. Would you consider patching binaries with install_name_tool and re-upload them? That should do the trick. EOL does not mean there are suddenly no users.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants