luna-runtime-helpers — the static-link runtime entry for the
binaries that luna-aot produces.
Role in the v1.3 Phase AOT pipeline
luna-aot compile foo.lua --out foo walks:
- Parse + compile
foo.luato a luna bytecode dump (Stages 1-2). - Emit a
.luna.bytecodedata section in a fresh.o(Stage 5). - Build this crate as a
staticlib—libluna_runtime_helpers.abundles the rust stdlib + luna-core + this thin C-ABI entry. - Emit a tiny C
mainthat calls into [luna_aot_run] passing the bracket-symbol bounds of the bytecode section (Stage 6). cclinksbytecode.o+main.o+libluna_runtime_helpers.a-lpthread -ldl -lminto the final executable.
The produced binary at run time:
- the C
maincalls [luna_aot_run(bytecode_ptr, len)][luna_aot_run] - [
luna_aot_run] constructs aVm, allows bytecode loading, callsVm::load(slice, b"=embedded")(which routes throughluna_core::vm::dump::undumpbecause the slice starts with\x1bLua), thenVm::call_valueon the resulting root closure - normal
print(...)from the script lands on stdout viastd::io::stdoutinside luna-core's builtins (no surprises) - exit code 0 on success, 1 on load / runtime error
Why a separate crate (not folded into luna-aot)
luna-aot is the build-time tool — it pulls object + clap
and eventually all of cranelift. The deploy-side binary must
not pull cranelift; it only needs the luna interp. Splitting this
entry into its own crate keeps the deploy-side .a tight (rust
stdlib + luna-core only) and lets luna-aot invoke
cargo build -p luna-runtime-helpers --release without dragging
its own dep tree into the link.
luna-core 0-third-party-dep contract
Unchanged. cargo tree -p luna-core --prefix none | grep -cE " v[0-9]"
continues to report 1. This crate sits above luna-core in the
dep graph; nothing here flows back into luna-core.