sergio/takana

1# LuaJIT 2.1 (rolling) — el TERCER intérprete Lua del catálogo, y hay razón para cada uno.
2#
3# ══ POR QUÉ TRES LUA ═══════════════════════════════════════════════════════════════════════════
4# `lua` 5.4.8 entró para wireplumber (su política está escrita en Lua). `lua5.2` entró para el OSC
5# de mpv, que sólo acepta 5.1/5.2/LuaJIT. Ésta entra porque hay consumidores que piden **LuaJIT por
6# nombre y no aceptan otra cosa**: `swayimg` ≥5.0 hace `dependency('luajit')` sin alternativa, y mpv
7# la prefiere sobre 5.2 (es la implementación que upstream prueba). No son la misma ABI ni de lejos:
8# LuaJIT es Lua 5.1 + FFI + JIT.
9#
10# ══ CÓMO CONVIVE SIN PISAR A LAS OTRAS DOS ═════════════════════════════════════════════════════
11# Sus rutas ya vienen versionadas de fábrica y no chocan con ninguna de las otras dos:
12# headers en `/usr/include/luajit-2.1/`, `libluajit-5.1.so.2`, `luajit.pc`, y el binario
13# `/usr/bin/luajit-2.1.<relver>` con el symlink `/usr/bin/luajit`. Ningún fichero se llama `lua`.
14#
15# ══ ⚠ EL PIN DE VERSIÓN NO ALCANZA: LuaJIT SE VERSIONA SOLO, DESDE `git` ═══════════════════════
16# Desde que 2.1 pasó a «rolling» no hay tags: la versión la saca del árbol. `src/Makefile:495` hace
17#
18#     [ -e ../.git ] && git show -s --format=%ct >luajit_relver.txt || cat ../.relver >...
19#
20# y `src/host/genversion.lua` sustituye ese número dentro de `luajit_rolling.h`. **Eso no es
21# cosmético: entra en un SÍMBOLO EXPORTADO** — `LUAJIT_VERSION_SYM` es `luaJIT_version_2_1_ROLLING`
22# con ROLLING reemplazado. O sea que dos builds del mismo commit con distinto estado de `.git`
23# publican símbolos con nombres distintos, y un consumidor compilado contra un header y ligado
24# contra la otra librería muere con símbolo indefinido. Peor que un hash que no reproduce: rompe.
25#
26# ARREGLO, y por eso son DOS pasos y no uno: se escribe `.relver` a mano con el `%ct` del commit
27# pineado (1787165859 = 2026-08-19T18:57:39Z) **y** se borra `.git`, porque la rama del `&&` que
28# consulta git GANA si el directorio existe. Con `.relver` sólo, un fetch que dejara `.git` volvería
29# a mandar. Misma familia que el `-Dbuild-date` de mpv y el `-Dversion` de swayimg — la perilla que
30# hay que buscar en toda app nueva, con el agravante de que acá afecta al enlazado.
31#
32# ══ TARGET_STRIP=true, A PROPÓSITO ═════════════════════════════════════════════════════════════
33# El Makefile corre `$(CROSS)strip` sobre el binario y la `.so` como parte de la COMPILACIÓN
34# (src/Makefile:749,754). Dos problemas: `strip` es de binutils y el lab no lo trae salvo que la
35# receta lo pida, y además borra el `.debug_*` antes de que takana pueda partirlo (SDD 23). Se
36# neutraliza con el no-op `true` en vez de sumar una dep para destruir información.
37#
38# ══ `-Wl,-E` EN Libs.private, QUE ES UNA TRAMPA CONOCIDA DE ESTE REPO ══════════════════════════
39# LuaJIT liga su binario con `-Wl,-E` (--export-dynamic) para que el FFI vea los símbolos del
40# ejecutable, y lo propaga en `Libs.private` de su `.pc`. El wrapper de zig de este repo tiene una
41# regla que QUITA `-static` cuando ve `--export-dynamic`: un consumidor que pida luajit con
42# `prefer_static` va a dejar de ser estático sin avisar. No es un bug de esta receta —es el
43# comportamiento correcto, `-E` y `-static` no se llevan— pero es exactamente el tipo de cosa que
44# se descubre seis meses después. Queda escrita acá.
45#
46# ══ `LIBS=-lunwind`: LA MISMA DEUDA DEL UNWINDER QUE YA PAGA librsvg ═══════════════════════════
47# Sin esto el link muere con NUEVE símbolos indefinidos —`_Unwind_RaiseException`, `_Unwind_SetGR`,
48# `__register_frame`…— todos desde `lj_err.o`. **No es un fallo de LuaJIT ni del pin**: es que su
49# manejo de errores usa unwinding DWARF de verdad (`LUAJIT_UNWIND_EXTERNAL`, que su propio Makefile
50# se activa solo al detectar que el compilador emite `.eh_frame`), y en glibc ese runtime vive en
51# `libgcc_s`, que musl no tiene. zig empaqueta la libunwind de LLVM y exporta esos símbolos.
52# Va por `LIBS=` y no por `LDFLAGS=` porque `TARGET_ALIBS= $(TARGET_XLIBS) $(LIBS) $(TARGET_LIBS)`
53# se expande DESPUÉS de los objetos en la línea de link (src/Makefile:748,753), que es donde el
54# linker resuelve; en `LDFLAGS` iría antes y no resolvería nada. Cubre las dos ligaduras, la del
55# ejecutable y la de la `.so`.
56#
57# Sin CROSS: el sandbox es x86_64 y el target también, así que HOST_CC = TARGET_CC y no hace falta
58# el modo cross de LuaJIT (que necesitaría un segundo compilador para `minilua`/`buildvm`).
59name    = "luajit"
60version = "2.1.1787165859"
61license = "MIT"
62
63[source]
64repo   = "https://github.com/LuaJIT/LuaJIT.git"
65commit = "1ee778a4e37122d8ca7d5733c590a47dafd6b15c"
66
67[build]
68compiler = "zig-cc"
69target   = "x86_64-linux-musl"
70link     = "dynamic"
71
72[build.phases]
73configure = '''
74set -e
75# Ver la cabecera: los DOS pasos hacen falta, `.relver` solo no alcanza si `.git` sobrevive al fetch.
76rm -rf .git
77echo 1787165859 > .relver
78'''
79compile = '''
80set -e
81make PREFIX=/usr CC="hammer-zig-cc" TARGET_STRIP=true LIBS=-lunwind
82'''
83install = '''
84set -e
85make install PREFIX=/usr DESTDIR=/out CC="hammer-zig-cc" TARGET_STRIP=true LIBS=-lunwind
86'''
87
88[deps]
89build = ["make", "pkgconf"]