# 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] configure = """ cmake -B build -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr -D__LIB=lib \ -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"