Repository navigation
macOS built Python3.11b5 can't find lib-dynload in relocatable framework if framework is relocated and python run from external symlink #95400
Description
Bug report
A build of Python 3.11b5's fails to find lib-dynload path if the following normally ok combination of criteria are met:
- The framework is made or modified in such a away to be relocatable (dynamic links are relative using @loader_path, etc) instead of absolute path
- The framework is installed in a location it wasn't built at
- python is executed by a symlink from elsewhere
Your environment
To reproduce this easily, I decompressed the installable package into my home directory, making a framework structure that would normally run. I do have to modify the linking to work relocated, using the following commands:
install_name_tool -change /Library/Frameworks/Python.framework/Versions/3.11/Python @loader_path/../Python Python.framework/Versions/3.11/bin/python3.11
install_name_tool -change /Library/Frameworks/Python.framework/Versions/3.11/Python @loader_path/../../../../Python Python.framework/Versions/3.11/Resources/Python.app/Contents/MacOS/Python
I then symlink the python executable.
ln -s Python.framework/Versions/3.11/bin/python3.11 python3.11
the following command works fine
./Python.framework/Versions/3.11/bin/python3.11 -c "import math"
while this does not
./python3.11 -c "import math"
Could not find platform dependent libraries <exec_prefix>
Traceback (most recent call last):
File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'math'
even though the shell itself works normally, just the lib-dynload is not being found.
I can make it work with the attached patch, but I don't assume it is the correct way to fix it
relocated_framework.patch.gz
.
Activity
ned-deily commentedon Jul 29, 2022
Just to be clear, are you saying that the steps you outlined to make the framework installation relocatable (not something that we claim to support) works as you expect when using a python.org 3.10.x macOS installation, i.e. this is a new problem in 3.11?
jpgarcia-ssec commentedon Jul 29, 2022
Correct, this is new to 3.11. The same modification to the latest 3.10 installable binaries will still be able to discover lib-dynload (and find and load the math module), regardless of where the python binary is symlinked to and run. The change in bevhaior based on the location of the used symlink to the executable, as opposed to the executable itself, is unexpected.
CI : Set `PYTHONHOME` on macOS
dmnq-f commentedon Jan 28, 2026
This also is fixed on main (mostly by #127974 which added
exec_prefix = prefixfallback whenPLATSTDLIB_LANDMARKexists at prefix, preventing the stale compile-time fallback. For main (3.15), both direct and symlink invocation work (framework build, dylib rewrite, move, symlink from outside)