Re: [Python-Help] Unable to bootstrap Python 3 install

On Thu, Jun 16, 2022 at 7:54 PM Christian Heimes <[email protected]> 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.