sergio/takana

1# firefox-instrumentado — el firefox de al lado, pero COMPILADO PARA MEDIRSE. Andamiaje del PGO
2# (SDD 26, unidad 3.a): existe sólo para correrlo una vez y quedarse con el perfil que emite.
3#
4# ══ QUÉ ES Y QUÉ NO ════════════════════════════════════════════════════════════════════════════
5# Es `recipes/firefox.toml` con UNA opción de más, `--enable-profile-generate=cross`, que hace que
6# clang instrumente cada rama. El binario resultante es LENTO y NO se distribuye: se ejecuta una
7# vez bajo un sway headless, escupe `.profraw`, y de ahí sale el `merged.profdata` que el firefox
8# de verdad consume con `--enable-profile-use=cross`.
9#
10# ⚠ ES UNA COPIA DE `firefox.toml` Y ESO TIENE UN PRECIO CONOCIDO. Dos ficheros que describen el
11# mismo build divergen sin que nada lo diga, y un perfil recogido de un binario que ya no se parece
12# al que se optimiza vale menos que ninguno. **Si se toca `firefox.toml` —deps, parches, mozconfig—
13# hay que tocar esto.** Se generó derivándolo del original, no escribiéndolo a mano, justamente para
14# que naciera igual; mantenerlo igual es responsabilidad de quien edite.
15#
16# ⚠ POR QUÉ EL PERFIL NO SE GENERA DENTRO DE HAMMER. Correr el navegador exige un compositor, y
17# meter sway en el sandbox pediría ~11 librerías más sobre las ~35 de firefox — cerca del límite de
18# 4 KB del `lowerdir=` de bwrap que ya tumbó a kio con 52 deps. Pero el argumento de fondo no es el
19# coste: **el perfil NO ES DETERMINISTA** (los contadores dependen del timing), así que meterlo en un
20# build hermético no compra reproducibilidad, sólo la finge. El paso no determinista vive FUERA y su
21# salida entra como fuente pineada, que es exactamente lo que el ADR 0013 hace con las fuentes.
22
23name    = "firefox-instrumentado"
24version = "154.0"
25license = "MPL-2.0"
26
27[source]
28# Tarball de RELEASE de Mozilla: fichero SUBIDO por upstream, sha256 estable y publicado en su
29# SHA256SUMS. No es un `/archive/<tag>` de forja, que se genera al vuelo (ver `recipes/mbedtls.toml`).
30tarball = "https://ftp.mozilla.org/pub/firefox/releases/154.0/source/firefox-154.0.source.tar.xz"
31sha256  = "36cec5b3688a60f78a6d20dcaee15b598f84e03c66f6587056aead6cb498b99a"
32# Los once de musl del APKBUILD de Alpine (community/firefox). NO se traen los suyos de ppc64le,
33# loongarch ni Android: no aplican a x86_64 y cada parche que no hace falta es una forma más de que
34# un rebase falle sin motivo.
35patches = [
36  "firefox-patches/lfs64.patch",
37  "firefox-patches/time64.patch",
38  "firefox-patches/musl-no-linux-prctl.patch",
39  "firefox-patches/fix-fortify-system-wrappers.patch",
40  "firefox-patches/fix-rust-target.patch",
41  "firefox-patches/sandbox-sched_setscheduler.patch",
42  "firefox-patches/abseil-cpp.patch",
43  "firefox-patches/glean-stub.patch",
44  "firefox-patches/rust-lto-thin.patch",
45  "firefox-patches/wasip1.patch",
46  "firefox-patches/widevine.patch",
47]
48
49[build]
50# ══ `clang` — Y POR QUÉ YA NO ES `gcc` (2026-09-05) ════════════════════════════════════════════
51# HISTORIA: esta receta nació con `compiler = "gcc"` porque con zig-cc el configure de Firefox murió
52# tres veces seguidas. Los tres muros eran REALES y siguen siéndolo para zig:
53#
54#   1. «Could not use lld as linker» — zig se identifica como `zig ld 0.16.0` y el sondeo de Mozilla
55#      clasifica por esa cadena buscando «LLD»/«GNU ld»/«GNU gold».
56#   2. «Cannot find ar» — zig trae `ar` como SUBCOMANDO y `check_prog` busca un ejecutable.
57#   3. «Firefox does not support linking statically with libstdc++» — `flags.configure:79` compila un
58#      C++ mínimo, lo pasa por `llvm-objdump --private-headers` y exige un `NEEDED` de la stdlib de
59#      C++. zig enlaza libc++ ESTÁTICA para musl, así que ese NEEDED no existe nunca.
60#
61# gcc satisfacía los tres, pero al precio de quedar FUERA de la cadena de optimización de Gecko:
62# **PGO, LTO y BOLT son cadena de clang en Firefox** (`--enable-lto=cross` quiere clang+lld,
63# `--enable-profile-use=cross` espera `-fprofile-instr-use`). Con gcc no hay perilla que encender.
64# Medido contra el APKBUILD de `community/firefox` de aports —nuestro propio upstream, de donde
65# salen los once parches de musl— y contra el PKGBUILD de Arch: **las dos hacen LTO y PGO**. No
66# estábamos adelante de nadie; estábamos atrás, y la puerta era el compilador.
67#
68# clang RESUELVE LOS TRES MUROS SIN PERDER NADA:
69#   1. `--enable-linker=lld` + `lld` en el lab (añadido a `bootstrap-devfs.sh` el 2026-09-05).
70#   2. `AR=llvm-ar` lo pone takana solo con `compiler="clang"` (takana-build/src/lib.rs), y la suite
71#      `llvm-*` está expuesta en `/usr/bin` por el paso 3a-ter del bootstrap.
72#   3. clang++ de Alpine usa la `libstdc++` COMPARTIDA de gcc ⇒ el `NEEDED` existe. La prueba no es
73#      teórica: Alpine construye este mismo Firefox con clang22 y **sin** `libcxx` en sus makedepends.
74#
75# El lab ya traía `clang22`/`llvm22` 22.1.8 (la MISMA major que usa Alpine: `_llvmver=22`), así que
76# esto no costó una receta de LLVM: costó `apk add lld`.
77#
78# ⚠ EL PRECIO, ESCRITO: el toolchain del lab SÍ entra en `hash_inputs` desde el 2026-08-10
79# (`takana-core/src/lab.rs`), pero **`lld` no casa ningún prefijo de `TOOLCHAIN_PREFIXES`** ⇒ su
80# versión NO está en la huella. Eso es lo que permitió añadirlo sin re-hashear los 837 artefactos
81# sellados —medido: la huella no se movió—, y a la vez deja un agujero que sólo expone a las recetas
82# `compiler="clang"`, que hoy es ésta. Cerrarlo cuesta un re-hasheo del corpus entero.
83compiler = "clang"
84target   = "x86_64-linux-musl"
85link     = "dynamic"
86flags    = []
87# ══ `strip_debug`: SIN ESTO EL ARTEFACTO SERÍA INMANEJABLE ═════════════════════════════════════
88# Medido en el `nodejs` que acaba de sellar sin strip: su binario pesa **984 MB, de los cuales
89# `.debug_info` son 497 MB y `.debug_line` otros 43** — más de la mitad del artefacto es información
90# de depuración. Firefox es varias veces V8, así que sin strip su artefacto entraría en varios GB, y
91# el store no es sólo disco: se sincroniza hub↔worker y se respalda.
92#
93# Es además el hallazgo del SDD 23: el 79% del contenido binario del store era `.debug_*`, y quitarlo
94# hace que artefactos que no reproducían PASEN a reproducir, porque lo que difería eran las rutas del
95# árbol de build embebidas en esas secciones.
96#
97# Entra en `hash_inputs` A PROPÓSITO (cambia el contenido del artefacto), y usa `zig objcopy`, que
98# siempre está en el sandbox ⇒ no agrega una dep de build.
99strip_debug = true
100# ══ `MOZ_BUILD_DATE`: SIN ESTO EL ARTEFACTO NO REPRODUCE ══════════════════════════════════════
101# El `BuildID` de `application.ini` es, por defecto, la FECHA Y HORA del build. Medido en el
102# artefacto sellado del 2026-09-05: `BuildID=20260905035306`. Dos construcciones de esta misma
103# receta, con el mismo ArtifactHash, producían bytes distintos — justo el agujero que el invariante
104# de reproducibilidad existe para cerrar, y que `build-state.json` no puede ver porque el hash es
105# input-addressed y no se mueve por esto.
106#
107# El valor sale de `SOURCE_DATE_EPOCH`, que el sandbox de takana YA fija a 1 para todas las recetas.
108# Es mejor que una constante escrita a mano: usa el mecanismo de hermeticidad que ya existe, en vez
109# de inventar un segundo. Alpine hace exactamente lo mismo en su APKBUILD.
110
111[build.phases]
112configure = '''
113export MOZBUILD_STATE_PATH="$PWD/.mozbuild"
114export MACH_BUILD_PYTHON_NATIVE_PACKAGE_SOURCE=system
115export MOZ_NOSPAM=1
116# ── RUST_TARGET: lo EXIGE el parche de Alpine, no Firefox ─────────────────────────────────────
117# `fix-rust-target.patch` REEMPLAZA la autodetección del triple de Rust por un
118# `os.environ['RUST_TARGET']` pelado. Sin la variable, configure muere con
119# `KeyError: 'RUST_TARGET'` — que se lee como un bug de Firefox y es en realidad el contrato del
120# parche: el APKBUILD de Alpine lo exporta como `$CTARGET` y acá hay que hacer lo propio.
121# El valor NO se adivina: sale de `ls .dev-fs/alpine/usr/lib/rustlib/` en el lab, que es
122# `x86_64-alpine-linux-musl` — el rustc del sandbox es el de Alpine, no el del host (el del host es
123# `x86_64-unknown-linux-gnu` y usarlo produciría un cross-compile silencioso).
124export RUST_TARGET=x86_64-alpine-linux-musl
125
126# ── `MOZ_REQUIRE_SIGNING=0`: SIN ESTO LA DISTRO NO PUEDE SHIPEAR NI UNA EXTENSIÓN PROPIA ──────
127# Firefox exige que todo XPI esté firmado por Mozilla. La pref `xpinstall.signatures.required` NO
128# alcanza: se ignora cuando la exigencia viene COMPILADA, y viene compilada porque el default de
129# `MOZ_REQUIRE_SIGNING` sale del MILESTONE (154.0 es release), no del canal de actualización — el
130# nuestro es `default`, y aun así estaba activa.
131#
132# Medido, no deducido: con el autoconfig ejecutándose de verdad (testigo `atuq.autoconfig.ok=true`
133# en el perfil) y `lockPref("xpinstall.signatures.required", false)` puesta, la instalación por
134# política seguía muriendo con `ERROR_SIGNEDSTATE_REQUIRED`.
135#
136# ⚠ EL PRECIO, ESCRITO: este Firefox —y por herencia `atuq`— deja de exigir la firma de Mozilla
137# para CUALQUIER complemento, no sólo los nuestros. La alternativa real es firmar en AMO, que pide
138# cuenta y revisión de Mozilla por cada versión: exactamente la dependencia externa que esta distro
139# existe para no tener. Es la misma postura que ya tomaba `--with-unsigned-addon-scopes`, llevada
140# hasta donde de verdad hace falta.
141# ⚠ SE DESACTIVA CON EL VALOR VACÍO, NO CON CERO. `MOZ_REQUIRE_SIGNING=0` muere con
142# «InvalidOptionError: MOZ_REQUIRE_SIGNING takes 0 values», porque es una bandera booleana y el `0`
143# es un VALOR que no acepta. La semántica está en el propio parser de mozbuild
144# (`python/mozbuild/mozbuild/configure/options.py`), y no se dedujo: se leyó del tarball —
145#     if values == ("",):  return NegativeOptionValue()   ⇒ VAR=   (vacío) DESACTIVA
146#     if values == ("1",): return PositiveOptionValue()   ⇒ VAR=1  activa
147# El `export` con valor vacío es lo que hace llegar la variable PRESENTE y vacía; desexportarla la
148# dejaría sin definir y volvería al default, que acá es «exigir firma».
149export MOZ_REQUIRE_SIGNING=
150export MOZ_BUILD_DATE="$(date -u -d "@${SOURCE_DATE_EPOCH:-1}" +%Y%m%d%H%M%S)"
151
152# ── LOS PARCHES ROMPEN EL CHECKSUM DE LOS CRATES VENDORIZADOS ─────────────────────────────────
153# `error: the listed checksum of third_party/rust/zeitstempel/src/unix.rs has changed`. Los crates
154# de Rust vienen VENDORIZADOS en el tarball y cargo verifica el sha de CADA fichero contra
155# `.cargo-checksum.json`; en cuanto un parche de musl toca uno, el build muere. Cargo no ofrece
156# ninguna forma de recalcularlo, así que la salida —la misma del APKBUILD de Alpine— es vaciar la
157# lista de ficheros del manifiesto, dejando el checksum del paquete.
158#
159# Son los CINCO crates que tocan los parches, no uno: el error los va destapando de a uno y buscarlos
160# por prueba y error costaría cinco vueltas de configure.
161for c in audio_thread_priority cc zeitstempel wgpu-hal alsa; do
162  f="third_party/rust/$c/.cargo-checksum.json"
163  [ -f "$f" ] || { echo "FALTA $f — ¿upstream movió el crate?" >&2; exit 1; }
164  sed -i 's/\("files":{\)[^}]*/\1/' "$f"
165done
166cat > .mozconfig <<'MOZ'
167ac_add_options --prefix=/usr
168ac_add_options --enable-application=browser
169ac_add_options --enable-default-toolkit=cairo-gtk3-wayland
170ac_add_options --enable-release
171ac_add_options --enable-optimize
172ac_add_options --enable-hardening
173# ── LA CADENA DE OPTIMIZACIÓN (2026-09-05) ────────────────────────────────────────────────────
174# Las tres primeras son lo que Alpine y Arch ya hacían y nosotros no. `--enable-linker=lld` además
175# resuelve el muro 1 del sondeo de linker (ver el bloque [build]).
176ac_add_options --enable-linker=lld
177ac_add_options --enable-lto=cross
178ac_add_options --enable-profile-generate=cross
179ac_add_options --enable-packed-relative-relocs
180# ── LO QUE HABILITA A `atuq` (SDD 26) ─────────────────────────────────────────────────────────
181# Sin esto un Firefox de release rechaza las extensiones que la distro deja en
182# `distribution/extensions/`. Es flag de CONFIGURE, o sea que NO se puede resolver en el overlay del
183# artefacto derivado: la capacidad de `atuq` de shipear sus propias extensiones (el `sct` v1) se
184# decide acá, en la base. Alpine pasa exactamente este flag y por el mismo motivo.
185ac_add_options --with-unsigned-addon-scopes=app,system
186ac_add_options --with-branding=browser/branding/unofficial
187ac_add_options --with-libclang-path=/usr/lib
188ac_add_options --disable-bootstrap
189ac_add_options --disable-jemalloc
190ac_add_options --disable-crashreporter
191ac_add_options --disable-updater
192ac_add_options --disable-tests
193ac_add_options --disable-debug
194ac_add_options --disable-debug-symbols
195ac_add_options --disable-strip
196ac_add_options --disable-install-strip
197ac_add_options --disable-cargo-incremental
198ac_add_options --with-wasi-sysroot=/usr/share/wasi-sysroot
199ac_add_options --enable-alsa
200ac_add_options --enable-pulseaudio
201ac_add_options --enable-dbus
202ac_add_options --enable-ffmpeg
203mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir
204MOZ
205# ── POR QUÉ AQUÍ NO HAY PGO TODAVÍA ───────────────────────────────────────────────────────────
206# PGO es la otra mitad de la ganancia (LTO solo rinde menos que LTO+PGO) y NO entra en esta pasada
207# por dos muros que las distros no tienen, porque no persiguen lo que nosotros perseguimos:
208#   1. El perfil se junta CORRIENDO el navegador. Alpine y Arch lo hacen bajo `xvfb-run`; nosotros
209#      NO tenemos X11 en el corpus (la distro es Wayland-only) ⇒ el camino es un sway headless.
210#   2. El `profdata` NO es determinista (los contadores dependen del timing) ⇒ si se generara aquí,
211#      cada build sellaría bytes distintos. La salida es generarlo UNA vez, sellarlo como artefacto
212#      propio y consumirlo por hash desde `[deps]`.
213# Es su propia unidad de trabajo (SDD 26 §3.ter). Cuando llegue, además trae el `jarlog`, que ordena
214# el `omni.ja` para el arranque — y eso condiciona cómo `atuq` puede re-empacarlo.
215#
216# ── ThinLTO Y LA MEMORIA ──────────────────────────────────────────────────────────────────────
217# El enlace ThinLTO abre un trabajo por hilo y cada uno carga bitcode: sin capar, el link es lo
218# primero que muere por OOM en una máquina de 16 GiB. Se capa con la MISMA cuenta que `-j` y por la
219# misma razón que ella no es un número fijo: un literal ataría el ArtifactHash a la RAM de quien
220# escribió la receta (ver la nota de la fase compile).
221# ⚠ Si algún día dos máquinas con distinto `nproc` sellan bytes distintos, el primer sospechoso es
222# este flag — ThinLTO se diseñó determinista respecto al número de trabajos, pero es una promesa
223# de upstream, no algo que hayamos medido acá.
224gib=$(awk "/MemTotal/{printf \"%d\", \$2/1024/1024}" /proc/meminfo)
225jl=$(( gib / 3 )); [ "$jl" -lt 1 ] && jl=1
226n=$(nproc); [ "$jl" -gt "$n" ] && jl=$n
227export LDFLAGS="${LDFLAGS:-} -Wl,--thinlto-jobs=$jl"
228echo "ThinLTO con --thinlto-jobs=$jl (MemTotal ${gib} GiB, nproc $n)"
229./mach configure
230'''
231# `mach build` respeta -jN; la cuenta es la misma que en nodejs.toml y por el mismo motivo: un número
232# fijo ataría el ArtifactHash a la RAM de quien escribió la receta.
233# ⚠ OJO con el techo: dentro del sandbox `/proc/meminfo` NO muestra la memoria del contenedor sino la
234# del host (medido en el LXC: 186 GiB en vez de 16), así que en un contenedor esta cuenta se degrada
235# a `nproc`. Es un tope, no una garantía.
236compile = '''
237export RUST_TARGET=x86_64-alpine-linux-musl   # ver la nota en la fase configure
238# ⚠ `MOZ_REQUIRE_SIGNING` TAMBIÉN ACÁ, Y NO ES REDUNDANCIA. Las fases son shells distintos y
239# `mach build` re-ejecuta el configure cuando lo cree necesario: exportarla sólo en la fase
240# `configure` produjo un artefacto con `MOZ_REQUIRE_SIGNING: true` pese a que el configure la
241# aceptó — 50 minutos de build para descubrirlo al abrir el navegador. Es exactamente la razón por
242# la que `RUST_TARGET` se repite en las tres fases.
243export MOZ_REQUIRE_SIGNING=
244export MOZ_BUILD_DATE="$(date -u -d "@${SOURCE_DATE_EPOCH:-1}" +%Y%m%d%H%M%S)"   # ídem: ver configure
245export MOZBUILD_STATE_PATH="$PWD/.mozbuild"
246export MACH_BUILD_PYTHON_NATIVE_PACKAGE_SOURCE=system
247export MOZ_NOSPAM=1
248gib=$(awk "/MemTotal/{printf \"%d\", \$2/1024/1024}" /proc/meminfo)
249j=$(( gib / 3 )); [ "$j" -lt 1 ] && j=1
250n=$(nproc); [ "$j" -gt "$n" ] && j=$n
251echo "mach build -j$j (MemTotal ${gib} GiB, nproc $n)"
252./mach build -j"$j"
253'''
254install = '''
255export RUST_TARGET=x86_64-alpine-linux-musl   # ver la nota en la fase configure
256export MOZ_REQUIRE_SIGNING=                   # ídem
257export MOZ_BUILD_DATE="$(date -u -d "@${SOURCE_DATE_EPOCH:-1}" +%Y%m%d%H%M%S)"   # ídem
258export MOZBUILD_STATE_PATH="$PWD/.mozbuild"
259export MACH_BUILD_PYTHON_NATIVE_PACKAGE_SOURCE=system
260DESTDIR=/out ./mach install
261
262# ── GUARDIÁN: QUE LA BANDERA HAYA LLEGADO AL ARTEFACTO, NO AL CONFIGURE ───────────────────────
263# `MOZ_REQUIRE_SIGNING` es una bandera que el configure acepta sin ruido y que aun así puede acabar
264# en `true` dentro del artefacto (pasó: la exportábamos sólo en `configure`). El síntoma aparece
265# lejísimos —al intentar instalar una extensión de la distro, en otra receta, tras 50 minutos de
266# build— y no menciona la bandera por ningún lado. Se comprueba donde de verdad importa: en el
267# `AppConstants` que va DENTRO de omni.ja.
268python3 - <<'PY'
269import sys, zipfile
270z = zipfile.ZipFile("/out/usr/lib/firefox/omni.ja")
271n = [x for x in z.namelist() if x.endswith("AppConstants.sys.mjs")]
272if not n:
273    sys.exit("guardián: no encontré AppConstants.sys.mjs en omni.ja")
274t = z.read(n[0]).decode("utf-8", "replace")
275if "MOZ_REQUIRE_SIGNING: false" not in t:
276    sys.exit("guardián: MOZ_REQUIRE_SIGNING NO quedó en false — la distro no podría "
277             "instalar ninguna extensión propia. Revisá que la variable se exporte en TODAS "
278             "las fases (son shells distintos y mach re-ejecuta configure).")
279print("guardián: MOZ_REQUIRE_SIGNING = false en el artefacto")
280PY
281
282# ── GUARDIÁN: QUE EL BuildID NO SEA UNA FECHA ────────────────────────────────────────────────
283# Mismo razonamiento que el de arriba, y el mismo modo de fallo: si `MOZ_BUILD_DATE` no llega, el
284# BuildID vuelve a ser la hora del build y el artefacto deja de reproducir SIN QUE NADA LO DIGA —
285# el ArtifactHash es input-addressed y no se mueve por esto, así que `build-state.json` seguiría en
286# verde. Se comprueba contra el valor que `SOURCE_DATE_EPOCH=1` obliga.
287esperado="$(date -u -d "@${SOURCE_DATE_EPOCH:-1}" +%Y%m%d%H%M%S)"
288real="$(sed -n 's/^BuildID=//p' /out/usr/lib/firefox/application.ini)"
289if [ "$real" != "$esperado" ]; then
290  echo "guardián: BuildID=$real y esperaba $esperado — el artefacto NO reproduce." >&2
291  echo "          Revisá que MOZ_BUILD_DATE se exporte en TODAS las fases." >&2
292  exit 1
293fi
294echo "guardián: BuildID = $real (determinista, de SOURCE_DATE_EPOCH)"
295
296# ── GUARDIÁN: QUE LA INSTRUMENTACIÓN HAYA LLEGADO AL BINARIO ─────────────────────────────────
297# Misma lección que RLBox: `--enable-profile-generate=cross` es una opción que el configure acepta
298# sin ruido, y un binario SIN instrumentar corre perfecto y no emite ni un `.profraw`. El fallo se
299# descubriría al final de la corrida de perfilado, con las manos vacías y sin nada que lo explique.
300# clang deja símbolos `__llvm_profile_*` en todo binario instrumentado; sin instrumentar son CERO.
301X=/out/usr/lib/firefox/libxul.so
302n=$(llvm-nm --defined-only "$X" 2>/dev/null | grep -c " __llvm_profile_")
303test "$n" -gt 0 || {
304  echo "!! el binario NO está instrumentado: 0 símbolos __llvm_profile_* en libxul.so" >&2
305  echo "   el configure aceptó --enable-profile-generate=cross y no hizo nada." >&2
306  exit 1
307}
308echo "guardián: instrumentado ($n símbolos __llvm_profile_*; sin instrumentar serían 0)"
309
310# ── GUARDIÁN: QUE RLBOX ESTÉ EN EL BINARIO, NO SÓLO EN EL CONFIGURE ───────────────────────────
311# Tercera repetición de la misma lección, y por eso nace junto con la bandera en vez de después:
312# `--with-wasi-sysroot` es exactamente la clase de opción que el configure acepta sin chistar y
313# que puede no llegar al artefacto. Ya pasó dos veces en ESTA receta (`MOZ_REQUIRE_SIGNING` y
314# `MOZ_BUILD_DATE`), y acá el fallo sería el más caro de todos: un firefox que dice tener
315# enjaulados los parsers de fuentes y medios —el código que come entrada NO confiable de la red—
316# y no los tiene. Una promesa falsa de seguridad es peor que no ofrecerla.
317#
318# QUÉ SE MIRA. RLBox compila esas librerías a wasm y las traduce a C con wasm2c, que deja su
319# rastro en los símbolos de `libxul.so`. El discriminante está MEDIDO, no supuesto: sobre el
320# artefacto `b3:352d7880` (el último con RLBox APAGADO, 224 MB de libxul) los tres patrones dan
321# CERO, así que cualquiera de ellos apareciendo significa que la jaula entró de verdad.
322# Se aceptan los tres y no sólo `w2c_` a propósito: el prefijo exacto es un detalle de la versión
323# de wasm2c, y un guardián que falla por un cambio de convención de nombres tira 4 h de build por
324# algo que no está roto. Lo que NO puede pasar desapercibido es que los tres sigan en cero.
325X=/out/usr/lib/firefox/libxul.so
326test -f "$X" || { echo "!! no hay libxul.so en el artefacto" >&2; exit 1; }
327n_w2c=$(llvm-nm --defined-only "$X" 2>/dev/null | grep -c " w2c_" || true)
328n_rlb=$(llvm-nm "$X" 2>/dev/null | grep -ci rlbox || true)
329n_w2n=$(llvm-nm "$X" 2>/dev/null | grep -ci wasm2c || true)
330if [ $((n_w2c + n_rlb + n_w2n)) -eq 0 ]; then
331  echo "!! RLBOX NO LLEGÓ AL BINARIO: libxul.so no tiene NI UN símbolo w2c_/rlbox/wasm2c." >&2
332  echo "   El configure aceptó --with-wasi-sysroot pero el sandbox wasm no se construyó." >&2
333  echo "   Mirá si las deps wasi-libc / wasi-compiler-rt / wasi-sdk llegaron al sandbox y si" >&2
334  echo "   /usr/share/wasi-sysroot/lib/wasm32-wasip1/libc.a existe durante el build." >&2
335  exit 1
336fi
337echo "guardián: RLBox en el binario (w2c_=$n_w2c rlbox=$n_rlb wasm2c=$n_w2n; con RLBox apagado los tres son 0)"
338'''
339
340[deps]
341# ⚠ DEP DE EJECUCIÓN, NO DE BUILD — Y NO ES DECORACIÓN (2026-09-06).
342# Este artefacto declara `NEEDED libstdc++.so.6` / `libgcc_s.so.1`, y hasta hoy NADIE en el corpus
343# las proveía: sólo existían en `.dev-fs/alpine`, o sea en el LAB. El binario sellaba, REPRODUCÍA
344# bit a bit, pasaba todos los guardianes… y no arrancaba fuera del lab. Se descubrió corriendo
345# `atuq` bajo un sway headless, no leyendo el grafo.
346# `runtime` NO entra en el ArtifactHash (igual que `license`), así que declararlo NO re-hashea:
347# lo que cambia es la CLAUSURA, que es lo que se hidrata en la imagen. Lo vigila
348# `scripts/vigia-sonames.py`, que corre en el latido y deja `docs/state/sonames.txt`.
349runtime = ["gcc-libs"]
350build = [
351  "python3", "pkgconf", "nasm", "make", "cmake",
352  # la plataforma Gecko, compartida con los forks (SDD 26)
353  #
354  # ⚠ NI `clang18` NI `llvm18` — Y NO ES UN OLVIDO (2026-09-05) ─────────────────────────────────
355  # Estaban aquí cuando esta receta compilaba con gcc: `clang18` aportaba el `libclang.so` que
356  # bindgen carga en runtime y `llvm18` la suite `llvm-ar`/`llvm-objdump` que Mozilla exige. Con
357  # `compiler = "clang"` se volvieron ACTIVAMENTE DAÑINAS: una dep del corpus se materializa en el
358  # sandbox y **tapa** el binario del lab, así que `/usr/bin/llvm-ar` pasaba a ser el de LLVM 18
359  # mientras el compilador era clang 22. Con ThinLTO encendido los `.o` ya no son objetos sino
360  # BITCODE, y el bitcode no es compatible hacia atrás:
361  #
362  #     /usr/bin/llvm-ar: error: …log.o: 'Unknown attribute kind (102)'
363  #                              (Producer: 'LLVM22.1.8' Reader: 'LLVM 18.1.8')
364  #
365  # El error nombra las DOS versiones, que es lo que lo hace diagnosticable de un vistazo. Es la
366  # misma forma que la lección de los headers UAPI: una dep tapa al lab y el fallo aparece lejos.
367  # El lab ya trae todo lo necesario en la versión correcta —`clang22-libclang` deja
368  # `/usr/lib/libclang.so` y el paso 3a-ter del bootstrap expone la suite `llvm-*` de llvm22 en
369  # `/usr/bin`—, así que la respuesta no es apuntar el AR a mano: es NO traer el 18.
370  # Es además lo que hace Alpine: clang22 + clang22-libclang, sin un segundo LLVM en la mesa.
371  "nodejs", "cbindgen",
372  # Las mismas variantes `-shared` que usa gtk3 (2026-09-05). No es simetría: declarar acá las
373  # ESTÁTICAS junto a un gtk3 que trae las compartidas son dos artefactos peleando por el mismo
374  # `lib/pkgconfig/pango.pc` y las mismas cabeceras, que es la otra forma conocida de este mismo
375  # fallo. Van las dos listas al mismo sitio o ninguna.
376  "gtk3", "atk", "gdk-pixbuf-shared", "pango-shared", "cairo-shared", "libepoxy",
377  "glib-shared", "pcre2-shared", "libffi-shared", "zlib-shared",
378  "harfbuzz-shared", "fribidi", "freetype-shared", "fontconfig-shared", "pixman",
379  "libpng-shared", "libjpeg-turbo-shared",
380  "wayland", "wayland-protocols", "libxkbcommon", "mesa", "libdrm",
381  "dbus", "pipewire", "pulseaudio", "alsa-lib",
382  "libxml2-shared", "linux-headers",
383  # ── LA CADENA WASM DE RLBOX (SDD 26 §3.b) ──────────────────────────────────────────────────────
384  # Van las TRES, y no es redundancia: las deps de takana NO son transitivas. En el `bwrap` sólo se
385  # apilan como overlay las que están escritas acá; declarar sólo `wasi-sdk` NO arrastra al
386  # `wasi-libc` que necesita, y el fallo sería el peor de los posibles — el sysroot no existiría y
387  # el error saldría a las horas, hablando de un header de wasm que no nombra a ninguna receta.
388  #
389  #   wasi-libc         el sysroot en sí (`/usr/share/wasi-sysroot`), que es lo que apunta el flag
390  #   wasi-compiler-rt  los builtins (`libclang_rt.builtins-wasm32.a`) SIN LOS CUALES NO ENLAZA
391  #                     nada a wasm; aterrizan en el resource dir del clang del lab
392  #   wasi-sdk          el `.cfg` de `/etc/clang22`, que hace el sysroot invisible para quien no
393  #                     pasa el flag. Con `--with-wasi-sysroot` explícito es cinturón Y tirantes:
394  #                     se declara igual porque es lo que hace Alpine y porque cuesta 28 K.
395  #   wasi-libcxx       libc++ y libc++abi para wasm32. NO es opcional: las librerías que RLBox
396  #                     enjaula no son todas C (graphite2 es C++) y sin esto el configure muere a
397  #                     los 6 segundos con «'cstring' file not found», culpando a los headers de
398  #                     WASI, que están perfectos. Es el hueco que este build encontró.
399  "wasi-libc", "wasi-libcxx", "wasi-compiler-rt", "wasi-sdk",
400  # ⚠ SÓLO EL INSTRUMENTADO LA NECESITA. `-fprofile-generate` enlaza contra la runtime de perfilado
401  # de compiler-rt —la que escribe los `.profraw`— y el LAB NO TRAE NINGUNA runtime de compiler-rt:
402  # su `lib/` del resource dir ni existe. Sin esto el build muere en el minuto 38 con
403  # `ld.lld: cannot open .../libclang_rt.profile.a`. El firefox de producción usa
404  # `-fprofile-use`, que NO necesita la runtime, así que esta dep no va allá.
405  "compiler-rt-profile",
406]