Files
takana/recipes
Sergio cddae46205 wasi-libcxx: el directorio VACÍO que hace visible a libc++ (y el guardián que lo prueba)
Segunda muerte del firefox con RLBox, otra vez a los 6 segundos y con el mismo
mensaje engañoso, ya con wasi-libcxx sellado:

    checking the wasm C compiler can find wasi headers... yes
    checking the wasm C++ compiler can find wasi headers...
    fatal error: 'cstring' file not found

El C pasaba todo y sólo fallaba el C++. Y `cstring` ESTABA en el artefacto, en
include/wasm32-wasip1/c++/v1/cstring. No era un fichero que faltara: era un
fichero que clang no buscaba.

CAUSA. El APKBUILD de Alpine hace un `mkdir -p .../include/c++/v1` que parece
ruido de empaquetado y yo descarté al transcribir. Es la SONDA por la que el
driver de clang decide que el sysroot tiene layout de libc++; sin ese directorio
no añade `include/<triple>/c++/v1` a la lista de búsqueda.

MEDIDO, no deducido. Sysroot fusionado (wasi-libc + wasi-libcxx) y la invocación
literal del configure de Mozilla, dentro del lab:

    clang++ -std=gnu++20 --target=wasm32-wasip1 conftest.cpp --sysroot=$S -c

    sin include/c++/v1  ->  fatal error: 'cstring' file not found
    con include/c++/v1  ->  exit 0

Es el reverso exacto de la regla 3 del CLAUDE.md: allá un directorio vacío es un
artefacto mentiroso, acá un directorio vacío es una declaración dirigida al
compilador. Queda documentado en la receta para que nadie lo borre por limpieza.

Y la lección que deja el guardián nuevo: los tests de presencia que tenía la
receta habrían dado esto por bueno, porque "existe" no es "se encuentra". Así
que ahora la receta corre LA MISMA PRUEBA que el configure de firefox, contra un
sysroot fusionado con el de su dep. Si pasa acá no puede fallar allá; y si falla,
falla en el segundo 20 de esta receta —imprimiendo la lista de búsqueda de
clang— y no en el segundo 6 de un build de cuatro horas que además culpa a otro.

Re-hashea: wasi-libcxx b3:1361deae -> b3:838a9557, y con él firefox.
2026-09-06 01:46:38 +00:00
..