From 58930769d90e63a87f7f4f911b006dca36932f00 Mon Sep 17 00:00:00 2001 From: Sergio Date: Thu, 17 Sep 2026 22:14:08 +0000 Subject: [PATCH] rust: el arreglo de libgcc iba en la fase que enlaza, no en configure MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit El primer intento dejó el enlace en `configure` y lo comprobó ahí mismo: la comprobación dio ✓ y el build murió igual, con el log mostrándolo con claridad cruel —«rust: libgcc.a enlazada desde /usr/lib/gcc/…» y, tres pantallas después, «ld.lld: error: unable to find library -lgcc»—. La causa es que LAS FASES NO COMPARTEN SISTEMA DE FICHEROS: cada una es un bwrap nuevo con `--tmp-overlay /`, que es una capa tmpfs DESCARTABLE (lo dice el propio comentario de sandbox.rs). El enlace se evaporó entre configure y compile. Un guardián que comprueba en la misma fase en la que escribe confirma algo que ya no será cierto cuando importe: lo que cambia el entorno de una fase se hace EN esa fase. Ahora va al principio de `compile` y de `install`, que son las que enlazan. Co-Authored-By: Claude Opus 5 (1M context) --- recipes/rust.toml | 49 +++++++++++++++++++++++++++-------------------- 1 file changed, 28 insertions(+), 21 deletions(-) diff --git a/recipes/rust.toml b/recipes/rust.toml index 9503818c..12a0e7dd 100644 --- a/recipes/rust.toml +++ b/recipes/rust.toml @@ -149,25 +149,6 @@ cp bootstrap.toml config.toml rustc --version | grep -q '1[.]97[.]0' || { echo "stage0 NO es 1.97.0: $(rustc --version)" >&2; exit 1; } llvm-config --version -# ⚠ `-lgcc` NO SE ENCUENTRA, y es la otra cara de invocar `ld.lld` directo (ver `rpath = false` -# arriba). Medido en el worker el 2026-09-17: el build muere a los 6 minutos enlazando `libstd.so` -# -# ld.lld: error: unable to find library -lgcc -# error: could not compile `std` (lib) -# -# `libgcc_s.so` sí está en /usr/lib —por eso `-lgcc_s` pasa y sólo falla el estático—, pero -# `libgcc.a` vive en el directorio privado de gcc (`/usr/lib/gcc///`), que un -# enlazador SIN driver de C no tiene por qué conocer: ese `-L` lo agrega `gcc`, no `ld`. Y el propio -# renglón de enlace que falla ya trae `-L /usr/lib`, así que basta con que la biblioteca esté ahí. -# -# El enlace se hace con `gcc -print-libgcc-file-name` y no con la ruta escrita a mano **a propósito**: -# la versión (hoy 15.2.0) es del LAB, que NO entra en `hash_inputs` — una ruta literal se rompería -# en silencio el día que el lab mueva de gcc. Es dentro del sandbox: no toca el artefacto. -LIBGCC=$(gcc -print-libgcc-file-name) -[ -f "$LIBGCC" ] || { echo "rust: gcc no sabe dónde está su libgcc.a ($LIBGCC) — sin ella el enlace de std muere con 'unable to find library -lgcc'" >&2; exit 1; } -ln -sf "$LIBGCC" /usr/lib/libgcc.a -[ -e /usr/lib/libgcc.a ] || { echo "rust: no pude dejar libgcc.a en /usr/lib" >&2; exit 1; } -echo "rust: libgcc.a enlazada desde $LIBGCC" ''' # `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 @@ -184,5 +165,31 @@ echo "rust: libgcc.a enlazada desde $LIBGCC" # # `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" +# ⚠⚠ DOS COSAS QUE COSTARON UN INTENTO CADA UNA (worker, 2026-09-17). +# +# 1. **`-lgcc` no se encuentra.** Es la otra cara de invocar `ld.lld` DIRECTO (ver `rpath = false` +# arriba): el build muere a los 6 minutos enlazando `libstd.so` con +# +# ld.lld: error: unable to find library -lgcc +# error: could not compile `std` (lib) +# +# `libgcc_s.so` sí está en /usr/lib —por eso `-lgcc_s` pasa y sólo falla el estático—, pero +# `libgcc.a` vive en el directorio privado de gcc, que un enlazador SIN driver de C no tiene por +# qué conocer: ese `-L` lo agrega `gcc`, no `ld`. El renglón que falla ya busca en `/usr/lib`, +# así que basta con dejarla ahí. La ruta sale de `gcc -print-libgcc-file-name` y NO escrita a +# mano: la versión (hoy 15.2.0) es del LAB, que no entra en `hash_inputs`, y una ruta literal se +# rompería en silencio el día que el lab cambie de gcc. +# +# 2. **Y va acá, no en `configure`, porque LAS FASES NO COMPARTEN SISTEMA DE FICHEROS.** Cada fase +# es un `bwrap` nuevo con `--tmp-overlay /`: una capa tmpfs DESCARTABLE. El primer arreglo hizo +# el enlace en `configure` y lo comprobó ahí mismo — la comprobación dio ✓ y el enlace se +# evaporó antes de `compile`. El log lo mostraba con una claridad cruel: +# +# rust: libgcc.a enlazada desde /usr/lib/gcc/x86_64-alpine-linux-musl/15.2.0/libgcc.a +# … +# ld.lld: error: unable to find library -lgcc +# +# Un guardián que comprueba en la misma fase en la que escribe confirma algo que ya no será +# cierto cuando importe. Lo que cambia el entorno de una fase se hace EN esa fase. +compile = "LIBGCC=$(gcc -print-libgcc-file-name) && ln -sf \"$LIBGCC\" /usr/lib/libgcc.a && export CC=gcc CXX=g++ AR=ar RANLIB=ranlib OPENSSL_STATIC=1 OPENSSL_DIR=/usr && python3 x.py build --stage 2" +install = "LIBGCC=$(gcc -print-libgcc-file-name) && ln -sf \"$LIBGCC\" /usr/lib/libgcc.a && export CC=gcc CXX=g++ AR=ar RANLIB=ranlib OPENSSL_STATIC=1 OPENSSL_DIR=/usr && DESTDIR=/out python3 x.py install --stage 2"