SDD 31: EL ESCALÓN 2 SELLÓ — rust 1.97.0 desde fuente, b3:015a07fb…

353 M, construido por la granja desde `llvm21` del corpus y el stage0 del lab. Los controles, en la
caja (que sí tiene cargador musl; el worker no):

    rustc --version            → 1.97.0 … (built from a source tarball)   ← NUESTRO
    rustc --print target-list  → x86_64-alpine-linux-musl                 ← EL PARCHE, DENTRO
    cargo --version            → 1.97.0 … (built from a source tarball)

Y compila: `--emit=obj` da un objeto de 3,5 K y `--crate-type=rlib` una biblioteca, sin enlazador.

🧱 MURO 8, YA MEDIDO: el compilador no trae con qué ENLAZAR. En una caja sin `cc` —cualquier takana
que no sea un hub— `-C linker-flavor=ld.lld` da «linker `lld` not found» y el `ld` de binutils muere
con «cannot find -lgcc». La causa estaba en una línea del log que parece informativa:

    skipping llvm-tools (x86_64-alpine-linux-musl): external LLVM

Al usar LLVM externo —que es lo que queremos— x.py se salta las herramientas de LLVM, y `rust-lld`
es una de ellas. El prebuilt oficial sí la trae, y por eso el escalón 1 enlazaba. Y `llvm21` no
sirve de repuesto: NO publica ningún `lld` (medido sobre sus 1,6 G).

Dos salidas: (a) `[rust] lld = true`, que construye rust-lld desde el llvm-project vendoreado y deja
el toolchain autosuficiente; (b) publicar `lld` desde llvm21 y fijar el linker en un
`/etc/cargo/config.toml` del sitio.

Y la lección de método: el artefacto SELLÓ, reproduce y NO ENLAZA. Es [[subcomando-sin-driver]] en
el corazón del toolchain. Un `build ok` no es la prueba: la prueba es el objeto en el disco.

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

docs/31-compilador-de-rust.md

@@ -103,6 +103,62 @@ Las salidas, por orden de honestidad:
 
 ⇒ La 1 es la que Alpine ya demostró que funciona, y es la que sigue.
 
+## 4.ter ✅ EL ESCALÓN 2 SELLÓ *(2026-09-16 00:18)*
+
+**`rust` 1.97.0 desde fuente: `b3:015a07fb…`, 353 M.** Construido por la granja, en el worker, desde
+`llvm21` del corpus y el stage0 del lab.
+
+Los controles, corridos en la caja (que sí tiene el cargador musl; el worker no):
+
+    $ rustc --version
+    rustc 1.97.0 (2d8144b78 2026-07-07) (built from a source tarball)     ← NUESTRO
+    $ rustc --print target-list | grep alpine
+    x86_64-alpine-linux-musl                                              ← EL PARCHE, DENTRO
+    $ cargo --version
+    cargo 1.97.0 (c980f4866 2026-06-30) (built from a source tarball)
+
+Y compila: `--emit=obj` da un objeto de 3,5 K y `--crate-type=rlib` una biblioteca de 6,4 K, las dos
+sin tocar el enlazador.
+
+### Los dos muros de esta tanda
+
+6. **El triple de Alpine no existía en el producto.** Resuelto con `rust-alpine-target.patch`, que lo
+   registra en `rustc_target` — un spec copiado del canónico con `crt_static_default = false` (sin
+   eso no hay dylibs y sin dylibs no hay proc-macros) y una línea en `supported_targets!`. Es lo que
+   hace Alpine. **El control no es que el build pase: es que `--print target-list` lo liste.**
+7. **`openssl-sys`, a la hora y media de build.** `tools = ["cargo"]` lo arrastra. La dep que entró es
+   **`openssl-threads` y no la canónica**: el `Configure` de openssl apaga los threads en cuanto ve
+   `-static` en LDFLAGS, y cargo es masivamente multihilo. Más `OPENSSL_STATIC=1`/`OPENSSL_DIR=/usr`,
+   porque el lab publica `.a` y ningún `.so`.
+
+### 🧱 Muro 8, ya medido: el compilador no trae con qué ENLAZAR
+
+En una caja sin `cc` —o sea, en cualquier takana que no sea un hub— el enlace falla:
+
+    $ rustc hola.rs -C linker-flavor=ld.lld
+    error: linker `lld` not found
+    $ rustc hola.rs -C linker=/usr/bin/ld -C link-self-contained=yes
+    /usr/bin/ld: cannot find -lgcc
+
+La causa está en el log del propio build, en una línea que parece informativa:
+
+    skipping llvm-tools (x86_64-alpine-linux-musl): external LLVM
+
+Al usar un LLVM externo —que es lo que queremos, porque `llvm21` es del corpus— **x.py se salta las
+herramientas de LLVM, y `rust-lld` es una de ellas**. El prebuilt oficial sí lo trae, y por eso el
+escalón 1 enlazaba y éste no. Y `llvm21` tampoco sirve de repuesto: **no publica ningún `lld`**
+(medido: 1,6 G de artefacto, cero binarios `lld`).
+
+⇒ Las salidas son dos, y hay que elegir: **(a)** `[rust] lld = true` en el `bootstrap.toml`, que
+construye `rust-lld` desde el `llvm-project` vendoreado en el tarball —el toolchain queda completo y
+autosuficiente—; o **(b)** publicar `lld` desde `llvm21` y fijar el linker en un
+`/etc/cargo/config.toml` del sitio. La (a) es la que hace que «tener compilador de Rust» signifique
+lo que parece.
+
+⚠ Y lo que esto enseña del método: **el artefacto selló, reproduce y no enlaza**. Es la familia de
+[[subcomando-sin-driver]] en el corazón del toolchain — un compilador que compila y no produce un
+ejecutable. Un `build ok` no es la prueba; la prueba es el objeto en el disco y el binario corriendo.
+
 ## 5. Lo que falta decidir
 
 - **Dónde vive el toolchain.** Hoy `rust-toolchain-bin` está en `perfil.servidor` (799 M; un