From 6dbe17f87d3ca4cbb67cc23152c02ed655544edd Mon Sep 17 00:00:00 2001 From: Sergio Date: Sat, 5 Sep 2026 03:51:39 +0000 Subject: [PATCH] =?UTF-8?q?firefox:=20fuera=20`clang18`=20y=20`llvm18`=20?= =?UTF-8?q?=E2=80=94=20una=20dep=20del=20corpus=20tapaba=20el=20llvm-ar=20?= =?UTF-8?q?del=20lab?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- recipes/firefox.toml | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-) 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",