Application Binary Interface
 |
||
|
Application Binary Interface |
|
"Usually new Lua versions [i.e. 4.0, 5.0, 5.1, 5.2, etc.] break the ABI in several other ways..." [4] However, Lua x.y.z releases are ABI compatible with x.y.w releases [5].
Concering LuaJit, "LuaJIT is also fully ABI-compatible to Lua 5.1 at the linker/dynamic loader level. This means you can compile a C module against the standard Lua headers and load the same shared library from either Lua or LuaJIT." [1]
Some compile-time settings in luaconf.h (e.g. LUA_COMPAT) can affect ABI compatibility.
LuaList:2011-06/msg00979.html has a discussion regarding ABI compatibility / opaque structures in 5.2 and LuaJit.
Related topics include how binary modules link to a C runtime library (e.g. msvcrt.dll or msvcr100.dll), how the Lua library is linked (e.g. statically, dynamically or via LuaProxyDll), and how the Lua library is named (e.g. lua51.dll or otherwise). See BuildingModules. How binary modules find other binary modules (e.g. see LoadLibrary) also affects whether using an ABI will be successful.
Inconsistent FPU state [2] has sometimes caused ABI problems.
Some efforts on ABI standardization in Lua have been done by LuaBinaries [3], LuaForWindows?, and LuaDist (partly predetermined by CMake conventions).
