sergio/takana

Primer build con clang+ThinLTO: murió a los 4 minutos, y el error nombra las dos versiones, que es
lo que lo hace diagnosticable de un vistazo:

    /usr/bin/llvm-ar: error: …log.o: 'Unknown attribute kind (102)'
                             (Producer: 'LLVM22.1.8' Reader: 'LLVM 18.1.8')

`clang18` y `llvm18` estaban en [deps].build de cuando esta receta compilaba con gcc: aportaban el
libclang para bindgen y la suite llvm-ar/llvm-objdump que Mozilla exige. Con `compiler = "clang"` se
volvieron ACTIVAMENTE DAÑINAS: una dep del corpus se materializa en el sandbox y TAPA el binario del
lab, así que llvm-ar pasó a ser el de LLVM 18 con un compilador clang 22. Mientras los .o eran
objetos no se notaba; con ThinLTO son BITCODE, y el bitcode no es compatible hacia atrás.

Misma forma que la lección de los headers UAPI: una dep tapa al lab y el fallo aparece lejos del
sitio que lo causó.

El arreglo no es apuntar AR a mano, es no traer el 18: el lab ya expone
/usr/bin/llvm-{ar,objdump,profdata} → llvm22 y /usr/lib/libclang.so → llvm22 (paso 3a-ter del
bootstrap). Es además lo que hace Alpine: clang22 + clang22-libclang, sin un segundo LLVM en la mesa.
Y llvm-profdata del 22 es el que va a hacer falta para el PGO.

Nuevo ArtifactHash: b3:aa90192a141f9fc6d2b59acd074db6caa36854af7100fb08fb51c8fe441b72b7

diff --git a/recipes/firefox.toml b/recipes/firefox.toml
index d869374e..4329d7fc 100644
--- a/recipes/firefox.toml
+++ b/recipes/firefox.toml
@@ -253,8 +253,26 @@ DESTDIR=/out ./mach install
 [deps]
 build = [
   "python3", "pkgconf", "nasm", "make", "cmake",
-  # la plataforma Gecko, compartida con Waterfox y Zen
-  "nodejs", "cbindgen", "clang18", "llvm18",
+  # la plataforma Gecko, compartida con los forks (SDD 26)
+  #
+  # ⚠ NI `clang18` NI `llvm18` — Y NO ES UN OLVIDO (2026-09-05) ─────────────────────────────────
+  # Estaban aquí cuando esta receta compilaba con gcc: `clang18` aportaba el `libclang.so` que
+  # bindgen carga en runtime y `llvm18` la suite `llvm-ar`/`llvm-objdump` que Mozilla exige. Con
+  # `compiler = "clang"` se volvieron ACTIVAMENTE DAÑINAS: una dep del corpus se materializa en el
+  # sandbox y **tapa** el binario del lab, así que `/usr/bin/llvm-ar` pasaba a ser el de LLVM 18
+  # mientras el compilador era clang 22. Con ThinLTO encendido los `.o` ya no son objetos sino
+  # BITCODE, y el bitcode no es compatible hacia atrás:
+  #
+  #     /usr/bin/llvm-ar: error: …log.o: 'Unknown attribute kind (102)'
+  #                              (Producer: 'LLVM22.1.8' Reader: 'LLVM 18.1.8')
+  #
+  # El error nombra las DOS versiones, que es lo que lo hace diagnosticable de un vistazo. Es la
+  # misma forma que la lección de los headers UAPI: una dep tapa al lab y el fallo aparece lejos.
+  # El lab ya trae todo lo necesario en la versión correcta —`clang22-libclang` deja
+  # `/usr/lib/libclang.so` y el paso 3a-ter del bootstrap expone la suite `llvm-*` de llvm22 en
+  # `/usr/bin`—, así que la respuesta no es apuntar el AR a mano: es NO traer el 18.
+  # Es además lo que hace Alpine: clang22 + clang22-libclang, sin un segundo LLVM en la mesa.
+  "nodejs", "cbindgen",
   "gtk3", "atk", "gdk-pixbuf", "pango", "cairo", "libepoxy",
   "glib-shared", "pcre2-shared", "libffi-shared", "zlib-shared",
   "harfbuzz", "fribidi", "freetype-shared", "fontconfig-shared", "pixman",