gioser

sergio/takana

> Una distribución Linux construida con un laboratorio funcional y hermético en el > sótano, y una terminal mutable, clásica y anárquica en el piso de arriba — diseñada > desde el suelo para que una IA programadora entienda, modifique y co…

TOML 1572Shell 203Rust 109Markdown 993728 Definiciones

⎇ 64005efcbd7f4aa6d6f2ab9d3a6fec8ec1bc30d4 recipes/llvm21.toml TOML · 91 líneas · 4.8 KB Historia crudo

llvm21: `dynamic` y con zlib — las 79 herramientas dejan de crashear, y rust se rehace detrás bad2b1c63 · Sergio ·

1# LLVM 21.1.2 — el LLVM que `rustc` necesita. NO es un duplicado de `llvm18`: son para dos cosas
2# distintas y ninguna sirve para la otra.
3#
4# ══ POR QUÉ 21 Y NO EL 18 QUE YA ESTÁ SELLADO ══════════════════════════════════════════════════
5# El plan era «rustc desde fuente con el llvm18 del corpus». Medido en el propio bootstrap de rustc
6# (`src/bootstrap/src/core/build_steps/llvm.rs`), el mínimo por versión es:
7#
8#     rustc 1.87 → LLVM ≥18   ·   1.90 → ≥19   ·   1.93/1.95 → ≥20   ·   **1.97 → ≥21**
9#
10#     panic!("\n\nbad LLVM version: {version}, need >=21\n\n")
11#
12# El lab —y por tanto todo lo que construimos— está en **rust 1.97.0**, así que con `llvm18` sólo se
13# podría construir `rustc 1.87`… que a su vez no se puede bootstrapear con lo que tenemos. La salida
14# no es bajar de rustc: es subir de LLVM.
15#
16# `llvm18` se queda donde está: lo usa `mesa-llvmpipe` y mesa 24.0.9 **no soporta** LLVM 21. Dos
17# consumidores con rangos incompatibles ⇒ dos artefactos. No es deuda, es la realidad de los rangos.
18#
19# ══ DIFERENCIAS DE BUILD FRENTE A `llvm18`, Y SON A PROPÓSITO ══════════════════════════════════
20# · **Sin DYLIB.** `llvm18` construye `libLLVM.so` porque mesa la enlaza. rustc quiere las estáticas
21#   y su `llvm-config`; y el link del dylib es lo que pide MUCHA RAM (la receta de llvm18 anota
22#   «worker GORDO» por eso). Sin él, el pico baja y entra en el worker de 6 núcleos y 16 G.
23# · **RTTI ON** (rustc lo exige) y sólo el target **X86**: nada de compilar los 20 backends.
24name    = "llvm21"
25version = "21.1.2"
26license = "Apache-2.0 WITH LLVM-exception"
27
28[source]
29tarball = "https://github.com/llvm/llvm-project/releases/download/llvmorg-21.1.2/llvm-project-21.1.2.src.tar.xz"
30sha256  = "1a417d1c8faf8d93e73fec1cbb76d393ed3218974c2283c7bac9672d3d47c54b"
31
32[build]
33compiler = "zig-cc"
34target   = "x86_64-linux-musl"
35# ⚠⚠ `dynamic`, y no es preferencia: con `static` **las 79 herramientas que publica este artefacto
36# CRASHEAN** (medido 2026-09-16, y también en el worker, o sea que es el build y no el entorno):
37#
38#     $ llc --version
39#     PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ …
40#     Stack dump:            ← y segfault, con el volcado vacío
41#
42# Salen `static-pie`, y el enlace estático descarta los constructores globales de los que dependen
43# los registros de LLVM (`cl::opt`, `TargetRegistry`): funciona lo que no los necesita (`llvm-ar`,
44# `llvm-config`) y revienta lo que sí. **No se notó durante meses porque el único consumidor, `rust`,
45# usa `llvm-config` y las `.a` — nunca una herramienta.** Lo destapó construir `lld21`, que enlaza
46# contra estas mismas librerías: estático crasheaba con cualquier entrada, dinámico da errores
47# limpios. Es la misma familia que `link-static-mentira-libtool` y que el openssl sin threads: **el
48# flag global de la receta decide cosas que la receta no dice**.
49#
50# Las `.a` que consume `rust` no cambian de contenido —el flag sólo quita el `-static` del enlace de
51# los EJECUTABLES—, pero `link` sí entra en `hash_inputs`, así que esto re-sella `llvm21` y con él
52# `rust`. Es el precio de tener herramientas que funcionan.
53link     = "dynamic"
54flags    = []
55
56[deps]
57# Mismas deps que `llvm18`: `samurai` es el ninja del corpus (nombre distinto, mismo programa) y
58# `pkgconf` lo pide el configure de cmake.
59# ⚠ `zlib` NO es un extra: sin él, el `lld` que se construye contra este LLVM hereda
60# `LLVM_ENABLE_ZLIB 0` de `LLVMConfig.cmake` y no puede leer las secciones de depuración COMPRIMIDAS
61# que trae la libc del lab —«is compressed with ELFCOMPRESS_ZLIB, but lld is not built with zlib
62# support»—, o sea que no puede enlazar nada real. Encenderlo acá es la única vía: el build
63# standalone de lld no puede contradecir a su LLVM.
64build = ["cmake", "samurai", "python3", "pkgconf", "zlib"]
65
66[build.phases]
67# `g++` del sandbox con `-static-libstdc++ -static-libgcc`, igual que `llvm18` y `cmake`: C++ a
68# escala con zig sigue siendo terreno minado (ver el runtime de C++ que tiene que COINCIDIR).
69configure = '''
70CC=gcc CXX='g++ -static-libstdc++ -static-libgcc' \
71cmake -S llvm -B build -G Ninja \
72  -DCMAKE_BUILD_TYPE=Release \
73  -DCMAKE_INSTALL_PREFIX=/usr \
74  -DLLVM_TARGETS_TO_BUILD=X86 \
75  -DLLVM_BUILD_LLVM_DYLIB=OFF \
76  -DLLVM_LINK_LLVM_DYLIB=OFF \
77  -DLLVM_ENABLE_RTTI=ON \
78  -DLLVM_ENABLE_PROJECTS="" \
79  -DLLVM_ENABLE_TERMINFO=OFF \
80  -DLLVM_ENABLE_ZLIB=ON \
81  -DLLVM_ENABLE_ZSTD=OFF \
82  -DLLVM_ENABLE_LIBXML2=OFF \
83  -DLLVM_ENABLE_LIBEDIT=OFF \
84  -DLLVM_ENABLE_BINDINGS=OFF \
85  -DLLVM_INCLUDE_TESTS=OFF \
86  -DLLVM_INCLUDE_EXAMPLES=OFF \
87  -DLLVM_INCLUDE_BENCHMARKS=OFF \
88  -DLLVM_INCLUDE_DOCS=OFF
89'''
90compile = "ninja -C build"
91install = "DESTDIR=/out ninja -C build install"