From ac856501b22f2992ab87caf3a5bbfbc0c99aa124 Mon Sep 17 00:00:00 2001 From: Sergio Date: Tue, 15 Sep 2026 23:59:22 +0000 Subject: [PATCH] =?UTF-8?q?rust:=20el=20s=C3=A9ptimo=20muro=20es=20el=20op?= =?UTF-8?q?enssl=20de=20cargo=20=E2=80=94=20y=20va=20la=20variante=20CON?= =?UTF-8?q?=20THREADS?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit El parche del triple FUNCIONÓ: el build pasó el stage 2 —donde moría— y llegó hasta las herramientas. Ahí cortó otra cosa: error: failed to run custom build command for `openssl-sys v0.9.114` The system library `openssl` required by crate `openssl-sys` was not found. `tools = ["cargo"]` arrastra `openssl-sys`, y eso pasa DESPUÉS de compilar las ~400 crates del compilador, o sea a la hora y media de build. La dep que entra es `openssl-threads` y NO la canónica, aunque las dos publiquen sólo `.a`: el `Configure` de openssl APAGA LOS THREADS en cuanto ve `-static` en LDFLAGS, y la canónica se construye así. Un cargo —masivamente multihilo— enlazado contra un openssl sin soporte de hilos es la clase de fallo que no se ve al construir ni al arrancar. La variante ya existía por exactamente lo mismo para `python3`, y el worker la tiene sellada con el mismo hash. Van también `OPENSSL_STATIC=1` y `OPENSSL_DIR=/usr`: el lab publica `.a` y ningún `.so`, y sin decírselo `openssl-sys` busca la dinámica y falla con un mensaje que habla de pkg-config. Co-Authored-By: Claude Opus 5 (1M context) --- recipes/rust.toml | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/recipes/rust.toml b/recipes/rust.toml index 970617ff..4b0fc559 100644 --- a/recipes/rust.toml +++ b/recipes/rust.toml @@ -54,7 +54,7 @@ flags = [] # # Y por eso abajo va `crt-static = false` para el host: sin eso, el rustc que salga de acá heredaría # el mismo defecto y no podría compilar ni una receta del corpus que use `derive`. -build = ["llvm21", "cmake", "samurai", "python3", "pkgconf", "curl"] +build = ["llvm21", "cmake", "samurai", "python3", "pkgconf", "curl", "openssl-threads"] [build.phases] # El fichero de configuración de x.py se llama `bootstrap.toml` desde 1.8x; se escribe también @@ -118,5 +118,17 @@ llvm-config --version # `CC`/`CXX` de GCC para los build scripts nativos (jemalloc, compiler-rt): con el wrapper de zig, # cmake declara el compilador «broken» en su prueba de ABI. Mismo motivo por el que `llvm21` y # `cmake` usan g++ en vez de zig. -compile = "export CC=gcc CXX=g++ AR=ar RANLIB=ranlib && python3 x.py build --stage 2" -install = "export CC=gcc CXX=g++ AR=ar RANLIB=ranlib && DESTDIR=/out python3 x.py install --stage 2" +# ── EL OPENSSL DE CARGO, Y POR QUÉ ES LA VARIANTE CON THREADS ────────────────────────────────── +# `tools = ["cargo"]` arrastra `openssl-sys`, que sin openssl en el lab corta con «The system library +# `openssl` required by crate `openssl-sys` was not found» — y eso pasa DESPUÉS de compilar las 400 +# crates del compilador, o sea a la hora y media de build. +# +# La dep es `openssl-threads` y NO la canónica, aunque las dos publiquen sólo `.a`: el `Configure` de +# openssl **apaga los threads en cuanto ve `-static` en LDFLAGS**, y la canónica se construye así. Un +# cargo —que es masivamente multihilo— enlazado contra un openssl sin soporte de hilos es la clase de +# fallo que no se ve al construir ni al arrancar. La variante existe por lo mismo para `python3`. +# +# `OPENSSL_STATIC`/`OPENSSL_DIR`: el lab publica `.a` y ningún `.so`, y sin decírselo `openssl-sys` +# busca la dinámica y falla con un mensaje que habla de pkg-config y no de eso. +compile = "export CC=gcc CXX=g++ AR=ar RANLIB=ranlib OPENSSL_STATIC=1 OPENSSL_DIR=/usr && python3 x.py build --stage 2" +install = "export CC=gcc CXX=g++ AR=ar RANLIB=ranlib OPENSSL_STATIC=1 OPENSSL_DIR=/usr && DESTDIR=/out python3 x.py install --stage 2"