Building Lua, dynamic linking using OW IDE
From Open Watcom
Obtain the current source distribution and unpack into an empty subdirectory.
First we build lualib.dll
Fire up the OW IDE.
Create a new target named lualib and of type dll
The file list is given in the file INSTALL but here is it anyway, insert these files into the target.
lapi.c lcode.c ldebug.c ldo.c ldump.c lfunc.c lgc.c llex.c lmem.c lobject.c lopcodes.c lparser.c lstate.c lstring.c ltable.c ltm.c lundump.c lvm.c lzio.c lauxlib.c lbaselib.c ldblib.c liolib.c lmathlib.c loslib.c ltablib.c lstrlib.c loadlib.c linit.c
In / menu / options / C compile switches
I'd set space optimisation and no debug. (the code is fine)
Save the project.
Hit compile. All being well a .dll appears.
Now we build the interpreter
Add a new target into the same project, name it lua and of type command line executable.
Populate the source files pane with just one file,
/menu/options/windows linking switches
Stack op, something much larger than OW default, with is very small maybe
Under pane 2, import export switches, under libraries, the middle text entry box
Save the project.
Hit compile and all being well lua.exe has appeared.
Run it, should pick up the the dll and off you go. A good first test, assuming you can find the source files
This loads and executes a script with that name.
If you want you can add another target luac.exe, with is a compiler to binary for scripts. A compiled script is roughly the same size but load slightly faster and a known free from syntax errors. For most users this utility is of little use.
Updated 2014 Last Lua 5.1, current stable 5.1.5, 5.2 is released by library support is limited, 5.3 in initial dev.
Building binary libraries, dll
Defines _WIN32 LUA_BUILD_AS_DLL
The compiler needs the path of lua.h and path to the header of any dependencies.
Linking is more difficult.
Link against lualib.dll and for any other dependencies the static (.lib) or dynamic (.dll)
A very critical linker step is override the default naming. Explanation: the core of Lua contains the poor practice of assuming it knows the name of a dynamic library export and os the name of the call is computed. OpenWatcom in fact adds a guard against linking incorrect calling conventions, the name is decorated with an additional character. In this case we compiled Lua and the library, the call is safe and therefore we can override the naming.
If in a Lua script we use a binary library named xml local xml = require("xml")
The Lua core will (this is simplified) ask the operating system to load a dll named xml.dll and call the dll initialisation function luaopen_xml it prepends luaopen_
The linker has to be told to do this, clarifying, there is an underscore at the end which we are removing. export luaopen_xml=luaopen_xml_
This is the only library external, the rest is automatic.
A wise move is if a header file does not exist for the library then make one and include in the top level as a safety check.
As an example here is what might be the contents of xml.h
LUALIB_API int luaopen_xml(lua_State *L);