tawasuyu

sergio/takana

> Una distribución Linux construida con un laboratorio funcional y hermético en el > sótano, y una terminal mutable, clásica y anárquica en el piso de arriba — diseñada > desde el suelo para que una IA programadora entienda, modifique y co…

TOML 1435Shell 145Markdown 88Rust 852973 Definiciones

waterfox: las variantes -shared de la cadena GUI, que es lo que mataba el enlace

El build llegaba al minuto 36 y moría enlazando libxul.so con un `collect2:
error: ld returned 1 exit status` y NADA delante — ni undefined reference, ni
cannot find -l, ni DSO missing. No era OOM ni disco. El filtro de salida de mach
clasificaba y descartaba justo el diagnóstico.

Rehecho el mismo objetivo llamando a gmake directo, el linker habló:

    ld: /usr/lib/libcairo.a(cairo-ft-font.c.o): in function `_cairo_ft_to_cairo_error':
        multiple definition of `_cairo_ft_to_cairo_error';
        gfx/cairo/cairo/src/cairo-ft-font.o: first defined here

…y así decenas de símbolos de cairo-ft-font, cairo-pdf-surface y
cairo-toy-font-face. O sea: el libcairo.a ESTÁTICO de la dep entra al enlace por
el -lcairo que arrastra el .pc de gtk3, y sus objetos chocan con el cairo
BUNDLEADO del propio árbol de Gecko.

La receta traía la lista de deps ANTERIOR a la migración de firefox: cairo,
pango, gdk-pixbuf y harfbuzz estáticas donde firefox ya usa las -shared. Y el
propio firefox.toml lo tiene escrito desde el 2026-09-05: declarar las estáticas
junto a un gtk3 que trae las compartidas son dos artefactos peleando por el
mismo .pc, «van las dos listas al mismo sitio o ninguna». Waterfox se quedó a
mitad de camino.

Con la variante compartida, -lcairo resuelve a libcairo.so y los símbolos
bundleados se quedan donde tienen que quedarse.

NO se tocan clang18/llvm18: firefox los quitó porque tapaban el LLVM 22 del lab
y con ThinLTO el bitcode no es compatible hacia atrás; acá el compilador es gcc,
así que ese razonamiento no aplica y cambiarlo sería otra unidad de trabajo.

Se deja puesta la rama de diagnóstico del compile: si mach falla, rehace el
enlace con gmake directo para que el linker hable. No cuesta nada en el camino
bueno (`&& exit 0`) y convirtió un fallo indiagnosticable en uno diagnosticado
en una sola corrida.

0ef8320c6c1d1361e556b81c4ea452c1a013b6d4 · por Sergio · (hace 1 mes) · padre 96bfa8fe5 · ver el árbol en este commit

Delta semántico

Ninguna definición cambió: el cambio es de texto, documentación o datos.

1 archivos · +34 −3

diff --git a/recipes/waterfox.toml b/recipes/waterfox.toml
index b9f0482e..54aa70bf 100644
--- a/recipes/waterfox.toml
+++ b/recipes/waterfox.toml
@@ -182,7 +182,27 @@ gib=$(awk "/MemTotal/{printf \"%d\", \$2/1024/1024}" /proc/meminfo)
 j=$(( gib / 3 )); [ "$j" -lt 1 ] && j=1
 n=$(nproc); [ "$j" -gt "$n" ] && j=$n
 echo "mach build -j$j (MemTotal ${gib} GiB, nproc $n)"
-./mach build -j"$j"
+./mach build -j"$j" && exit 0
+
+# ── EL ENLACE FALLA Y `mach` SE TRAGA EL MENSAJE DEL LINKER ───────────────────────────────────
+# Medido dos veces (2026-09-06, 03:20 y 04:08): el build llega al minuto ~36 y muere enlazando
+# `libxul.so` con
+#
+#     E collect2: error: ld returned 1 exit status
+#
+# y NADA delante. Entre la línea que anuncia el enlace y el `collect2` no hay ni un renglón en el
+# log, ni `undefined reference`, ni `cannot find -l`, ni `DSO missing`. No es OOM (13 G libres, swap
+# sin tocar) ni disco (37%). El filtro de salida de `mach` clasifica y descarta, y lo que descarta es
+# justo el diagnóstico.
+#
+# Así que si `mach` falla se REHACE el mismo objetivo llamando a gmake directo, sin el filtro de por
+# medio, y se deja hablar al linker. No cambia lo que se construye: es el mismo target sobre el mismo
+# objdir, sólo que sin nadie tapándole la boca. Si el enlace ahora pasa (porque el fallo fuera del
+# propio `mach`), igual salimos con error: esta rama existe para diagnosticar, no para aprobar.
+echo "=== mach falló; rehago el enlace SIN su filtro para ver qué dice ld ==="
+gmake -C objdir/toolkit/library/build V=1 2>&1 | tail -60
+echo "=== fin del reintento ==="
+exit 1
 '''
 install = '''
 export RUST_TARGET=x86_64-alpine-linux-musl   # ver la nota en la fase configure
@@ -196,9 +216,20 @@ build = [
   "python3", "pkgconf", "nasm", "make", "cmake",
   # la plataforma Gecko, compartida con Waterfox y Zen
   "nodejs", "cbindgen", "clang18", "llvm18",
-  "gtk3", "atk", "gdk-pixbuf", "pango", "cairo", "libepoxy",
+  # ⚠ LAS VARIANTES `-shared`, Y NO ES SIMETRÍA CON FIREFOX: ES EL FALLO QUE MATABA EL ENLACE.
+  # Con las estáticas, `libcairo.a` entra al enlace de `libxul.so` por el `-lcairo` que arrastra el
+  # `.pc` de gtk3, y sus objetos CHOCAN con el cairo BUNDLEADO del propio árbol de Gecko:
+  #
+  #     ld: /usr/lib/libcairo.a(cairo-ft-font.c.o): multiple definition of `_cairo_ft_to_cairo_error';
+  #         gfx/cairo/cairo/src/cairo-ft-font.o: first defined here
+  #
+  # …y así decenas de símbolos. Con la variante compartida, `-lcairo` resuelve a `libcairo.so` y los
+  # símbolos bundleados se quedan donde tienen que quedarse. Las cuatro van juntas por lo que ya
+  # dice `firefox.toml`: declarar las ESTÁTICAS junto a un `gtk3` que trae las compartidas son dos
+  # artefactos peleando por el mismo `.pc`. Van las dos listas al mismo sitio o ninguna.
+  "gtk3", "atk", "gdk-pixbuf-shared", "pango-shared", "cairo-shared", "libepoxy",
   "glib-shared", "pcre2-shared", "libffi-shared", "zlib-shared",
-  "harfbuzz", "fribidi", "freetype-shared", "fontconfig-shared", "pixman",
+  "harfbuzz-shared", "fribidi", "freetype-shared", "fontconfig-shared", "pixman",
   "libpng-shared", "libjpeg-turbo-shared",
   "wayland", "wayland-protocols", "libxkbcommon", "mesa", "libdrm",
   "dbus", "pipewire", "pulseaudio", "alsa-lib",