lunarmodules/lua-compat-5.3

How to compile on windows

Closed this issue · 4 comments

I fail to compile this library on windows as dll to be loaded by lua.
After some attempts (see commented cmake code here) I took a look in the code and I cannot see any way to use dllexport or similar. Because of that the dll cannot be loaded by lua afterwards.

How is one supposed to compile this library as dll on windows?
Does it not support windows in current form?

There are six parts to this project: Two Lua modules (compat53/init.lua and compat53/module.lua), a C API intended for 3rd party C modules, and three C modules backported from Lua 5.3. The C API can be configured using COMPAT53_PREFIX and COMPAT53_API. The readme explains how those two macros work together, and there are comments explaining them in c-api/compat53.h. The three backported modules use the LUAMOD_API macro, but it is not overridable (see lprefix.h. The configured value is fine for Unixes and MinGW on Windows. For MSVC you would need a .def file for each module (I believe that's how LuaRocks builds them).

LUAMOD_API is out of our control, because it is set by luaconf.h, but we could add another configurable macro for the three backported modules if .def files is not an option for you.

Had never heard of .def. But by searching with it I was able to find https://cmake.org/cmake/help/latest/prop_tgt/WINDOWS_EXPORT_ALL_SYMBOLS.html

Enable this boolean property to automatically create a module definition (.def) file with all global symbols found in the input .obj files

I was able to compile on windows by setting the property on my compile targets in CMake:

set_property(
  TARGET compat53_string compat53_table compat53_utf8
  PROPERTY WINDOWS_EXPORT_ALL_SYMBOLS YES
)

Thanks.

From my understanding, LUAMOD_API is LUALIB_API which in turns equal to LUA_API which in turns equal to dllimport/export if LUA_BUILD_AS_DLL is defined (and you should define that when compiling under MSVC anyway) or extern otherwise.

https://github.com/lua/lua/blob/v5.3/luaconf.h#L236-L261

Is there something that I missed?

Yes, the comment section of the block you linked to. It says that LUA_API, LUALIB_API, and LUAMOD_API are for the Lua core, the Lua auxiliary library, and standard library open functions, respectively. LUAMOD_API is not intended for third-party modules. The difference is that the standard library open functions usually end up in the same DLL as the core and the auxiliary library. The definitions in luaconf.h are set up for this. Third-party module open functions are usually in their own DLLs, so the decoration needs to be different from the standard library open functions (and core and auxiliary functions).

I'm aware that many people nevertheless use LUAMOD_API, and to my surprise it seems to work. I'm assuming that they just don't test on MSVC, or MSVC is very forgiving. Anyway, third-party modules in external DLLs should export their own open functions and import the Lua API. This is not possible if the decoration is the same for both.

__declspec(dllimport) is optional for function declarations, this is why we can get away with leaving the LUA_MODAPI macros in place (for the default LUA*_API macro definitions as long as we don't use LUA_BUILD_AS_DLL).