Bootstrapping python311 on LoongArch fails due to dynlib()
Hello, with python311, I'm working on probably the last package which needs to be bootstrapped for LoongArch before the port can be fully bootstrapped on OBS. Unfortunately, I'm currently stuck in the process as I'm struggling with the dynamic libraries which get installed into /usr/lib64/python3.11/lib-dynload/. On x86_64, the shared libraries were renamed to include the Python version as well as the target triplet in the filename. In my Debian unstable chroot, the shared libraries are built successfully, but their names don't contain any information generated by the dynlib() macro. Thus, I only got filenames like: /(...)/BUILDROOT/usr/lib64/python3.11/lib-dynload/math.cpython-311.so instead of: /(...)/BUILDROOT/usr/lib64/python3.11/lib-dynload/math.cpython-311.so I have tried finding the bits that are responsible for setting the filenames for the shared library files, but I can't find those. Does anyone have any idea how that voodoo mechanism works? Thanks, Adrian
On Sun Dec 1, 2024 at 6:47 PM CET, John Paul Adrian Glaubitz via openSUSE Factory wrote:
Thus, I only got filenames like:
/(...)/BUILDROOT/usr/lib64/python3.11/lib-dynload/math.cpython-311.so
instead of:
/(...)/BUILDROOT/usr/lib64/python3.11/lib-dynload/math.cpython-311.so
Is it just too late or these are really the same? What do you get? Matěj -- http://matej.ceplovi.cz/blog/, @mcepl@floss.social GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 All men's miseries derive from not being able to sit in a quiet room alone. -- Blaise Pascal
On Sun, 2024-12-01 at 23:31 +0100, Matěj Cepl wrote:
On Sun Dec 1, 2024 at 6:47 PM CET, John Paul Adrian Glaubitz via openSUSE Factory wrote:
Thus, I only got filenames like:
/(...)/BUILDROOT/usr/lib64/python3.11/lib-dynload/math.cpython-311.so
instead of:
/(...)/BUILDROOT/usr/lib64/python3.11/lib-dynload/math.cpython-311.so
Is it just too late or these are really the same? What do you get?
It has to know the arch triplet: glaubitz@suse-laptop:/usr/lib64/python3.11/lib-dynload> ls -l |head total 5224 -rwxr-xr-x 1 root root 65696 Nov 11 13:43 array.cpython-311-x86_64-linux-gnu.so -rwxr-xr-x 1 root root 61456 Nov 11 13:43 _asyncio.cpython-311-x86_64-linux-gnu.so -rwxr-xr-x 1 root root 44016 Nov 11 13:43 audioop.cpython-311-x86_64-linux-gnu.so -rwxr-xr-x 1 root root 31832 Nov 11 13:43 binascii.cpython-311-x86_64-linux-gnu.so -rwxr-xr-x 1 root root 15000 Nov 11 13:43 _bisect.cpython-311-x86_64-linux-gnu.so -rwxr-xr-x 1 root root 48376 Nov 11 13:43 _blake2.cpython-311-x86_64-linux-gnu.so -rwxr-xr-x 1 root root 27568 Nov 11 13:43 _bz2.cpython-311-x86_64-linux-gnu.so -rwxr-xr-x 1 root root 39984 Nov 11 13:43 cmath.cpython-311-x86_64-linux-gnu.so -rwxr-xr-x 1 root root 153888 Nov 11 13:43 _codecs_cn.cpython-311-x86_64-linux-gnu.so glaubitz@suse-laptop:/usr/lib64/python3.11/lib-dynload> Doesn't speak for cpython that you have to encode this for every triplet separately when they could just infer that information from config.sub. Adrian
Maybe it's using Python's definition: https://github.com/python/cpython/blob/main/Misc/platform_triplet.c
In Python 3.12 the platform triplet detection code is here. https://github.com/python/cpython/blob/3.12/configure.ac#L980 Python 3.11 does not have the loongarch part.
On Mon, 2024-12-02 at 03:39 +0000, JS via openSUSE Factory wrote:
In Python 3.12 the platform triplet detection code is here. https://github.com/python/cpython/blob/3.12/configure.ac#L980
Python 3.11 does not have the loongarch part.
Ah, that explains the problem. I have added a hack to rename the SO files in any case. Adrian
participants (3)
-
John Paul Adrian Glaubitz -
JS -
Matěj Cepl