You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(This is a hesitant report: I'm not 100% sure about where the issue is attributable to. Also, I'm guessing that apparent problems with the xmlsec PyPI packages would be reportable here – please redirect me if that's wrong.)
This is on macOS 15.4, which provides Python 3.9.6.
After I install xmlsec (1.3.15) into a venv, from PyPI, I'm unable to import it because, it appears, it contains references to homebrew libraries which don't exist.
% python
Python 3.9.6 (default, Mar 12 2025, 20:22:46)
[Clang 17.0.0 (clang-1700.0.13.3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import xmlsec
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: dlopen([PATH-TO-VENV]/lib/python3.9/site-packages/xmlsec.cpython-39-darwin.so, 0x0002): Library not loaded: /opt/homebrew/opt/libxmlsec1/lib/libxmlsec1-openssl.1.dylib
Referenced from: <FD0F84B5-77CB-3D58-9D97-52ECC5125326> [PATH-TO-VENV]/lib/python3.9/site-packages/xmlsec.cpython-39-darwin.so
Reason: tried: '/opt/homebrew/opt/libxmlsec1/lib/libxmlsec1-openssl.1.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/opt/homebrew/opt/libxmlsec1/lib/libxmlsec1-openssl.1.dylib' (no such file), '/opt/homebrew/opt/libxmlsec1/lib/libxmlsec1-openssl.1.dylib' (no such file)
>>>
And sure enough, if I use dyld_info to look at the libraries that library loads, they refer to homebrew (see below), and this is corroborated (also below) by looking at the load commands using otool -l (there, I notice also a reference to /Users/amin which suggests this may not have been build in an entirely clean environment). There is no homebrew cryptex on the machine, and no /opt/homebrew.
I have had homebrew on this machine, but deleted it, which meant that my first suspicion was that there was some hangover from that, that was messing with the dyld load path (and it's been a while since I had to be fully familiar with dyld's gymnastics). But I don't think that's the explanation, since this was a pip binary install (also there's no user amin on my machine, ruling out that path being synthesised dynamically).
I tried a --no-binary install of xmlsec, but it failed (the docs note that this is a tricky build). That's fine – I'd rather install a PyPI binary than attempt to integrate a non-trivial build into my current build-system.
Thus it appears that the PyPI package depends on a homebrew library which is present on the package build machine, but not on mine. My hesitation is because I've never had to become familiar with the internal details of Python package building, and because I'm aware dyld has tricked me in the past, so I'm reluctant to make confident statements here.
(This is a hesitant report: I'm not 100% sure about where the issue is attributable to. Also, I'm guessing that apparent problems with the
xmlsec
PyPI packages would be reportable here – please redirect me if that's wrong.)This is on macOS 15.4, which provides Python 3.9.6.
After I install
xmlsec
(1.3.15) into a venv, from PyPI, I'm unable to import it because, it appears, it contains references to homebrew libraries which don't exist.And sure enough, if I use
dyld_info
to look at the libraries that library loads, they refer to homebrew (see below), and this is corroborated (also below) by looking at the load commands usingotool -l
(there, I notice also a reference to/Users/amin
which suggests this may not have been build in an entirely clean environment). There is no homebrew cryptex on the machine, and no/opt/homebrew
.I have had homebrew on this machine, but deleted it, which meant that my first suspicion was that there was some hangover from that, that was messing with the dyld load path (and it's been a while since I had to be fully familiar with dyld's gymnastics). But I don't think that's the explanation, since this was a
pip
binary install (also there's no useramin
on my machine, ruling out that path being synthesised dynamically).I tried a
--no-binary
install ofxmlsec
, but it failed (the docs note that this is a tricky build). That's fine – I'd rather install a PyPI binary than attempt to integrate a non-trivial build into my current build-system.Thus it appears that the PyPI package depends on a homebrew library which is present on the package build machine, but not on mine. My hesitation is because I've never had to become familiar with the internal details of Python package building, and because I'm aware dyld has tricked me in the past, so I'm reluctant to make confident statements here.
Checking the load commands seems to corroborate this:
The text was updated successfully, but these errors were encountered: