Sergio
f0614f679e
mold b3:9ce9fe3194982cc2b28d0fa547b037d7d36dae773fbd033ad252d7f11cb92dd2
wireguard-tools b3:086d0837e30e8a7a5e05c61c2df47987c2574645c03226e0020f35635ba8ba41
Los dos sellaban, reproducían y NO CORRÍAN. Se descubrió ejecutando el binario; ni el sellado, ni
`takana hash`, ni la reproducibilidad lo veían.
mold — dos causas independientes, las dos leídas en su CMakeLists.txt:
1. `:149` — `if(ZLIB_FOUND AND NOT MOLD_MOSTLY_STATIC)` enlaza la zlib COMPARTIDA del sistema
(ídem zstd `:179` y blake3 `:161`). El binario salía pidiendo `libz.so.1`/`libzstd.so.1`, que
el corpus no publica (`zlib` canónica es `.a`), y al correrlo tomaba la del anfitrión:
`Error relocating /lib/libz.so.1: __snprintf_chk: symbol not found` — símbolo de
_FORTIFY_SOURCE de glibc que musl no tiene. `-DMOLD_MOSTLY_STATIC=ON` usa las que trae en tree.
2. El `LDFLAGS=-static` que el lab exporta para `link = "static"` NO llegaba a la línea de enlace
de CMake ⇒ hace falta `-DCMAKE_EXE_LINKER_FLAGS=-static` explícito.
Ahora: `statically linked`, y `mold --version` contesta 2.42.1.
Y antes de eso, otro defecto que tampoco fallaba: el primer sello pesaba 629 MB, de los cuales
628 eran UN SOLO FICHERO — /usr/bin/mold con el DWARF adentro, que CMAKE_BUILD_TYPE=Release no
quita. Con `strip_debug = true` (SDD 23) quedó en 41 MB. Un artefacto obeso no rompe nada: entra
en el store, en la imagen y en el respaldo, y nadie mira el tamaño.
wireguard-tools — acá el error era del razonamiento, y el artefacto lo desmintió. La receta iba
`link = "dynamic"` con [deps] build=["libmnl"] argumentando «wg enlaza libmnl y no hay libmnl.a en
el store». `readelf -d wg` da UN solo NEEDED, `libc.so`, y los `mnl_*` están definidos adentro.
La razón está en la fuente, `src/netlink.h:1`:
/* This is a minimized version of libmnl meant to be #include'd */
Upstream embebe el subconjunto que usa para no arrastrar la dependencia. Pasa a `link = "static"`
y pierde la dep: declarar una que no se usa ata esta receta al hash de otra y haría que un rebuild
de libmnl la re-selle para nada.
REGLA, escrita en las dos recetas: `link = "static"` es una DECLARACIÓN. Lo único que la comprueba
es `readelf -d` sobre el artefacto, o correrlo.
62 lines
3.8 KiB
TOML
62 lines
3.8 KiB
TOML
# mold 2.42.1 — enlazador paralelo. C++20, CMake.
|
|
#
|
|
# ── POR QUÉ ENTRA, Y ES DISTINTO DEL RESTO DE ESTA TANDA ──────────────────────────────────────
|
|
# Las otras recetas de la tanda son para el usuario del producto; ésta es para quien CONSTRUYE con
|
|
# él. El catálogo trae `sccache` (cachear compilaciones) y no tenía con qué acelerar el enlace, que
|
|
# es justo la fase serial de un build grande. No reemplaza al lld de zig que usa el lab: entra como
|
|
# herramienta del userland, no del sandbox.
|
|
#
|
|
# ── `-DCMAKE_LINK_DEPENDS_USE_LINKER=OFF`, Y NO ES OPCIONAL ───────────────────────────────────
|
|
# El lld que trae zig SEGFAULTEA cuando CMake le pasa `--dependency-file` (CMake ≥3.31 lo hace de
|
|
# fábrica para calcular dependencias de enlace). Ya está medido en este repo: de 15 recetas CMake
|
|
# barridas, 5 NO construían por esto. Una línea lo evita.
|
|
#
|
|
# `-DMOLD_USE_SYSTEM_TBB=OFF` y mimalloc: mold trae sus dependencias en `third-party/` y prefiere
|
|
# las suyas; el corpus no tiene ni tbb ni mimalloc, así que usar las de upstream no es una
|
|
# concesión sino la única vía sin escribir dos recetas más.
|
|
name = "mold"
|
|
version = "2.42.1"
|
|
license = "MIT"
|
|
|
|
[source]
|
|
repo = "https://github.com/rui314/mold"
|
|
commit = "9b376bc6a9899d4a16b41777de1f013989459fbc"
|
|
|
|
[build]
|
|
compiler = "zig-cc"
|
|
target = "x86_64-linux-musl"
|
|
link = "static"
|
|
|
|
# ⚠ `strip_debug` NO ES COSMÉTICA ACÁ, Y ESTÁ MEDIDA. El primer sello de esta receta dio un
|
|
# artefacto de **629 MB, de los cuales 628 son UN SOLO FICHERO**: `/usr/bin/mold` con la info de
|
|
# depuración adentro. Un enlazador pesa ~8 MB pelado; el resto es DWARF de un C++20 grande
|
|
# compilado con `-g`, que `CMAKE_BUILD_TYPE=Release` no quita. Sellar eso no rompe nada —el binario
|
|
# funciona— y por eso es el modo de fallo caro: entra en el store, entra en la imagen, entra en el
|
|
# respaldo, y nadie mira el tamaño. Split SDD 23 (entra en `hash_inputs`; obliga a `binutils`).
|
|
strip_debug = true
|
|
|
|
[build.phases]
|
|
# ⚠ `MOLD_MOSTLY_STATIC=ON` + `-static` EXPLÍCITO — LOS DOS, Y SE APRENDIÓ CORRIENDO EL BINARIO.
|
|
# El primer sello llevaba `link = "static"` y salió **dinámico**: `NEEDED libz.so.1 libzstd.so.1
|
|
# libc.so`, con intérprete. Al ejecutarlo:
|
|
# Error relocating /lib/libz.so.1: __snprintf_chk: symbol not found
|
|
# …que es la zlib de glibc DEL ANFITRIÓN resolviendo símbolos de `_FORTIFY_SOURCE` que musl no
|
|
# tiene. O sea el cuadro completo de la casa: **selló, reprodujo y NO CORRÍA**. Dos causas
|
|
# independientes, y hacen falta las dos perillas:
|
|
# 1. `CMakeLists.txt:149` — `if(ZLIB_FOUND AND NOT MOLD_MOSTLY_STATIC)` enlaza la zlib
|
|
# COMPARTIDA del sistema; con MOSTLY_STATIC usa la `zlibstatic` que trae en tree (ídem
|
|
# zstd y blake3, líneas 161 y 179). Sin esto el binario pide sonames que el corpus no
|
|
# publica: `zlib` canónica es `.a`.
|
|
# 2. `-DCMAKE_EXE_LINKER_FLAGS=-static` — el `LDFLAGS=-static` que el lab exporta para
|
|
# `link = "static"` NO llegó a la línea de enlace de CMake. Declararlo es lo que hace
|
|
# que `link = "static"` sea verdad y no una etiqueta.
|
|
#
|
|
# Moraleja para la próxima receta CMake: `link = "static"` es una DECLARACIÓN, no una
|
|
# comprobación. Lo único que la comprueba es `readelf -d` sobre el artefacto — o correrlo.
|
|
configure = 'cmake -S . -B _build -G Ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_LINK_DEPENDS_USE_LINKER=OFF -DCMAKE_EXE_LINKER_FLAGS=-static -DMOLD_MOSTLY_STATIC=ON -DMOLD_USE_SYSTEM_TBB=OFF -DBUILD_TESTING=OFF'
|
|
compile = 'cmake --build _build'
|
|
install = 'DESTDIR=/out cmake --install _build'
|
|
|
|
[deps]
|
|
build = ["cmake", "samurai", "zlib", "zstd", "openssl", "pkgconf", "binutils"]
|