Repository navigation
exec_prefix not found when prefix is found at runtime when install tree is moved #107658
Description
Background: for years we've distributed a copy of python (starting with version 2.7 or before) with our app and have depended on python finding prefix & exec_prefix when they're different than the directories specified when configure is run. On macOS, we use a framework enabled build and install_name_tool to rewrite module loads paths so they are relative.
When python 3.12b4 is built with macOS frameworks enabled and the python install tree is moved, exec_prefix is not set to the correct directory even though prefix is. The bug could also affect other builds and other platforms.
To reproduce on macOS --
cd cpython
mkdir ../install
./configure --with-pydebug --prefix=`pwd`/../install --enable-framework=`pwd`/../install/lib
make install
mv ../install ../install.moved
DYLD_FRAMEWORK_PATH=pwd/../install.moved/lib ../install.moved/bin/python3
>> import sys
>> sys.prefix
'/Users/jpe/install.moved/lib/Python.framework/Versions/3.13'
>>> sys.exec_prefix
'/Users/jpe/cpython/../install/lib/Python.framework/Versions/3.13'
The problem is in Modules/getpath.py -- it looks for the prefix based on the library variable but does not do this for exec_prefix. I plan to submit a pull request with a potential fix.
Activity
jpe commentedon Aug 5, 2023
I just realized that in the steps to reproduce above, I had replaced the absolute bin/python3 symbolic link with a relative one. The relative link is created with
ln -sf ../lib/Python.framework/Versions/3.13/bin/python3(the pwd is the bin directory)dmnq-f commentedon Jan 28, 2026
I'm currently working at a few fixes in this area and while doing that, I noticed that this issue and the related PR seem to be fixed/obsolete – i.e. it's fixed on main (3.15) as a side effect of PR 127972 which extended dladdr-based library detection to all platforms with dlfcn.h. With
librarynow populated for shared-library builds,getpath.pyresolves prefix from the loadedlibpythonpath, andexec_prefixderives from it correctly.FFY00 commentedon Mar 3, 2026
Thanks for looking into this!
It looks like this was fixed in GH-127974.
GH-127972 shouldn't have any effect on the described scenario, as before that change,
librarywas already populated for macOS framework installs — the PR extended that to any platform wheredladdris available, unconditionally.