`dwarves` estaba SELLADA y llevaba tiempo sin construir. Se destapó al arreglar los symlinks de
`bzip2`: su hash se movió, dwarves cayó a deuda, y al reconstruirla el link murió con
`Error running link command: Segmentation fault` — crash del linker, no error de símbolos.
**No lo rompió el cambio de bzip2, y se puede probar**: el `libbz2.a` y el `bzlib.h` nuevos son
byte-idénticos a los viejos (`cmp -s`); lo único que cambió fueron cuatro destinos de symlink. El
artefacto sellado tapaba una rotura que ya existía — el lab rueda desde Alpine edge y zig subió. El
rehash no causó la rotura: la DESTAPÓ.
## La causa, bisecada sobre la línea de enlace real
CMake deja la línea literal en `build/CMakeFiles/<target>.dir/link.txt`, y el árbol de post-mortem la
conserva. Rehecha a mano FUERA de takana y del sandbox, sustituyendo el wrapper por el `zig` del lab
y las rutas `/usr/lib/*` por las del store:
tal cual → exit 139 (SIGSEGV)
quitando `-static` → exit 139 ⇒ no es el enlace estático
quitando `--dependency-file` → **exit 0** ⇒ ES ESO
`-Xlinker --dependency-file=…` lo emite CMake ≥3.27 para que el LINKER calcule las dependencias de
enlace, y el `lld` de zig 0.16.0 segfaultea procesándolo. `-DCMAKE_LINK_DEPENDS_USE_LINKER=OFF` es la
palanca de upstream (cmake del corpus: 3.31.6).
**Es mejor que `compiler = "gcc"`**, que es como esquivé ayer el MISMO crash en los tres
`protoc-gen-upb*` de protobuf sin conocer la causa: deja la receta en el toolchain por defecto del
proyecto en vez de escapar de él.
⚠ **Y el alcance no son dos recetas: 153 del corpus usan CMake con zig.** Todas selladas, así que hoy
nadie lo ve — pero el crash depende de los inputs (dentro de protobuf caían 3 de ~10 ejecutables), o
sea que no se sabe cuáles fallan hasta que su hash se mueva. Deuda latente pura.
No se arregla poniendo la perilla en el lab: la mayoría de esas 153 traen su `cmake …` EXPLÍCITO en
la receta, así que tocar la fase por defecto no las tocaría **y** re-hashearía a las que sí usan la
heurística. Incompleto y disruptivo a la vez.
Verificado: los 10 ejecutables estáticos con 0 NEEDED —incluidos `codiff` y `dtagnames`, los dos que
segfaulteaban—, `pahole --version` → v1.30, y REPRODUCE bit a bit.
135 lines
8.9 KiB
TOML
135 lines
8.9 KiB
TOML
# dwarves 1.30 (pahole) — la llave que destraba sched-ext (plan-jaula-juegos T1.2, diferido
|
|
# con causa verificada): en 6.16.12 SCHED_CLASS_EXT depende de DEBUG_INFO_BTF, y generar BTF
|
|
# exige pahole en las build-deps del kernel. Sin esta receta, sched-ext (los schedulers scx
|
|
# de juego: scx_lavd, scx_bpfland) queda fuera del kernel propio para siempre.
|
|
#
|
|
# OJO REPRO: meter pahole en el kernel no es sólo declarar la dep — BTF mete la versión de
|
|
# pahole en el juego de la bit-repro (pahole-skew entre builders cambia el .BTF). El análisis
|
|
# está pendiente en el plan; ESTA receta sólo pone la herramienta en el catálogo para poder
|
|
# hacerlo. El kernel NO la declara todavía.
|
|
#
|
|
# libbpf EMBEBIDO (-DLIBBPF_EMBEDDED=ON, el default del tarball que vendorea libbpf): evita
|
|
# una receta libbpf aparte hoy; si libbpf entra al catálogo por otro frente, se despega.
|
|
#
|
|
# ── 🧱 EL MURO REAL, MEDIDO EN EL WORKER 2026-08-07 (antes se creía que era el rootfs) ──────────
|
|
# Falla en `configure` con:
|
|
# CMake Error at cmake/modules/FindDWARF.cmake:93 (message):
|
|
# Could NOT find some ELF and DWARF libraries, please install the missing packages
|
|
# NO es que falte cmake ni que el rootfs del worker esté flaco: cmake corre perfectamente. Lo que
|
|
# falta es **libdw**. Nuestro artefacto de `elfutils` entrega SÓLO libelf (`libelf.a/.so`, `libelf.h`,
|
|
# `gelf.h`) — sin `libdw`, sin `dwarf.h` — y eso es DELIBERADO: su cabecera dice que libdw/libdwfl
|
|
# arrastran argp/obstack/fts, «lo verdaderamente difícil en musl». Aquella receta existe para el
|
|
# `objtool` del kernel, que sólo necesita libelf.
|
|
#
|
|
# ⚠ Y NO se arregla ampliando `elfutils`: de él cuelgan `linux`, `linux-generic`, `linux-metal` y
|
|
# `linux-metal-dual`, o sea **el kernel que ya reproduce bit a bit**. Tocarlo re-hashea ese baseline
|
|
# validado a cambio de una herramienta que hoy nadie pide. El camino correcto es una receta APARTE
|
|
# —`elfutils-libdw`— igual que el patrón de las sombras `-shared`: deja intacto lo sellado y paga el
|
|
# coste de musl una sola vez, donde se necesita.
|
|
#
|
|
# ⇒ CLASIFICACIÓN HONESTA: esto NO es «una receta en deuda» sino un frente propio, con muro conocido
|
|
# (portar libdw a musl) y sin urgencia: ningún perfil de `targets.toml` pide dwarves, y el kernel
|
|
# desactiva `DEBUG_INFO_BTF` explícitamente «para evitar pahole, ausente del toolchain». Se
|
|
# desbloquea cuando se quiera sched-ext, no antes.
|
|
#
|
|
# BLOQUEADA (intento real en worker 2026-07-17): el cmake no halla libdw/dwarf.h porque el
|
|
# artefacto sellado de elfutils sólo empaqueta LIBELF (headers + .a/.so — lo que kbuild
|
|
# necesita), no libdw. Y elfutils.toml es INTOCABLE: es build-dep de los kernels sellados
|
|
# (linux.toml load-bearing del selfhost-verify). Destrabar = receta variante
|
|
# `elfutils-libdw` (elfutils completo, que en musl arrastra shims argp/fts/obstack — los
|
|
# parches de Alpine) que SÓLO dwarves consuma. Es un sub-proyecto de la cola clib, no un
|
|
# retoque de flags. sha256 del tarball verificado (fedorapeople 2026-07-17).
|
|
|
|
# ── FRENTE libdw/musl, cerrado el 2026-08-27 ───────────────────────────────────────────────────
|
|
# dwarves necesita TRES cosas que musl no da y que el corpus no tenía:
|
|
# · `libdw` + `dwarf.h` → `elfutils-libdw` (variante; la canónica sólo hace libelf porque de ella
|
|
# cuelgan los cuatro kernels y no se le puede mover el hash).
|
|
# · `libargp` → `argp-standalone` (`find_package(argp REQUIRED)` en su CMakeLists).
|
|
# · `libobstack` → `musl-obstack` (`find_package(obstack REQUIRED)`).
|
|
#
|
|
# Los dos `find_package` son REQUIRED y sus `Find*.cmake` hacen `find_library(NAMES argp/obstack)`
|
|
# sobre /usr/lib. En glibc no hacen falta (van dentro de la libc) y por eso el proyecto no los
|
|
# empaqueta; en musl son librerías aparte. Se les pasa la ruta explícita con
|
|
# `-DARGP_LIBRARY=`/`-DOBSTACK_LIBRARY=` para no depender del orden de búsqueda de cmake.
|
|
#
|
|
# `-DCMAKE_C_STANDARD_LIBRARIES='-llzma -lbz2'`: libdw descomprime secciones de debug comprimidas
|
|
# (`.debug_*` en xz/bzip2) y referencia `lzma_code`/`BZ2_bzDecompress`. El `FindDWARF.cmake` de
|
|
# dwarves pone en `DWARF_LIBRARIES` sólo libdw y libelf, así que esas dos no entran por ahí y hay
|
|
# que añadirlas al link de todos los ejecutables. Misma familia de fallo que appstream/cargo-deb.
|
|
#
|
|
name = "dwarves"
|
|
version = "1.30"
|
|
license = "GPL-2.0-only"
|
|
|
|
[source]
|
|
tarball = "https://fedorapeople.org/~acme/dwarves/dwarves-1.30.tar.xz"
|
|
sha256 = "1c89f47dc4f127c4b9d3fb46c8386a40be45c36ef82e8df472418de9423fc5bb"
|
|
|
|
[build]
|
|
compiler = "zig-cc"
|
|
target = "x86_64-linux-musl"
|
|
link = "static"
|
|
|
|
[deps]
|
|
build = ["busybox", "make", "cmake", "elfutils-libdw", "argp-standalone", "musl-obstack", "zlib", "xz", "bzip2"]
|
|
|
|
# `DWARF_LIBRARY`/`ELF_LIBRARY` por ruta `.a` + `CMAKE_EXE_LINKER_FLAGS=-static` (audit 2026-08-31):
|
|
# la receta decía `link = "static"` y los DIEZ ejecutables salían DINÁMICOS contra cinco librerías.
|
|
# Dos causas encadenadas: (1) `FindDWARF.cmake` resuelve libdw/libelf con `find_library`, que
|
|
# prefiere `.so` — y `elfutils-libdw` empaqueta libelf en las dos formas — así que metía
|
|
# `/usr/lib/libelf.so` en la línea de enlace, y ante un `.so` en la línea el wrapper del lab TIRA el
|
|
# `-static` inyectado (`sandbox.rs:597`); (2) sin `-static`, `-lz`/`-llzma`/`-lbz2` resolvían a las
|
|
# `.so` DEL ROOTFS de Alpine y no a los artefactos de `zlib`/`xz`/`bzip2` —que sólo traen `.a`—:
|
|
# tres entradas no declaradas.
|
|
#
|
|
# ⚠ `-DCMAKE_FIND_LIBRARY_SUFFIXES=.a` NO sirve y se probó: `Platform/Linux.cmake` lo asigna como
|
|
# variable NORMAL al correr `project()`, y una normal TAPA a la del caché ⇒ el `-D` es inerte. La
|
|
# palanca que sí funciona es la que esta misma receta ya usa para argp/obstack: dar la ruta `.a`
|
|
# explícita a cada variable que el `Find*.cmake` correspondiente consulta.
|
|
#
|
|
# Y son TRES, no dos: `find_package(ZLIB REQUIRED)` (CMakeLists:52) metía `/usr/lib/libz.so` —la
|
|
# del ROOTFS— en la línea, y con eso basta para que el wrapper tire el `-static` aunque libdw y
|
|
# libelf ya fueran `.a`. Se vio leyendo `build/CMakeFiles/pahole.dir/link.txt`, que es donde cmake
|
|
# deja la línea de enlace literal: **el `-static` estaba puesto y lo quitaban después**. Ése es el
|
|
# sitio donde mirar la próxima vez que `link = "static"` no pegue en un proyecto cmake.
|
|
#
|
|
# Esto NO es cosmético: el día que se encienda `DEBUG_INFO_BTF` (SDD 25 H7), pahole corre DENTRO
|
|
# del sandbox del build del kernel, y un pahole dinámico fallaría ahí diciendo que no está.
|
|
[build.phases]
|
|
# ⚠ **`CMAKE_LINK_DEPENDS_USE_LINKER=OFF`: EL LINKER DE ZIG SE CAE CON `--dependency-file`.**
|
|
#
|
|
# Esta receta estaba SELLADA y llevaba tiempo sin construir. Se destapó el 2026-09-12 al arreglar los
|
|
# symlinks de `bzip2`: su hash se movió, dwarves cayó a deuda, y al reconstruirla:
|
|
#
|
|
# [ 71%] Linking C executable codiff
|
|
# Error running link command: Segmentation fault
|
|
#
|
|
# **No lo rompió el cambio de bzip2 y se puede probar**: el `libbz2.a` y el `bzlib.h` nuevos son
|
|
# byte-idénticos a los viejos (`cmp -s`); lo único que cambió fueron cuatro destinos de symlink. El
|
|
# artefacto sellado tapaba una rotura que ya existía — el lab rueda desde Alpine edge y zig subió.
|
|
#
|
|
# **La causa se aisló bisecando la línea de enlace**, no suponiendo. Con el `link.txt` que cmake deja
|
|
# en `build/CMakeFiles/codiff.dir/`, rehecho a mano FUERA de takana y del sandbox:
|
|
#
|
|
# tal cual → exit 139 (SIGSEGV)
|
|
# quitando `-static` → exit 139 ⇒ no es el enlace estático
|
|
# quitando `--dependency-file` → **exit 0** ⇒ ES ESO
|
|
#
|
|
# `-Xlinker --dependency-file=…` lo emite CMake ≥3.27 para que el LINKER calcule las dependencias de
|
|
# enlace, y el `lld` de zig 0.16.0 **segfaultea** al procesarlo. `CMAKE_LINK_DEPENDS_USE_LINKER=OFF`
|
|
# es la palanca que upstream expone justo para apagarlo (cmake del corpus: 3.31.6 ⇒ la soporta).
|
|
#
|
|
# ⚠ **Y NO ES UN PROBLEMA DE DWARVES**: es de *cualquier* proyecto CMake construido con zig en este
|
|
# corpus. El mismo crash mató a los tres `protoc-gen-upb*` de protobuf el día anterior, y allá se
|
|
# esquivó con `compiler = "gcc"` sin conocer la causa. Ésta es la causa, y el arreglo bueno — porque
|
|
# deja la receta en el toolchain por defecto del proyecto en vez de escapar del él.
|
|
configure = """
|
|
cmake -B build -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr -D__LIB=lib \
|
|
-DCMAKE_LINK_DEPENDS_USE_LINKER=OFF \
|
|
-DBUILD_SHARED_LIBS=OFF -DLIBBPF_EMBEDDED=ON \
|
|
-DARGP_LIBRARY=/usr/lib/libargp.a -DOBSTACK_LIBRARY=/usr/lib/libobstack.a -DCMAKE_C_STANDARD_LIBRARIES='-llzma -lbz2' -DCMAKE_C_FLAGS='-O2 -fno-sanitize=undefined' \
|
|
-DDWARF_LIBRARY=/usr/lib/libdw.a -DELF_LIBRARY=/usr/lib/libelf.a -DZLIB_LIBRARY=/usr/lib/libz.a -DCMAKE_EXE_LINKER_FLAGS='-static'
|
|
"""
|
|
compile = "make -C build -j\"$(nproc)\""
|
|
install = "make -C build install DESTDIR=/out"
|