-
-
Notifications
You must be signed in to change notification settings - Fork 30k
-
-
Notifications
You must be signed in to change notification settings - Fork 30k
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
make install doesn't respect configure --with-platlibdir=lib64 #84861
Comments
bpo-1294959 added --with-platlibdir option to configure, but "make install" doesn't fully respect it. Example: ./configure --prefix /opt/py39b1 --with-platlibdir=lib64 I get: /opt/py39b1/lib/python3.9/lib-dynload/readline.cpython-39-x86_64-linux-gnu.so whereas Python doesn't use this directory: $ /opt/py39b1/bin/python3.9 -m site
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
sys.path = [
'/home/vstinner/Python-3.9.0b1',
'/opt/py39b1/lib64/python39.zip',
'/opt/py39b1/lib64/python3.9',
'/opt/py39b1/lib64/lib-dynload',
'/home/vstinner/.local/lib/python3.9/site-packages',
'/opt/py39b1/lib64/python3.9/site-packages',
]
USER_BASE: '/home/vstinner/.local' (exists)
USER_SITE: '/home/vstinner/.local/lib/python3.9/site-packages' (exists)
ENABLE_USER_SITE: True Python looks into /opt/py39b1/lib64/lib-dynload ("lib64") make install writes into /opt/py39b1/lib/python3.9/lib-dynload/ ("lib") |
The Fedora package is built using --libdir=/usr/lib64 --with-platlibdir=lib64 which works around the issue: + /builddir/build/BUILD/Python-3.9.0b1/configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-platlibdir=lib64 --enable-ipv6 --enable-shared --with-computed-gotos=yes --with-dbmliborder=gdbm:ndbm:bdb --with-system-expat --with-system-ffi --enable-loadable-sqlite-extensions --with-dtrace --with-lto --with-ssl-default-suites=openssl --with-valgrind --without-ensurepip --enable-optimizations |
I tested manually my fix: it works as expected. Install: ./configure --prefix /opt/py39_lib64 --with-platlibdir=lib64 Test: $ /opt/py39_lib64/bin/python3.9 -m site
sys.path = [
'/',
'/opt/py39_lib64/lib64/python39.zip',
'/opt/py39_lib64/lib64/python3.9',
'/opt/py39_lib64/lib64/python3.9/lib-dynload',
'/home/vstinner/.local/lib/python3.9/site-packages',
'/opt/py39_lib64/lib64/python3.9/site-packages',
]
USER_BASE: '/home/vstinner/.local' (exists)
USER_SITE: '/home/vstinner/.local/lib/python3.9/site-packages' (exists)
ENABLE_USER_SITE: True
$ /opt/py39_lib64/bin/python3.9
Python 3.9.0b2+ (heads/3.9:6cb24a035c, Jun 9 2020, 16:43:12)
[GCC 10.1.1 20200507 (Red Hat 10.1.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import _asyncio
>>> _asyncio
<module '_asyncio' from '/opt/py39_lib64/lib64/python3.9/lib-dynload/_asyncio.cpython-39-x86_64-linux-gnu.so'> |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: