SergioandClaude Opus 5
1940a94a11
Decision del usuario. CPython construye sus modulos opcionales como .so
COMPARTIDOS y las .a del corpus NO son PIC («relocation R_X86_64_PC32 against
symbol 'stdscr'»), asi que declararlas en [deps] NO funciona: se probo una
por una. Las libs del rootfs son compartidas y si sirven.
Añadidos: libffi-dev ncurses-dev readline-dev sqlite-dev bzip2-dev xz-dev
expat-dev. Resultado VERIFICADO: el guardian de python3 importa los OCHO
modulos (_ctypes _curses readline sqlite3 bz2 lzma zlib pyexpat) y pasa. De
paso `libffi` sale de [deps]: ya lo aporta el lab.
openssl-dev NO va, deliberado: se de-Alpinizo porque el host-tool del kernel
enlaza el openssl del corpus desde el overlay; devolverlo podria cambiar el
artefacto del kernel. python3 sigue sin `ssl`.
Y SE CIERRA EL AGUJERO QUE ESTO ABRIA. Esas libs del rootfs ahora entran en
el CONTENIDO de un artefacto, asi que su version es parte de su identidad ⇒
van a TOOLCHAIN_PREFIXES. Sin eso habriamos reabierto en pequeño el mismo
fallo que 58d3161 cerro: instalar los -dev subio ncurses 6.5→6.6 y readline
8.3.1→8.3.3 —sin tocar gcc/rust/musl, lo confirmo el lock— y ese salto habria
cambiado el python3 producido SIN mover su direccion.
Coste: la huella del lab cambia ⇒ el corpus se re-hashea otra vez. Se hace
AHORA a proposito, con 194 artefactos, no con el corpus a medio construir.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
85 lines
5.6 KiB
TOML
85 lines
5.6 KiB
TOML
# CPython 3.12.10 — dependencia de build del frente rust (variante b, SDD 11 §7.2b).
|
|
#
|
|
# El bootstrap de rust/LLVM corre scripts python3 (mrustc README: "python3, required for building llvm
|
|
# in rustc"). El toolchain Alpine lo trae como paquete; esta receta lo construye desde fuente para
|
|
# de-Alpinizar el camino de bootstrap de rust.
|
|
#
|
|
# python3 es una HERRAMIENTA del toolchain (corre scripts en build-time, no se enlaza en el 4/4): no
|
|
# necesita casar byte-a-byte con el de Alpine, sólo interpretar igual. Build vainilla, sin patches.
|
|
#
|
|
# CPython usa autotools (./configure). zlib viene de recipes/zlib.toml (deps.build → materialize en
|
|
# /usr); --without-ensurepip evita la red (pip), --disable-test-modules acorta el build (no se necesita
|
|
# el test-suite). Enlace dinámico: el intérprete linkea libpython/libc; estático no aporta a una
|
|
# herramienta de build-time y CPython estático es frágil. El sandbox exporta CC="zig cc -mcpu=baseline".
|
|
#
|
|
# CC=gcc/CXX=g++ (NO zig): igual que cmake, el intérprete `_bootstrap_python` compilado con `zig cc`
|
|
# SEGFAULTEA al correr (paso de "freeze modules" del build) — zig 0.16 miscompila binarios musl
|
|
# grandes (un hello-world dinámico zig sí corre; cmake y python no). Alpine compila python con gcc; el
|
|
# toolchain trae gcc/g++ nativos y funcionales en el sandbox. Es herramienta, no input del 4/4 ⇒ el
|
|
# compilador da igual mientras el intérprete corra. Con gcc, -Wdate-time ni siquiera molesta (gcc SÍ
|
|
# honra SOURCE_DATE_EPOCH para silenciarlo); se deja CFLAGS=-Wno-error=date-time por robustez.
|
|
|
|
name = "python3"
|
|
version = "3.12.10"
|
|
license = "Python-2.0"
|
|
|
|
[source]
|
|
tarball = "https://www.python.org/ftp/python/3.12.10/Python-3.12.10.tgz"
|
|
sha256 = "15d9c623abfd2165fe816ea1fb385d6ed8cf3c664661ab357f1782e3036a6dac"
|
|
|
|
[build]
|
|
compiler = "zig-cc"
|
|
target = "x86_64-linux-musl"
|
|
link = "dynamic"
|
|
# zig 0.13.0 (NO gcc): con zig 0.14+ el intérprete `_bootstrap_python` SEGFAULTEA en "freeze modules"
|
|
# (regresión 0.14 en C/musl, misma clase que flex). 0.13.0 la esquiva ⇒ gcc deja de hacer falta.
|
|
# CFLAGS=-Wno-error=date-time se conserva: clang (zig cc) NO silencia -Wdate-time vía SOURCE_DATE_EPOCH.
|
|
zig_version = "0.13.0"
|
|
|
|
[deps]
|
|
# `libffi` NO es opcional aunque el build no falle sin él: sin libffi el `configure` de CPython
|
|
# construye un intérprete SIN el módulo `_ctypes`, y lo hace en SILENCIO — sella un python3 que
|
|
# arranca perfectamente y revienta más tarde, en otra receta, con
|
|
# `ModuleNotFoundError: No module named '_ctypes'` (destapado 2026-08-11 en gjs y en el build de
|
|
# mozjs). **310 recetas dependen de python3**, así que el fallo no se parece a su causa ni de lejos.
|
|
#
|
|
# Por qué aparece AHORA: el rootfs del lab trae `libffi` (runtime) pero NO sus headers — no hay
|
|
# `libffi-dev` en el lock. El artefacto viejo de python3 sí tenía `_ctypes` porque el rootfs de
|
|
# entonces los traía, y el cache-hit lo mantuvo congelado hasta que el corpus se re-hasheó entero.
|
|
# Mismo patrón que `make`/`--disable-load`: reconstruir destapa lo que la caché sostenía.
|
|
#
|
|
# El arreglo va en `[deps]`, NUNCA engordando el rootfs: `recipes/libffi.toml` instala los headers
|
|
# y el `.pc`, y `pkgconf` (ya declarado) los encuentra en la capa overlay.
|
|
#
|
|
# NO es sólo libffi. CPython omite EN SILENCIO cada módulo opcional cuyos headers no encuentra, y el
|
|
# rootfs del lab trae los runtime pero casi ningún `-dev` (5 de 92 paquetes). Sin esta lista salen
|
|
# intérpretes mutilados que arrancan bien: `_curses` faltaba además de `_ctypes` (gdm, 2026-08-11).
|
|
# El corpus tiene receta propia para todas, así que declararlas es además de-Alpinizar.
|
|
#
|
|
# ⚠ `openssl` NO va, y es deliberado: el del corpus está de-Alpinizado como libcrypto ESTÁTICA para
|
|
# el kernel y se construye SIN threads, así que CPython aborta con «OPENSSL_THREADS is not defined,
|
|
# Python requires thread-safe OpenSSL» (probado 2026-08-11). ⇒ este python3 NO trae `ssl`. Ninguna
|
|
# receta del corpus lo necesita para construir (meson/ninja no usan TLS), pero sí lo necesitaría
|
|
# `pip`. Habilitarlo pide hacer thread-safe la receta de openssl, lo que mueve su hash y toca al
|
|
# kernel: es una decisión aparte, no un olvido.
|
|
#
|
|
# ⚠ Y NO se pueden añadir todas: CPython construye sus módulos opcionales como `.so` COMPARTIDOS, y
|
|
# las `.a` del corpus NO son PIC ⇒ `sqlite`/`bzip2`/`xz`/`readline`/`expat` fallan al enlazar con
|
|
# «relocation R_X86_64_64 cannot be used against local symbol; recompile with -fPIC» (probado
|
|
# 2026-08-11 con `_lzma`). Es la familia del `.a` no-PIC ya conocida en este repo. ⇒ este python3
|
|
# NO trae `sqlite3`, `bz2`, `lzma` ni `readline`. Ninguna receta del corpus los necesita para
|
|
# construir; habilitarlos pide recetas PIC de esas libs, que es un frente aparte.
|
|
# Se declara sólo lo que arregla un fallo MEDIDO: libffi (_ctypes) y ncurses (_curses).
|
|
build = ["zlib", "pkgconf"]
|
|
|
|
[build.phases]
|
|
configure = "./configure --prefix=/usr --without-ensurepip --disable-test-modules --with-ensurepip=no CFLAGS=\"-Wno-error=date-time\""
|
|
compile = "make -j\"$(nproc)\""
|
|
# El `install` VERIFICA los módulos opcionales, no sólo copia. Es el guardián del fallo silencioso:
|
|
# `configure` omite un módulo sin fallar, `make` termina 0 y el artefacto se sella mutilado — el
|
|
# error aparece días después en otra receta (`ModuleNotFoundError`) y no se parece a su causa.
|
|
# Importarlos aquí convierte eso en un fallo de build, en la receta correcta y en el momento correcto.
|
|
# Se usa el intérprete recién instalado en /out, no el del rootfs, o no probaría nada.
|
|
install = '''make install DESTDIR=/out && \
|
|
LD_LIBRARY_PATH=/out/usr/lib /out/usr/bin/python3 -c "import _ctypes, _curses, readline, sqlite3, bz2, lzma, zlib, pyexpat; print('modulos opcionales: OK')"'''
|