El firefox con RLBox murió en el configure a los SEIS SEGUNDOS:
/tmp/conftest.cpp:1:10: fatal error: 'cstring' file not found
ERROR: Cannot find wasi headers or problem with the wasm compiler.
El mensaje culpa a los headers de WASI y los headers de WASI estaban perfectos.
`<cstring>` es un header de C++ y `wasi-libc` sólo trae la C: las librerías que
RLBox enjaula no son todas C —graphite2 es C++— así que el sandbox necesita una
biblioteca estándar de C++ para wasm32. Mismo patrón que la lección de los
headers UAPI: el error nombra lo que buscó, no lo que falta.
El hueco estaba en el GRAFO antes de que el build lo encontrara, y se podía ver
sin construir nada: el `wasi-sdk` de Alpine declara
`depends="wasi-libc wasi-libcxx wasi-compiler-rt"` —TRES— y nosotros teníamos
dos. Queda anotado como método: cuando se porta una cadena ajena, la lista de
depends del paquete equivalente es una comprobación de completitud gratis.
La receta es el mismo tarball de LLVM 22.1.8 que `wasi-compiler-rt` (mismo
sha256) y repite su transcripción del toolchain file de wasi-sdk, por el mismo
motivo: 38 líneas de declaraciones puras no justifican una fuente de red y una
receta. Si se toca una, se toca la otra.
Dos detalles que son trampas y no adorno:
- Se construyen los DOS triples (wasip1 y wasip1-threads). `wasi-libc` ya publica
los dos y firefox pide el sysroot por nombre de triple, así que dejar uno sin
libc++ sería presente-a-medias, que es peor que ausente.
- cmake instala en el triple canónico (`wasm32-unknown-wasip1`) y clang busca en
el corto (`wasm32-wasip1`). Sin el renombre del install, libc++ queda al lado
del sitio donde se la busca: en el artefacto e invisible para el compilador.
El guardián exige exactamente lo que el configure no encontró —`cstring`,
`libc++.a` y `libc++abi.a`— para los dos triples.
Re-hashea: wasi-sdk b3:c8a587fa -> b3:f13634c6, firefox b3:98d6899a ->
b3:2880e28a.
62 lines
2.6 KiB
TOML
62 lines
2.6 KiB
TOML
# wasi-sdk — el fichero de configuración que le dice a clang dónde está el sysroot de wasm.
|
|
#
|
|
# Es la pieza más chica de la cadena y la que la vuelve INVISIBLE para quien la usa: sin esto,
|
|
# firefox tendría que enterarse por un flag de cómo llegar al sysroot; con esto, `clang
|
|
# --target=wasm32-wasip1` lo encuentra solo. El clang de Alpine lee `/etc/clang22/<triple>.cfg`
|
|
# —el lab ya trae ahí su propio `x86_64-alpine-linux-musl.cfg`, así que el mecanismo está probado en
|
|
# esta misma máquina— y overlayfs FUSIONA directorios, así que esta dep suma su fichero sin pisar el
|
|
# del lab.
|
|
#
|
|
# NO TIENE FUENTE UPSTREAM porque el contenido es nuestro: una línea. Usa `[source] dir`, el modo
|
|
# que se agregó para `atuq` (SDD 26 §2.ter). Es su segundo consumidor, y el primero fuera del caso
|
|
# que lo motivó.
|
|
#
|
|
# ⚠ `/etc/clang22` lleva la versión del lab en la RUTA. No es una constante que se pueda olvidar: si
|
|
# el lab sube de LLVM, esta ruta deja de existir y el sysroot se vuelve invisible en silencio — por
|
|
# eso el guardián de abajo comprueba que el directorio del lab exista ANTES de escribir dentro.
|
|
name = "wasi-sdk"
|
|
version = "27"
|
|
license = "Apache-2.0"
|
|
|
|
[source]
|
|
dir = "wasi-sdk"
|
|
|
|
[build]
|
|
compiler = "clang"
|
|
|
|
[deps]
|
|
# Las TRES que declara el `wasi-sdk` de Alpine (`depends="wasi-libc wasi-libcxx
|
|
# wasi-compiler-rt"`), verificado contra su APKBUILD el 2026-09-06. Acá `wasi-libcxx` no es
|
|
# decorativa: sin ella el sysroot al que apunta el .cfg tiene la C y no la C++, y el guardián de
|
|
# abajo —que sólo mira `libc.a`— lo daría por bueno.
|
|
build = ["wasi-libc", "wasi-libcxx"]
|
|
|
|
[build.phases]
|
|
configure = "true"
|
|
compile = "true"
|
|
install = '''
|
|
set -e
|
|
|
|
# Si el lab cambió de versión de LLVM, esta ruta ya no es la que clang lee. Fallar acá es barato;
|
|
# fallar dentro del build de firefox, cuatro horas después y con un error sobre un header de wasm
|
|
# que no nombra a esta receta, no lo es.
|
|
test -d /etc/clang22 || {
|
|
echo "!! el lab no tiene /etc/clang22: ¿subió de versión de LLVM?" >&2
|
|
ls -d /etc/clang* 2>/dev/null >&2
|
|
exit 1
|
|
}
|
|
|
|
mkdir -p /out/etc/clang22
|
|
cp /src/wasm32-unknown-wasip1.cfg /out/etc/clang22/
|
|
cp /src/wasm32-unknown-wasip1-threads.cfg /out/etc/clang22/
|
|
|
|
# GUARDIÁN: que el sysroot al que apunta el .cfg EXISTA. Un `--sysroot` que señala a la nada no da
|
|
# error: clang sigue adelante y falla mucho después por headers que no encuentra.
|
|
S=$(sed -n 's/^--sysroot //p' /out/etc/clang22/wasm32-unknown-wasip1.cfg)
|
|
test -f "$S/lib/wasm32-wasip1/libc.a" || {
|
|
echo "!! el .cfg apunta a $S y ahí no hay libc.a de wasm32-wasip1" >&2
|
|
exit 1
|
|
}
|
|
echo "guardián: /etc/clang22 apunta a un sysroot wasm real ($S)"
|
|
'''
|