From a0b3e27effd8a1847d03bfde5d6491415952294b Mon Sep 17 00:00:00 2001 From: Sergio Date: Tue, 15 Sep 2026 21:43:12 +0000 Subject: [PATCH] =?UTF-8?q?SDD=2031=20=C2=A74.bis:=20el=20sexto=20muro=20d?= =?UTF-8?q?e=20rust,=20que=20la=20granja=20encontr=C3=B3=20sola?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `rust` en la cola del worker llegó MUCHO más lejos: compiló las 386 crates del stage1 y murió al empezar `Building stage1 library artifacts (stage1 -> stage1)`: error: error loading target specification: could not find specification for target "x86_64-alpine-linux-musl" Es la OTRA MITAD del muro 4 y sólo se ve en el stage 2: usar el triple de Alpine funciona mientras el compilador que manda es el del LAB —Alpine le PARCHEA esa especificación a su rustc— y deja de funcionar en cuanto toma el relevo el rustc recién construido, que es upstream puro y no la conoce. El triple que hace falta para ARRANCAR el build es el que el PRODUCTO del build no tiene. Tres salidas, con la elegida: parchear `rustc_target` para registrar el triple (lo que hace Alpine; queda DENTRO del compilador y vale en todos los stages). El `RUST_TARGET_PATH` + JSON es más barato pero un target por JSON como HOST es terreno que rustc no soporta bien. Y volver al canónico no tiene candidato a stage0: el prebuilt oficial trae esa std pero no puede compilar proc-macros. Co-Authored-By: Claude Opus 5 (1M context) --- docs/31-compilador-de-rust.md | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/docs/31-compilador-de-rust.md b/docs/31-compilador-de-rust.md index f66e68b6..9a33a110 100644 --- a/docs/31-compilador-de-rust.md +++ b/docs/31-compilador-de-rust.md @@ -73,6 +73,36 @@ el binario corre. Una distro sin compilador de C puede compilar Rust igual. cmake, y con el wrapper de zig la prueba de ABI falla. `CC=gcc CXX=g++`, igual que en `llvm21` y `cmake`. +## 4.bis El SEXTO muro, que la granja encontró sola *(2026-09-15)* + +`rust` entró a la cola del worker y llegó **mucho más lejos**: compiló las **386 crates del stage1** y +murió justo al empezar `Building stage1 library artifacts (stage1 -> stage1)`: + + error: error loading target specification: could not find specification for target + "x86_64-alpine-linux-musl" + = help: did you mean `x86_64-unknown-linux-musl`? + +**Es la otra mitad del muro 4, y sólo se ve en el stage 2.** Usar el triple de Alpine funciona +mientras el compilador que manda es el del LAB —Alpine le PARCHEA esa especificación a su rustc— y +deja de funcionar en el instante en que toma el relevo **el rustc que acabamos de construir**, que es +upstream puro y no la conoce. O sea: el triple que hace falta para arrancar el build es el que el +producto del build no tiene. + +Las salidas, por orden de honestidad: + +1. **Parchear `rustc_target` para registrar `x86_64-alpine-linux-musl`**, que es literalmente lo que + hace Alpine en su APKBUILD. Un fichero de spec copiado de `x86_64_unknown_linux_musl.rs` y una + línea en `supported_targets!`. El triple queda DENTRO del compilador, así que vale en todos los + stages. +2. `RUST_TARGET_PATH` + un `.json` generado por el propio stage0 + (`--print target-spec-json`) — más barato, pero un target por JSON como **host** es terreno que + rustc no soporta bien: la std del host se construye con el spec built-in. +3. Volver al triple canónico y resolver el «can't find crate for std» del stage0 por otro lado. Hoy + no hay candidato: el prebuilt oficial trae esa std pero **no puede compilar proc-macros** (muro 2), + así que no sirve de stage0 para el bootstrap. + +⇒ La 1 es la que Alpine ya demostró que funciona, y es la que sigue. + ## 5. Lo que falta decidir - **Dónde vive el toolchain.** Hoy `rust-toolchain-bin` está en `perfil.servidor` (799 M; un