Application Binary Interface

lua-users home

An [application Binary Interface (ABI)] is the interface between functions on a binary level. ABI compatibility in Lua typically means that a binary module compiled with one instance of Lua works in another instance of Lua without the need to recompile anything.

"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).

RecentChanges · preferences
edit · history
Last edited October 15, 2011 11:03 pm GMT (diff)