la cadena rehecha: llvm21 arreglado, lld enlaza, rust reconstruido — los seis controles pasan

Un cambio de dos líneas en `llvm21` re-selló tres artefactos y los molió la granja sola, en orden,
por dependencia: llvm21 95956a16→bd4a4094, lld21 27be53c1→95a4794b, rust 015a07fb→702094a8.

    llc --version        Stack dump: + segfault   →   LLVM 21.1.2, Optimized build
    opt --version        ídem                     →   LLVM 21.1.2
    ld.lld               «not built with zlib»    →   ENLAZA
    rustc --version                               →   1.97.0 (built from a source tarball)
    --print target-list                           →   x86_64-alpine-linux-musl
    cargo build + correr                          →   0,16 s y el binario habla

La config del sitio pasa a usar `lld` (más rápido); el `ld` de binutils queda documentado como
alternativa que también funciona.

LA REGLA QUE SE GANÓ SU LUGAR: **`link = "static"` en el encabezado decide cosas que la receta no
dice**. Van tres, todas medidas: apagó los threads de openssl, le mintió a libtool, y acá rompió los
registros estáticos de LLVM (`cl::opt`, `TargetRegistry`) porque el `static-pie` descarta sus
constructores globales. Con C++ grande la postura por defecto pasa a ser `dynamic` y medirlo — y el
control no es que selle: es CORRER UNA HERRAMIENTA del artefacto.

Y el corolario de por qué nadie lo vio en meses: el único consumidor de llvm21 era rust, que usa
`llvm-config` y las `.a`, nunca una herramienta. **Un artefacto puede estar roto en todo lo que nadie
usa** — como los 44 `cargo-*` sin cargo y los 23 binarios sin cargador.

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

docs/31-compilador-de-rust.md

@@ -207,6 +207,44 @@ los registros de LLVM (`cl::opt`, `TargetRegistry`): funciona lo que no los nece
 usable— **re-hashea `llvm21` y con él `rust`**, o sea dos builds largos. Y arreglar las 79
 herramientas es la misma operación. Hoy no bloquea nada: el toolchain enlaza con `ld`.
 
+## 4.quinquies ✅ LA CADENA REHECHA: `llvm21` arreglado, y todo detrás *(2026-09-16)*
+
+Un cambio de dos líneas en `llvm21` re-selló tres artefactos, y los seis controles pasan:
+
+| | antes | ahora |
+|---|---|---|
+| `llc --version` | `Stack dump:` + segfault | **LLVM 21.1.2, Optimized build** |
+| `opt --version` | ídem | **LLVM 21.1.2** |
+| `ld.lld` contra la libc del lab | «not built with zlib support» | **enlaza** |
+| `rustc --version` | — | 1.97.0 *(built from a source tarball)* |
+| `--print target-list \| grep alpine` | — | `x86_64-alpine-linux-musl` |
+| `cargo build` + correr | — | **0,16 s y el binario habla** |
+
+Los hashes: `llvm21` `95956a16…`→`bd4a4094…`, `lld21` `27be53c1…`→`95a4794b…`,
+`rust` `015a07fb…`→`702094a8…`. La granja los molió sola, en orden, por dependencia.
+
+### Lo que se arregló, y por qué estaba roto
+
+1. **`link = "dynamic"`.** Con `static` los binarios salen `static-pie` y el enlace descarta los
+   constructores globales de los que dependen los registros de LLVM (`cl::opt`, `TargetRegistry`).
+   Por eso `llvm-ar` y `llvm-config` funcionaban —no los usan— y `llc`/`opt`/`lld` reventaban.
+2. **`LLVM_ENABLE_ZLIB=ON` + dep `zlib`.** Un `lld` construido contra este LLVM **hereda**
+   `LLVM_ENABLE_ZLIB` de `LLVMConfig.cmake`: encenderlo en la receta de lld era inerte. Sin zlib no
+   puede leer las secciones de depuración comprimidas que trae la libc del lab, o sea que no enlaza
+   nada real.
+
+### La regla que se ganó su lugar
+
+**`link = "static"` en el encabezado decide cosas que la receta no dice.** Van tres, todas medidas:
+apagó los threads de openssl (`Configure` lo hace al ver `-static`), le mintió a libtool
+(`link-static-mentira-libtool`), y acá rompió los registros estáticos de LLVM. Con C++ grande, la
+postura por defecto pasa a ser **`dynamic` y medirlo** — y el control no es que selle: es **correr una
+herramienta del artefacto**.
+
+⚠ Y el corolario de por qué nadie lo vio en meses: **el único consumidor de `llvm21` era `rust`, que
+usa `llvm-config` y las `.a`**. Un artefacto puede estar roto en todo lo que nadie usa. Vale para los
+44 `cargo-*` sin `cargo`, para los 23 binarios sin cargador, y ahora para 79 herramientas de LLVM.
+
 ## 5. Lo que falta decidir
 
 - **Dónde vive el toolchain.** Hoy `rust-toolchain-bin` está en `perfil.servidor` (799 M; un

scripts/servidor/cargo-config.toml

@@ -5,14 +5,15 @@
 # enlazador es el `ld` de binutils y que el modo es estático, que es el natural de musl.
 #
 # Por qué CADA flag, todos medidos el 2026-09-16 contra el rustc que construimos:
-#   · `linker-flavor=ld` + `linker=/usr/bin/ld` — el `ld` del corpus. (`lld` sería más rápido, pero
-#     el nuestro hereda `LLVM_ENABLE_ZLIB=0` de `llvm21` y no puede leer las secciones de depuración
-#     COMPRIMIDAS que trae la libc del lab: «is compressed with ELFCOMPRESS_ZLIB, but lld is not
-#     built with zlib support».)
+#   · `linker-flavor=ld.lld` + `linker=/usr/bin/ld.lld` — el `lld` del corpus (`recipes/lld21.toml`).
+#     Hasta el 2026-09-16 acá decía el `ld` de binutils, porque el `lld` heredaba `LLVM_ENABLE_ZLIB=0`
+#     de `llvm21` y no podía leer las secciones de depuración COMPRIMIDAS de la libc del lab. Con
+#     `llvm21` reconstruido con zlib, lld enlaza y es más rápido. El `ld` de binutils sigue
+#     funcionando como alternativa: `-C linker-flavor=ld -C linker=/usr/bin/ld`.
 #   · `target-feature=+crt-static` — sin esto rustc pide `-lgcc`/`-lgcc_s` para el desenrollado y el
 #     enlace muere en `cannot find -lgcc`: la distro se construye con zig, que trae compiler-rt y no
 #     libgcc. Estático es además el modo natural de musl.
 #   · `link-self-contained=yes` — usa los `crt*.o` y la `libc.a` que el propio toolchain trae.
 [target.x86_64-alpine-linux-musl]
-linker = "/usr/bin/ld"
-rustflags = ["-C", "linker-flavor=ld", "-C", "target-feature=+crt-static", "-C", "link-self-contained=yes"]
+linker = "/usr/bin/ld.lld"
+rustflags = ["-C", "linker-flavor=ld.lld", "-C", "target-feature=+crt-static", "-C", "link-self-contained=yes"]