sergio/takana
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

rust: el séptimo muro es el openssl de cargo — y va la variante CON THREADS

Browse Source 
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) <noreply@anthropic.com>
This commit is contained in:
Sergio
2026-09-15 23:59:22 +00:00
co-authored by Claude Opus 5
parent c8aa1ddd08
commit ac856501b2
1 changed files with 15 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
recipes/rust.toml
+15 -3
View File
@@ -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"