Application Binary Interface
This section documents the platform-specific conventions used by
LuaCheia binaries. The goals of this chapter are to educational, and
also to promote interoperability between LuaCheia and other Lua-based
projects.
Basics
The Lua core is designed to be flexible and easy to embed, so it can
be compiled in a variety of different ways. It can be embedded
directly in another application, it can be built as a single
stand-alone executable, it can be built as one or more static or
shared libraries, it can be built as shared libaries plus a small
interpreter shell, etc.
LuaCheia adopts the fairly common convention that the Lua core will be
built as a small interpreter shell, plus two shared libraries:
|
lua executable |
this is the standard Lua interpreter shell |
|
liblua |
this is the Lua VM and runtime, built as a shared library |
|
liblualib |
this is the set of Lua base libraries, built as a shared library |
|
binary modules |
these are shared libraries that can be loaded dynamically |
|
Each of these components has different binary formats and naming
conventions on different platforms. The sections below give details
for several common platforms. (If your platform is not listed here,
it may well still be supported by LuaCheia, if your platform is
supported by autotools and libtool.)
Windows
|
lua executable ‐‐ lua5.exe |
Standard Windows console .exe, built
from lua.c in the Lua core. Imports KERNEL32.dll, msvcrt.dll,
liblua-5.dll, and liblualib-5.dll |
|
liblua ‐‐ liblua-5.dll |
Standard liblua DLL, built from the Lua
core; imports KERNEL32.dll and msvcrt.dll, calling convention of Lua
API is __declspec(dllexport) |
|
liblualib ‐‐ liblualib-5.dll |
Standard liblualib DLL, built from
the Lua core; imports KERNEL32.dll, msvcrt.dll and liblua-5.dll,
calling convention of Lua library API is __declspec(dllexport) |
|
binary modules ‐‐ various, of the form luacheia5/lua*.dll |
Windows
DLL's, linked to liblua-5.dll, liblualib-5.dll and msvcrt.dll, plus
possibly other module-specific DLL's. The entry point for intializing
the module can be any exported function with signature
"__declspec(dllexport) int some_function_name(lua_State* L)". If in
doubt when choosing a function name for the initializer, we suggest
luaLM_import (from the Binary Modules convention). LuaCheia uses Lua
stub loaders for each module, though, so the name of the C initializer
can vary from module to module. |
|
Linux
Details below may also apply to other Posix systems.
|
lua executable ‐‐ bin/lua5 |
Standard Lua shell interpreter,
possibly linked with libreadline or similar. Links to liblua.so.5 and
liblualib.so.5, plus standard C and system libraries. |
|
liblua ‐‐ lib/liblua.so ‐‐> liblua.so.5 ‐‐> liblua.so.5.0.0 |
ELF shared object, links to standard C runtime and system libraries. |
|
liblualib ‐‐ lib/liblualib.so ‐‐> liblualib.so.5 ‐‐> liblualib.so.5.0.0 |
ELF shared object, links to liblua.so.5 plus standard C runtime and system libraries. |
|
binary modules ‐‐ various, of the form lib/luacheia5/lua*.so |
ELF
shared objects, linked to liblua.so.5, liblualib.so.5 and C libraries,
plus possibly other module-specific libraries. The entry point for
intializing the module can be any exported function with signature
"int some_function_name(lua_State* L)". If in doubt when choosing a
function name for the initializer, we suggest luaLM_import (from the
Binary Modules convention). LuaCheia uses Lua stub loaders for each
module, though, so the name of the C initializer can vary from module
to module. |
|
Mac OSX / Darwin
|
lua executable ‐‐ bin/lua5 |
@@ TODO |
|
liblua ‐‐ lib/liblua.dylib ‐> liblua.5.dylib |
Darwin dylib built
from Lua core @@ TODO add details |
|
liblualib ‐‐ lib/liblualib.dylib ‐> liblualib.5.dylib |
Darwin
dylib built from Lua core libraries @@ TODO add details |
|
binary modules ‐‐ various, of the form lib/luacheia5/lua*.so |
These are actually dylib's, although they are named like ELF shared
objects. @@ TODO add details |
|
|
