Repository navigation
Incorrect installation of lib-dynload for custom builds on openSUSE #131425
Description
Activity
As an openSUSE user, I had this problem as well. I think I did a combination of
--exec-prefix=...and altinstall. I can't remember exactly the command and I won't be back until Sunday. I can check at that time.- changed the title
[-]installation form source on "openSUSE Leap 15.5" and "SUSE Linux Enterprise Server 15 SP6" - incorrect location of python3.13/lib-dynload[/-][+]Incorrect installation of `lib-dynload` for custom builds on openSUSE[/+]on Mar 18, 2025 I think I actually also specified the libdir explicitly so that it doesn't use lib64 but lib instead. I'll see if I can write better installation instructions for openSUSE
I think that's an error in the configure script. And it's not only OPENSUSE - it's also SLES
Yes I think so as well but I'll need to confirm it properly. I'll also tag those responsible for openSUSE contact
could someone figure out what causes this difference?
dynamic libraries are installed to$RUN/3.13.2/lib64/python3.13/lib-dynload
but internally sys.path uses$RUN/3.13.2/lib/python3.13/lib-dynloadhow are those 2 paths defined in configure? what is different on SUSE that causes the difference?
could someone figure out what causes this difference? dynamic libraries are installed to $RUN/3.13.2/lib64/python3.13/lib-dynload but internally sys.path uses $RUN/3.13.2/lib/python3.13/lib-dynload
how are those 2 paths defined in configure? what is different on SUSE that causes the difference?
I believe it’s because the configure script doesn’t handle the possibility that
CONFIG_SITEmay be set. I’m pasting a part of my analysis from #108819.Since
CONFIG_SITEis set to/usr/share/site/x86_64-pc-linux-gnu, said file is sourced (this has the effect of settinglibdirto'${exec_prefix}/lib64'), and the makefile generated contains, among other things:LIBDIR= ${exec_prefix}/lib64 PLATLIBDIR= libwhich I think is the reason
lib-dynloadwent in the wrong location:BINLIBDEST= $(LIBDIR)/python$(VERSION) DESTSHARED= $(BINLIBDEST)/lib-dynloadwhile the remaining files, which depend on
PLATLIBDIR(which is hard-coded inconfigure.ac) went in the expected location.Reacted by Filipe LaínsReacted by Filipe Laínsif you give me the right git commands to download the correct files (my git knowledge is barely existant....)
if you give me the right git commands to download the correct files (my git knowledge is barely existant....)
In that case, I'd recommend you use the Github CLI, which simplifies this quite significantly 😊
Using it, it should be as straightforward as:
$ gh pr checkout 133163
Otherwise, you'll have to manually add a remote for my fork, and then checkout the correct branch.
$ git remote add ffy00 https://github.com/FFY00/cpython.git $ git fetch ffy00 $ git checkout gh-108819
wouldn't I also need a git clone? Github CLI is not really an option
$ git clone https://github.com/FFY00/cpython.git
$ git remote add ffy00 https://github.com/FFY00/cpython.git
$ git fetch ffy00
$ git checkout gh-108819Reacted by Filipe LaínsI obviously don’t see anything like this with our system packages:
Python 3.13.3 (main, Apr 11 2025, 19:56:42) [GCC] Type 'copyright', 'credits' or 'license' for more information IPython 8.31.0 -- An enhanced Interactive Python. Type '?' for help. In [1]: import sys In [2]: sys.path Out[2]: ['/usr/bin', '/usr/lib64/python313.zip', '/usr/lib64/python3.13', '/usr/lib64/python3.13/lib-dynload', '', '/home/matej/.local/lib/python3.13/site-packages', '/usr/lib/python3.13/site-packages/setuptools/_vendor', '/home/matej/archiv/knihovna/repos/osc', '/home/matej/archiv/2024/SUSE/projekty/maintenance-toolkit', '/home/matej/archiv/knihovna/repos/epy/src', '/usr/lib64/python3.13/site-packages', '/usr/lib64/python3.13/site-packages/PIL', '/usr/lib64/python3.13/_import_failed', '/usr/lib/python3.13/site-packages'] In [3]:However, we have plenty of patches and configuration. Perhaps looking at https://build.opensuse.org/package/show/devel:languages:python:Factory/python313 would show something interesting. However, to be honest, I don’t care that much about user-build builds; I think we are doing pretty good job in packaging Python ourselves and we support those.
That'd be because you set
--with-platlibdirto match the systemlibdir, so no mismatch would happen there.looks good:
git clone https://github.com/python/cpython.git cd cpython/ git remote add ffy00 https://github.com/FFY00/cpython.git git fetch ffy00 git checkout gh-108819 ./configure --prefix=/lfs/lfs19/python/3.12.7 make make install ~/cpython> find /lfs/lfs19/python/3.12.7/ -name lib-dynload /lfs/lfs19/python/3.12.7/lib/python3.14/lib-dynload ~/cpython> /lfs/lfs19/python/3.12.7/bin/python3 Python 3.14.0a7+ (heads/gh-108819:a2b43c9d137, Apr 29 2025, 12:15:56) [GCC 7.5.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from _posixsubprocess import fork_exec as _fork_exec >>>Reacted by Filipe LaínsFTR, I usually solve the installation issue by supplying
--with-platlibdir=lib64since the default one falls back tolibinstead oflib64.
Bug report
Bug description:
from
Python-3.13.2.tar.xzdynamic libraries are installed to
$RUN/3.13.2/lib64/python3.13/lib-dynloadbut internally
sys.pathuses$RUN/3.13.2/lib/python3.13/lib-dynloadsetting a link resolves the
errors that show up:
CPython versions tested on:
3.13
Operating systems tested on:
Linux