sergioandClaude Opus 4.8
7bf49fb960
Mata gcc para 5 de las 7 recetas que lo forzaban, vía una escotilla nueva: - hammer-core/hammer-build: campo `[build].zig_version` por receta. Cuando se fija, el lab resuelve ese zig (hermano del por defecto, `zig-x86_64-linux-<v>`) en vez del global, y entra al hash SÓLO si está presente (baseline 9adefb82 intacto). `effective_zig_dir` lo aplica en ensure_layout + Sandbox. - Causa: BISECT con oráculo flex (reproducido sólo vía lab: musl DINÁMICO) — el miscompile es una REGRESIÓN de zig 0.14; 0.13.0 compila limpio, 0.14/0.15/0.16 fallan. Es C/musl-dinámico, NO afecta C++. - Flip a zig_version="0.13.0" (quitando CC=gcc): flex, openssl, elfutils, binutils, python3. Verificados: `as` 2.45.1 corre, python3 3.12.10 corre (deepfreeze OK), libcrypto/libelf sellan. Todas son tools (no inputs del 4/4). cmake queda en gcc: su segfault es C++ (libc++/musl), bug distinto que 0.13 NO arregla (ni con -static). El kernel queda pendiente de verificar. Tests: hammer-core/hammer-build verdes. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
45 lines
2.4 KiB
TOML
45 lines
2.4 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"
|
|
|
|
[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]
|
|
build = ["zlib"]
|
|
|
|
[build.phases]
|
|
configure = "./configure --prefix=/usr --without-ensurepip --disable-test-modules --with-ensurepip=no CFLAGS=\"-Wno-error=date-time\""
|
|
compile = "make -j\"$(nproc)\""
|
|
install = "make install DESTDIR=/out"
|