sergio/takana

El build muere a los 6 minutos enlazando libstd.so: `ld.lld: error: unable to find library -lgcc`.
Es la otra cara de lo que la receta ya documentaba para `rpath = false`: al poner ld.lld como
enlazador del triple, se invoca DIRECTO, y el `-L` del directorio privado de gcc lo agrega gcc, no
ld. 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 /usr/lib/gcc/<triple>/<version>/.

Se enlaza a /usr/lib, que el propio renglón de enlace que falla ya busca. La ruta sale de
`gcc -print-libgcc-file-name` y no escrita a mano a propósito: la versión es del LAB, que no entra en
hash_inputs, así que una ruta literal se rompería en silencio el día que el lab mueva de gcc.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

diff --git a/recipes/rust.toml b/recipes/rust.toml
index f1e6de09..9503818c 100644
--- a/recipes/rust.toml
+++ b/recipes/rust.toml
@@ -148,6 +148,26 @@ cp bootstrap.toml config.toml
 # tiene que fallar acá y no tres horas después.
 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