sergio/takana

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) <noreply@anthropic.com>

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/<triple>/<version>/`), 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"