Step one: build a GCC cross compiler which is linked to a newer glibc than what your build system is running, or a different version of musl if that's what you're using.
Step two: cross-compile Python against the new libc exactly the same way you would cross-compile any other program, using the same triple for build/host/target, such as x86_64-linux-gnu. Step three: watch the build almost complete, then enjoy the fireworks at the end when Python attempts to load freshly compiled .so objects into the host system Python, crashing and burning. Step four: apply Xavier's patch, fix the problem, and then move on with your life. On Fri, 17 Jun 2022 13:10:28 +0200 Victor Stinner <vstin...@python.org> wrote: > On Thu, Jun 16, 2022 at 7:54 PM Christian Heimes <christ...@python.org> wrote: > > What Victor means that we would like to have clear instructions how to > > reproduce the problem ourselves. Could you please provide step by step > > instructions how I could set up a build environment on a X86_64 PC with > > a standard Linux distro (Fedora, Debian/Ubuntu)? > > > > What packages have to be installed? Do I have to download any extra > > packages? How do I have to set up my build environment? Which commands > > do I have to execute? Is there a container image available that comes > > with everything pre-installed? > > I don't know if it helps, but I managed to build Python linked to the > musl libc using musl-gcc. > > The build and the built Python just work on Fedora 36. It doesn't seem > to reproduce the discussed build issue. > > Commands: > --- > sudo dnf install musl-libc musl-gcc > git clean -fdx > ./configure --with-pydebug CC=musl-gcc LD=musl-gcc > make > --- > > Interesting part of the build: > --- > Platform "x86_64-pc-linux-musl" with compiler "gcc" is not supported by the > CPython core team, see https://peps.python.org/pep-0011/ for more information. > --- > > The executable is linked to ld-musl-x86_64.so.1: > --- > $ ldd ./python > linux-vdso.so.1 (0x00007fffbd6b6000) > ld-musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x00007f5253669000) > --- > > Python works as expected: > --- > $ ./python > Python 3.12.0a0 (heads/main:4beee0c7b0, Jun 17 2022, 12:23:58) [GCC > 12.1.1 20220507 (Red Hat 12.1.1-1)] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> 1+1 > 2 > --- > > The _struct extension works as expected and is linked to musl: > --- > $ ./python > >>> import _struct > >>> _struct.pack('I', 4) > b'\x04\x00\x00\x00' > >>> _struct > <module '_struct' from > '/home/vstinner/python/main/build/lib.linux-x86_64-3.12-pydebug/_struct.cpython-312d-x86_64-linux-musl.so'> > > $ ldd > /home/vstinner/python/main/build/lib.linux-x86_64-3.12-pydebug/_struct.cpython-312d-x86_64-linux-musl.so > linux-vdso.so.1 (0x00007ffedb5fd000) > ld-musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x00007f4be8cd0000) > --- > > > There are some compiler warnings and build errors, but I didn't pay > attention to them since I was interested by the discussed build issue. > > > --- > > > I also tried something closer to "cross-compiler", but I got it wrong, > since Python is still linked to the glibc, not to musl. Again, I don't > reproduce the issue. > > By the way, what is the issue? Is it a build error? > > bpo-39399 mentions the error "ImportError: libc.so: cannot open shared > object file" on "import struct". > > > Get Python 3.12 on the host (installed in /opt/py3.12): > --- > git clean -fdx > ./configure --prefix=/opt/py3.12 > make > make install > --- > > Fake buildchain: > --- > $ mkdir cross-build > $ cd cross-build/ > $ ln -s /usr/bin/readelf x86_64-pc-linux-musl-readelf > $ cd .. > --- > > Build: > --- > $ sudo dnf install musl-libc # install musl > > $ cat config-musl > ac_cv_file__dev_ptmx=no > ac_cv_file__dev_ptc=no > > $ cat build.sh > set -e -x > PATH=$PATH:cross-build/ \ > CONFIG_SITE=config-musl \ > ./configure \ > --with-build-python=/opt/py3.12/bin/python3.12 \ > --build=x86_64-pc-linux-gnu \ > --host=x86_64-pc-linux-musl \ > --with-pydebug \ > --disable-ipv6 \ > --cache-file=../configure-musl.cache > > $ ./build.sh > $ make > --- > > Sadly, the built executable is linked to the glibc: > --- > $ ldd ./python > linux-vdso.so.1 (0x00007ffcd89d0000) > libm.so.6 => /lib64/libm.so.6 (0x00007f54d2a60000) > libc.so.6 => /lib64/libc.so.6 (0x00007f54d285f000) > /lib64/ld-linux-x86-64.so.2 (0x00007f54d2b62000) > --- > > > Well, since glibc and musl are available and just work on my system, > I'm not sure if my test makes any sense :-) Should the target libc not > work on the host to reproduce the issue? > > Victor > -- > Night gathers, and now my watch begins. It shall not end until my death. -- Nathan Cline <n...@killthe.net> _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/UE6AJ7L7RDMMDEXEVVIP7AXCTYLC25T5/ Code of Conduct: http://python.org/psf/codeofconduct/
