rustc desde fuente está compilando el stage1 en el worker. El documento recoge el frente entero: el
hueco medido (12 crates y 42 555 líneas de Rust, 44 recetas `cargo-*`, CERO de rustc, y el `rustc`
que construye todo eso saliendo del LAB — que ENTRA en el ArtifactHash), los tres escalones, y lo
que costó cada uno.
Los cinco muros del escalón 2, todos con un mensaje que no nombra la causa:
1. `llvm18` no sirve: `bad LLVM version, need >=21`. Mínimos medidos en el propio bootstrap
(1.87→18 · 1.90→19 · 1.93/1.95→20 · 1.97→21). Bajar de rustc no es salida porque el stage0 de N
es N-1 o N. De ahí `llvm21` — y `llvm18` se queda, que lo usa mesa.
2. **El toolchain musl oficial no puede producir proc-macros** (crt-static=true ⇒ sin dylibs):
muere compilando el propio bootstrap de rustc, que usa `clap` con derive. Sirve para compilar
programas, no para arrancar el build de rustc. El stage0 es el del lab.
3. x.py DESCARGA el stage0 si no le nombras el local: en un sandbox sin red, `RuntimeError: failed
verification` en `download_toolchain()`, que no menciona ni la red ni el stage0.
4. El triple de Alpine no es el canónico: sin fijarlo, la sección `[target.…-unknown-…]` no aplica a
nada y x.py se pone a construir LLVM solo; forzando el canónico, el stage0 no tiene su std.
5. cmake + zig = «compiler broken» en la prueba de ABI. CC=gcc, igual que llvm21 y cmake.
Y del escalón 1, lo que no estaba en el grafo: el prebuilt no ejecuta sin `musl-shared` (cargador) y
sin `gcc-libs` (`libgcc_s.so.1`) — dos paquetes sellados y en el perfil equivocado. Más una
propiedad que vale: no hace falta un `cc`, el toolchain trae su propio lld.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016Tf9T4vGzsMoT7eS8YzMFn
Ordenando el protocolo numerado en los dos sentidos: cosmic-comp manda
configure_bounds(0,0)+configure(0,0) («elegi vos»), el cliente contesta
set_min_size(117,37), set_max_size(348,16332) y set_window_geometry(117,70),
y RECIEN ahi el compositor devuelve configure(117,70) teniendo 1280x692
para dar. No hay nada que arreglar en COSMIC.
El MOZ_LOG dice como: «Initial resize to 1 x 1» — Gecko crea la ventana de
1x1 y nunca la agranda; 117x70 es lo que queda cuando el chrome se mide a
si mismo. El frente se mueve a Gecko.
El configure abortó con «stage0 NO es 1.97.0: rustc 1.97.0» — o sea, la guarda rechazando
exactamente la versión que exige. La causa: en un string multilínea con comillas SIMPLES, TOML no
procesa escapes, así que `grep -q '1\\.97\\.0'` busca una barra invertida literal y nunca casa.
Va `'1[.]97[.]0'`, que no depende de cómo el formato trate las barras.
Un guardián que falla sobre lo que debería aceptar es tan inútil como uno que nunca falla — pero al
menos éste falló RUIDOSAMENTE y en el primer minuto, no tres horas después.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016Tf9T4vGzsMoT7eS8YzMFn
El segundo escalón de los tres: rustc construido acá, con el `llvm21` del corpus y con
`rust-toolchain-bin` (el tarball oficial sellado ayer) como **stage0**. Un prebuilt ajeno sirve
exactamente para esto: ser el escalón que permite dejar de necesitarlo.
Tres cosas que no son detalles y que van escritas en la receta:
· **`local-rebuild = true`**: el bootstrap espera que el stage0 sea el compilador ANTERIOR (o el
beta de esta versión), y acá es 1.97.0 construyendo 1.97.0. Sin esa opción x.py aborta por
«stage0 compiler version mismatch». Es el modo con el que las distros reconstruyen la misma
versión con la misma versión.
· **LLVM externo ≥21**, medido en el propio bootstrap (`bad LLVM version … need >=21`). Por eso
existe `llvm21`: `llvm18` está sellado pero lo usa mesa, que no soporta 21.
· **Sin red**: el tarball `-src` trae `vendor/` con todas las deps de cargo. Es la única forma de
construir dentro del sandbox, que no tiene red después del fetch.
Y una guarda en el `configure`: la versión del stage0 se COMPRUEBA (`rustc --version | grep 1.97.0`)
en vez de asumirse. `local-rebuild` sólo es correcto si el compilador de arranque es exactamente
esta versión; si alguien mueve el pin de `rust-toolchain-bin`, esto tiene que fallar ahí y no tres
horas después.
`llvm21` ya selló: 1,6 G, `llvm-config --version` → 21.1.2.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016Tf9T4vGzsMoT7eS8YzMFn
Las otras tres recetas cgo (sq, usql, gitea) dan DERIVA, no no-determinismo: sus dos
reconstrucciones coinciden entre sí y el artefacto guardado era el de antes del arreglo.
Ya están al día.
Y de paso se les fue una deuda que NO era de reproducibilidad sino de PORTABILIDAD: el
`x_cgo_sigaction` de sq y usql —código C de cgo, sin guarda de CPU en runtime— venía con
AVX2 horneado, de cuando el driver pisaba el `-mcpu=baseline`. Un binario así no falla al
construir ni al sellar: falla al EJECUTAR en una CPU sin AVX2, con SIGILL. Ahora los tres
salen baseline (cero ymm, cero zmm en esa función).
── El límite del libro, anotado en su encabezado ──────────────────────────────────────
`gocryptfs` acabó con CUATRO filas al MISMO hash: dos NO-DETERMINISMO y dos reproduce, y
las cuatro son ciertas. La clave (receta, hash) no puede distinguir antes y después de un
arreglo del FRAMEWORK, porque la fase generada no entra en `hash_inputs` — a propósito,
para no re-sellar 362 recetas cada vez que se toca un driver.
Corolario, que es lo caro: tras tocar un driver, lo sellado NO se rehace solo. Hay que
forzarlo receta por receta, y si nadie lo hace el store se queda con artefactos que ya
nadie construiría así.
`gocryptfs` era el último no-determinismo vigente del corpus. Ya REPRODUCE.
── La medición, que primero hice mal ──────────────────────────────────────────────────
Comparé los dos ficheros de `store/.divergen/` y salían 1.874.136 bytes distintos, con
`.text` entre ellos y funciones de OpenSSL cambiando de AVX2 a AVX-512. Era el par
EQUIVOCADO: `.divergen/<D>` es el artefacto VIEJO archivado, no una reconstrucción. El
par que define el veredicto es `<D>.r1` (1ª reconstrucción) contra el que queda en el
store (2ª).
Comparado bien, el no-determinismo son **7 bytes, todos en `.debug_str`**: los dígitos
de `go-build598798091` contra `go-build270591055`.
(Lo de AVX no era ruido: era DERIVA real contra el artefacto viejo, sellado antes de que
467a87cd pusiera `-mcpu=baseline` en el CC de cgo. Se trata aparte, abajo.)
── La causa ───────────────────────────────────────────────────────────────────────────
`-trimpath` reescribe rutas, pero cuál gana depende de dónde esté el work dir de Go:
dentro del módulo gana la reescritura del módulo y el componente ALEATORIO sobrevive;
fuera, Go reescribe el work dir entero a `/tmp/go-build` y el número desaparece. El
driver ponía `GOTMPDIR=/src/.gotmp`, que es justo dentro del módulo.
Con CGO off da igual —no hay fuentes C generadas, ninguna ruta del work dir entra en el
DWARF— y por eso las 15 recetas Go puras verificadas reproducen. Con cgo sí entra. Por
eso el cambio va acotado a `cgo = true`: las otras 358 no lo necesitan.
── Medido en los dos sentidos, con un módulo cgo de juguete y cachés limpias ─────────
· GOTMPDIR dentro ⇒ `go-build3806217352` en el binario; dos builds DIFIEREN
· GOTMPDIR fuera ⇒ ninguna cadena `go-build`; dos builds IDÉNTICOS
Y sobre gocryptfs de verdad: DERIVA primero (las dos reconstrucciones ya coincidían
entre sí y el guardado era el viejo), REPRODUCE en la pasada siguiente. En el binario
sólo queda `/tmp/go-build`, el marcador constante de trimpath.
── Va a `/cache` y no a `/tmp`, y se COMPRUEBA que exista ─────────────────────────────
El sandbox monta `--tmpfs /tmp` (~½ RAM) y un proyecto Go grande lo desborda: ésa era la
razón de poner esto en `/src`. `/cache` es un bind RW a disco (el de la caché de zig),
así que conserva el disco y queda fuera del módulo.
Y no se da por hecho que esté: con `--tmp-overlay /` la raíz es escribible, así que un
`mkdir -p /cache/gotmp` a ciegas TRIUNFARÍA creando el directorio en la capa tmpfs —en
RAM, el desbordamiento que se quería evitar, y en silencio. Si el bind falta, el build
muere diciéndolo.
El plan era «rustc desde fuente con el llvm18 del corpus». No se puede, y el propio bootstrap de
rustc lo dice en una línea:
panic!("\n\nbad LLVM version: {version}, need >=21\n\n")
Mínimos medidos, versión por versión, leyendo `src/bootstrap/src/core/build_steps/llvm.rs`:
rustc 1.87 → LLVM ≥18 · 1.90 → ≥19 · 1.93/1.95 → ≥20 · 1.97 → ≥21
El lab —y con él todo lo que construimos— está en **rust 1.97.0**. Con `llvm18` sólo se podría
construir `rustc 1.87`, que además no se puede bootstrapear con lo que tenemos (el stage0 de rustc N
es N-1 o N, y nuestro binario es 1.97). La salida no es bajar de rustc: es subir de LLVM.
`llvm18` se queda donde está: lo usa `mesa-llvmpipe`, y mesa 24.0.9 no soporta LLVM 21. Dos
consumidores con rangos incompatibles ⇒ dos artefactos. No es deuda, es la realidad de los rangos.
Dos diferencias de build frente a `llvm18`, las dos a propósito: **sin DYLIB** (rustc quiere las
estáticas y su `llvm-config`; el link del dylib es lo que pide «worker GORDO» según la propia receta
de llvm18 — sin él el pico de RAM entra en los 16 G del worker) y **RTTI ON**, que rustc exige.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016Tf9T4vGzsMoT7eS8YzMFn
`grep NO-DETERMINISMO` daba 3 y sugería tres problemas abiertos. Dos ya no existen:
kirigami y syntax-highlighting se arreglaron el mismo día y sus filas están clavadas
al hash VIEJO, que es justo lo que la clave (receta, hash) hace bien — pero quien
cuenta líneas no lo ve.
Se deja el veredicto medido intacto y se añade a qué hash fue superado. El único
no-determinismo VIGENTE al hash de hoy es `gocryptfs`, que no está en ningún perfil.
Los dos ya reconstruidos contra el syntax-highlighting arreglado.
REPRODUCEN 2 · DERIVA 0 · NO-DETERMINISMO 0.
Sellar de nuevo no demuestra nada por sí solo: lo que cierra el arreglo es que el
árbol reconstruido REPRODUZCA.
Como cosmic-comp no emite DEBUG (macros compiladas fuera), se le pregunto
por el protocolo con WAYLAND_DEBUG=1. Manda configure_bounds(0,0) al
mapear, despues bounds(1280,692) y configure(117,70): la ventana queda de
117x70. El pixel lo confirma — restando el cuadro de antes aparece un
cluster de 286x86 con la decoracion de COSMIC en (496,115).
Cae la hipotesis del §6.10.nonies: hay 43 wl_callback.done, o sea que SI
hay frame callbacks. Y la tasa 2 de 10 no medía «pinto/no pinto» sino
«ventana grande / ventana de 117x70».
Arnes: --wayland-debug y --set-rust-log (perilla por /etc/cosmic-mode, que
cosmic-start lee antes de RUST_LOG); margen de espera 420->780s porque con
carga ~13 la VM no llegaba al shell.
El arreglo movió el hash (4c1638a0… → 3db73c19…) y con él sus 4 dependientes
directos y 5 transitivos: kate, ktexteditor, plasma-desktop, plasma-workspace y
powerdevil. Comprobado aparte del log: para las seis existe
`store/<hash-de-hoy>-<nombre>`.
⚠ `kate` falló en el primer intento con «No space left on device» y esta vez NO era
el disco: `/mnt/vvv` tenía 15 G libres. El que se agotaba era un **tmpfs**, y un
tmpfs sin sitio significa RAM sin sitio — la caja tenía 855 MB disponibles, zram ya
con 6,3 G, otro agente compilando Rust y un QEMU encima. Al reintentar con 1,7 G
disponibles construyó en 242 s a la primera.
Que el mismo mensaje signifique dos cosas distintas —disco lleno o RAM llena— es
justo lo que hace caro el diagnóstico: hay que mirar QUÉ sistema de ficheros, no
sólo `df` del que uno tiene en la cabeza.
`rustc 1.97.0` y `cargo 1.97.0` responden en `2.29.29.217`, y un `fn main(){println!("ok");}`
compila y **corre**. El toolchain oficial de rust-lang, verificado por su sha256 y sellado tal cual
con `foreign = true` (son bytes ajenos, no un build nuestro: clase `ajeno`, fuera del recuento del
corpus).
Lo que costó hacerlo correr, y ninguna de las dos cosas se ve en el grafo porque las dos estaban
`sealed` y en el perfil equivocado:
1. **El cargador musl.** `rustc` es PIE dinámico (`NEEDED librustc_driver-*.so`, `NEEDED libc.so`).
En el worker ni arranca —`cannot execute: required file not found`, que es como se ve la falta
del intérprete—; en la caja sí, porque ahí está `musl-shared`.
2. **`libgcc_s.so.1`**: `Error loading shared library … _Unwind_Resume: symbol not found`. Lo
publica `gcc-libs`, sellado y declarado **sólo en los cuatro perfiles de escritorio**. Una línea
en `base`. Es la tercera vez HOY que aparece la misma figura —`tar`, `os-release`, `gcc-libs`—:
el paquete existe, está sellado, y no viaja en la imagen que lo necesita.
Y una propiedad que vale anotar: **no hace falta un `cc`**. El primer `rustc` falla con
`linker \`cc\` not found` y no hay que traer un compilador de C — el toolchain **trae su propio
lld** (`rustlib/<target>/bin/rust-lld`), y con `-C linker-flavor=ld.lld -C link-self-contained=yes`
enlaza y el binario corre. Una distro sin compilador de C puede compilar Rust igual.
Va en `perfil.servidor` y no en `base`: son 799 M y una imagen de escritorio no compila nada.
Pendiente, que es config del SITIO y no de la receta: que esas flags sean el default
(`/etc/cargo/config.toml`), para que `cargo build` funcione sin recordarlas.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016Tf9T4vGzsMoT7eS8YzMFn
Sergio