lld21: dinámico y con zlib — dos fallos que sólo se ven USÁNDOLO

El primer `lld21` selló, arrancó y se moría en cuanto hacía algo: `--version` y `--help` contestaban
bien, y CUALQUIER enlace —incluso uno que sólo debía dar un error, como un fichero de entrada
inexistente— terminaba en SIGSEGV con el banner de LLVM y un «Stack dump:» vacío.

🧨 Y no era culpa de esta receta: **las 79 herramientas que publica `llvm21` tienen el mismo defecto**
—`llc --version` también crashea, y también en el worker— porque salen `static-pie` y el enlace
estático descarta los constructores globales de los que dependen los registros de LLVM
(`cl::opt`, `TargetRegistry`). Lo que funciona es lo que no los necesita (`llvm-ar`, `llvm-config`),
y por eso nadie lo había visto: `rust` usa `llvm-config` y las `.a`, nunca una herramienta.
⇒ `link = "dynamic"` en esta receta (como `openssl-threads`, y por lo mismo: el flag global decide
cosas que la receta no dice). Control en los dos sentidos: con `static`, SIGSEGV; con `dynamic`,
`ld.lld: error: cannot open /no/existe.o: No such file or directory` — un error limpio.

Y el segundo, ya enlazando de verdad con nuestro rustc:

    lld: error: …/self-contained/crtn.o:(.debug_line) is compressed with ELFCOMPRESS_ZLIB,
         but lld is not built with zlib support

Los objetos `crt*` del sysroot de rust llevan las secciones de depuración COMPRIMIDAS. Para `llvm21`
apagar zlib era gratis; para el ENLAZADOR no lo es. ⇒ `-DLLVM_ENABLE_ZLIB` encendido y `zlib` a las
deps — copiar los flags del hermano sin preguntarse qué hace cada uno es lo que lo causó.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

recipes/lld21.toml

@@ -34,15 +34,33 @@ sha256  = "1a417d1c8faf8d93e73fec1cbb76d393ed3218974c2283c7bac9672d3d47c54b"
 [build]
 compiler = "zig-cc"
 target   = "x86_64-linux-musl"
-link     = "static"
+# ⚠ `dynamic` NO es una preferencia: con `static` el binario SELLA, arranca y **se muere en cuanto
+# hace algo** (medido 2026-09-16). `ld.lld --version` y `--help` contestan bien; cualquier enlace
+# —incluso uno que sólo debería dar un error, como un fichero de entrada inexistente— termina en
+# SIGSEGV con el banner de LLVM y un «Stack dump:» vacío. La firma es la de los registros estáticos
+# de LLVM: `cl::opt`, `TargetRegistry` y compañía se inicializan desde constructores globales que
+# viven en objetos de las `.a`, y un enlace estático agresivo los DESCARTA por no estar
+# referenciados — lo que funciona es lo que no los necesita (`--version`), y lo que no, revienta.
+# Es la misma familia que `link-static-mentira-libtool`: el flag global de la receta decide cosas
+# que la receta no dice.
+link     = "dynamic"
 strip_debug = true
 
 [deps]
 # `llvm21` NO es un adorno: el build standalone de lld necesita su `lib/cmake/llvm/LLVMConfig.cmake`
 # y sus `.a`. Es la misma dep que el paso `Lld` del bootstrap de rustc habría usado.
-build = ["llvm21", "cmake", "samurai", "python3", "pkgconf"]
+build = ["llvm21", "cmake", "samurai", "python3", "pkgconf", "zlib"]
 
 [build.phases]
+# ⚠ `LLVM_ENABLE_ZLIB` va ENCENDIDO —al revés que en `llvm21`— y lo decidió un error, no el gusto:
+#
+#     lld: error: …/self-contained/crtn.o:(.debug_line) is compressed with ELFCOMPRESS_ZLIB,
+#          but lld is not built with zlib support
+#
+# Los objetos `crt*` que rust trae en su sysroot llevan las secciones de depuración COMPRIMIDAS, así
+# que un enlazador sin zlib no puede ni leerlos. Para `llvm21` apagarlo era gratis; para el
+# ENLAZADOR no lo es.
+#
 # `g++` con los runtimes estáticos, igual que `llvm21` y `cmake`: C++ a escala con zig sigue siendo
 # terreno minado, y además LLD tiene que casar ABI con el LLVM contra el que enlaza — que se
 # construyó exactamente así.
@@ -53,7 +71,6 @@ cmake -S lld -B build -G Ninja \
   -DCMAKE_INSTALL_PREFIX=/usr \
   -DLLVM_DIR=/usr/lib/cmake/llvm \
   -DLLVM_INCLUDE_TESTS=OFF \
-  -DLLVM_ENABLE_ZLIB=OFF \
   -DLLVM_ENABLE_ZSTD=OFF \
   -DLLVM_ENABLE_LIBXML2=OFF
 '''