Files
takana/recipes
Sergio 0ef8320c6c 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.
2026-09-06 05:03:57 +00:00
..