From 0a2f8916e64c7d4459436545b6eb5db7e475c752 Mon Sep 17 00:00:00 2001 From: Sergio Date: Thu, 27 Aug 2026 15:26:38 +0000 Subject: [PATCH] =?UTF-8?q?python3:=20TRAE=20`ssl`=20=E2=80=94=20la=20caus?= =?UTF-8?q?a=20era=20`link=3Dstatic`,=20no=20openssl?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit CPython abortaba `_ssl` con «OPENSSL_THREADS is not defined, Python requires thread-safe OpenSSL», y la receta lo daba por imposible sin rehacer openssl. CAUSA RAÍZ, probada: no es openssl, es `link = "static"`. `hammer-build/src/lib.rs:285` inyecta `LDFLAGS=-static`, y el Configure de openssl (línea 1514) hace: if (grep { $_ =~ /(?:^|\s)-static(?:\s|$)/ } @{$config{LDFLAGS}}) { disable('static', 'pic', 'threads'); } ⇒ el propio `-static` apaga los threads en silencio. Añadir `threads` explícito NO sirve (el disable() va después y gana): el configuration.h salía byte a byte idéntico. Dentro del sandbox `configdata.pm` decía `thread_scheme => pthreads` pero `THREADS_DEFINE=0`; fuera del sandbox, los mismos flags —y hasta con el perl del corpus— SÍ definían el macro. La diferencia era el entorno. `openssl-threads`: misma receta con `link = "dynamic"` (mantiene `no-shared`, sigue emitiendo .a). Verificado: OPENSSL_THREADS definido y 36 símbolos pthread_ reales en libcrypto.a. VARIANTE y no tocar `recipes/openssl.toml`: de la canónica cuelgan los CUATRO kernels (linux, linux-generic, linux-metal, linux-metal-dual) y la reproducción bit a bit del 6.16.12 es un resultado cerrado; moverle el hash lo invalidaría, más 125 sellados. Además `ssl` entra en la asserción del install. Sin ese guardián se volvería a sellar un intérprete mudo — que es justo como esto estuvo escondido meses. Verificado: `checking for stdlib extension module _ssl... yes`, _ssl.cpython-312-x86_64-linux-musl.so instalada, y el propio install imprime `modulos opcionales: OK` importando ssl. ⚠ Mueve el hash de python3: 251 dependientes directos, ~369 sellados en los cinco grafos (161 en KDE). Es el coste aceptado de la decisión. --- recipes/openssl-threads.toml | 62 ++++++++++++++++++++++++++++++++++++ recipes/python3.toml | 25 ++++++++++----- 2 files changed, 79 insertions(+), 8 deletions(-) create mode 100644 recipes/openssl-threads.toml diff --git a/recipes/openssl-threads.toml b/recipes/openssl-threads.toml new file mode 100644 index 00000000..c26ff5b8 --- /dev/null +++ b/recipes/openssl-threads.toml @@ -0,0 +1,62 @@ +# OpenSSL 3.5.4 con THREADS — variante para `python3` (_ssl). NO sustituye a `recipes/openssl.toml`. +# +# ── POR QUÉ UNA VARIANTE Y NO TOCAR LA CANÓNICA ───────────────────────────────────────────────── +# La canónica existe para de-Alpinizar el host-tool `certs/extract-cert` del kernel, y **los CUATRO +# kernels dependen de ella** (`linux`, `linux-generic`, `linux-metal`, `linux-metal-dual`). Moverle +# el hash invalidaría los 125 sellados que cuelgan de openssl e incluiría la reproducción bit a bit +# del kernel 6.16.12, que es un resultado CERRADO. Esta variante deja esa cadena intacta: sólo la +# usa `python3`. Mismo patrón que las sombras `libpng-pic` / `glib-shared`. +# +# ── QUÉ CAMBIA: `link = "dynamic"` (NO es un flag de openssl) ─────────────────────────────────── +# El `configure` de CPython comprueba `#if !defined(OPENSSL_THREADS) || defined(OPENSSL_NO_THREADS)` +# y aborta con «OPENSSL_THREADS is not defined, Python requires thread-safe OpenSSL». +# +# LA CAUSA NO ES OPENSSL, ES `link = "static"` DE LA RECETA. `hammer-build/src/lib.rs:285` mete +# `LDFLAGS=-static` cuando el link es estático, y el `Configure` de openssl (línea 1514) hace: +# +# if (grep { $_ =~ /(?:^|\s)-static(?:\s|$)/ } @{$config{LDFLAGS}}) { +# disable('static', 'pic', 'threads'); +# } +# +# ⇒ **el propio `-static` apaga los threads**, en silencio y pase lo que pase en la línea de +# `Configure`. Probado: añadir `threads` explícito NO sirve de nada (el `disable()` va después y +# gana); el `configuration.h` salía byte a byte idéntico al de la canónica. Con `link = "dynamic"` +# desaparece el `-static` de LDFLAGS y `OPENSSL_THREADS` vuelve a definirse. +# +# `no-shared` SE MANTIENE: seguimos produciendo `libcrypto.a`/`libssl.a`. `link` es de hammer (qué +# LDFLAGS inyecta), `no-shared` es de openssl (qué artefactos emite). Son perillas distintas y acá +# hacen falta las dos. +# +# Cómo se cazó: `thread_scheme => "pthreads"` en el `configdata.pm` DENTRO del sandbox (o sea, el +# target estaba bien) pero `THREADS_DEFINE=0`; y el mismo `Configure`, con los mismos flags y hasta +# con el perl del corpus, SÍ definía el macro fuera del sandbox. La diferencia era el entorno, no la +# receta de openssl. +# +# ⚠ PIC no es el problema y conviene decirlo: `libcrypto.a` de la canónica YA es PIC. `readelf -r` +# cuenta 256175 `R_X86_64_32`, pero **excluyendo las secciones `.rela.debug_*` son 0** — es la +# trampa de medición ya documentada en el repo. Así que la variante NO añade `-fPIC`. + +name = "openssl-threads" +version = "3.5.4" +license = "Apache-2.0" + +[source] +tarball = "https://github.com/openssl/openssl/releases/download/openssl-3.5.4/openssl-3.5.4.tar.gz" +sha256 = "967311f84955316969bdb1d8d4b983718ef42338639c621ec4c34fddef355e99" + +[build] +compiler = "zig-cc" +target = "x86_64-linux-musl" +link = "dynamic" +# zig 0.13.0 en vez del 0.16: el gcc era precautorio por el riesgo de miscompilación de zig 0.16 en +# binarios grandes (regresión 0.14). 0.13.0 lo esquiva (mismo bisect que flex). openssl es C+asm GAS, +# que el assembler integrado de zig cc (clang) maneja. Con el zig bueno por-receta gcc no hace falta. +zig_version = "0.13.0" + +[deps] +build = ["perl"] + +[build.phases] +configure = "./Configure linux-x86_64 --prefix=/usr --libdir=lib no-shared no-docs no-tests no-apps" +compile = "make -j\"$(nproc)\" build_libs" +install = "make DESTDIR=/out install_dev" diff --git a/recipes/python3.toml b/recipes/python3.toml index 54b4b93b..a90cd041 100644 --- a/recipes/python3.toml +++ b/recipes/python3.toml @@ -56,12 +56,21 @@ zig_version = "0.13.0" # 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. +# ✅ `openssl-threads` SÍ va (2026-08-27) — y con él este python3 TRAE `ssl`. +# +# Antes decía acá que era imposible sin tocar la receta de openssl. Lo que faltaba era la causa real: +# **el `no-threads` no venía de openssl, venía de `link = "static"`**. `hammer-build/src/lib.rs:285` +# inyecta `LDFLAGS=-static`, y el `Configure` de openssl (línea 1514) hace +# `disable('static','pic','threads')` en cuanto ve `-static` en LDFLAGS. Por eso el `OPENSSL_THREADS` +# no aparecía y CPython abortaba con «Python requires thread-safe OpenSSL». +# +# `recipes/openssl-threads.toml` es la MISMA receta con `link = "dynamic"` (sigue con `no-shared`, +# o sea sigue emitiendo `.a`). Se usa una VARIANTE y no se toca `recipes/openssl.toml` porque de la +# canónica cuelgan los CUATRO kernels (linux, linux-generic, linux-metal, linux-metal-dual) y su +# reproducción bit a bit es un resultado cerrado: moverle el hash la invalidaría. +# +# ⚠ `ssl` entra además en la asserción del install de abajo. Sin eso, el día que vuelva a romperse +# se sellaría un python3 mudo otra vez — que es exactamente cómo esto estuvo escondido meses. # # ⚠ 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 @@ -70,7 +79,7 @@ zig_version = "0.13.0" # 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 = ["zlib", "pkgconf", "openssl-threads"] [build.phases] configure = "./configure --prefix=/usr --without-ensurepip --disable-test-modules --with-ensurepip=no CFLAGS=\"-Wno-error=date-time\"" @@ -81,4 +90,4 @@ compile = "make -j\"$(nproc)\"" # 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')"''' +LD_LIBRARY_PATH=/out/usr/lib /out/usr/bin/python3 -c "import ssl, _ctypes, _curses, readline, sqlite3, bz2, lzma, zlib, pyexpat; print('modulos opcionales: OK')"'''