 |
lua-l archive |
|
|
||
|
I'm new to Lua and I would like to give it a try in an application. That is, on Windows 10 with Visual Studio 2010.
I have some examples in Lua 5.1 but I also would like to try Lua 5.3 so I downloaded both versions.
Lua 5.1.5 comes with a nice driver for Visual Studio in 'etc/luavs.bat', unfortunately Lua 5.3.4 is missing this kind of tooling.
Is was not too dificult to 'upgrade' the 5.1.5 version, using the 5.3.4 Makefile as a source for details.
(See the listing of my version of 'VS2010/luavs.bat' at the end of this message.)
Building Lua 5.1.5 was no problem, one try, one hit. Lua.exe was responding the way I expected it.
But as a newbee to Lua, no way that I could do some extensive testing, of cause.
Building Lua 5.3.4 gave me some troubles which I would like to discuss and/or report because I do not know how to correctly solve the problems or what the impact will be.
And I got some sort of a workaround.
The Makefile suggest to build a Lua53.a (or a Lua53.lib in MS parlance).
If I do that then I get linker errors for Luac.exe but not for Lua.exe.
Here are the linker details:
...\Lua\lua-5.3.4\src>link /nologo /out:luac.exe luac.obj lua53.lib
luac.obj : error LNK2019: unresolved external symbol _luaP_opmodes referenced in function _PrintCode
luac.obj : error LNK2019: unresolved external symbol _luaP_opnames referenced in function _PrintCode
luac.obj : error LNK2019: unresolved external symbol _luaU_dump referenced in function _pmain
luac.exe : fatal error LNK1120: 3 unresolved externals
Looking up the code I found the following remarks in luaconf.5 r264...
/*
@@ LUAI_FUNC is a mark for all extern functions that are not to be
** exported to outside modules.
@@ LUAI_DDEF and LUAI_DDEC are marks for all extern (const) variables
** that are not to be exported to outside modules (LUAI_DDEF for
** definitions and LUAI_DDEC for declarations).
...
My conclusion:
The references to _luaP_opmodes and _luaP_opnames are only possible within lua53.lib and not available for luac.obj.
And that suggested to me to link against *.obj, not to link agains Lua53.lib. That sort of solved my problem.
(The script at the end of this message is configured for this option).
My point:
There must be a reason for the data structures not to be visible outside the archive (or library).
Linking against *.obj defeats that.
I tried to 'solve' the issue by changing luaconf.h but was not able to get some result.
I don't have a Linux system available and my experience with gcc has collected dust for at least 10 years. So I can't check what the Makefile is doing exactly.
The solution I've found might be acceptable for luac.exe but what if I need the same data structures in my application.
Not likely, at least not in the beginning, I know. But I rather ask now than later.
My question:
What must be done to 'solve' this issue so that Visual Studio can use Lua53.lib for Luac.exe?
Kind regards.
Andre Steenveld.
PS: I'm willing to answer questions about my version of 'luavs.bat' if something is not clear.
My 2 cents as a donation for the comunity. ;-)VS2010/luavs.bat
===8<---
@rem Script to build Lua with "Visual Studio 2010 .NET Command Prompt".
@rem Do not run from this directory; run it from the toplevel as: VS2010\luavs.bat.
@rem It creates lua53.dll, lua53.lib, lua.exe, and luac.exe in src.
@rem Run from a Visual Studio command shell, a plain command shell will not work.
@rem
@rem Advised way to call this script, all output goes to luavs.log:
@rem
@rem ...\lua-5.3.4> VS2010\luavs.bat > luavs.log
@rem
@rem Version: Lua-5.3.4; altered by Andre Steenveld, changes based on src\Makefile.
@rem Version: Lua-5.1.5; (contributed by David Manura and Mike Pall)
@setlocal
@set MYCOMPILE=cl /nologo /MD /O2 /W3 /c /D_CRT_SECURE_NO_DEPRECATE /DLUA_COMPAT_5_2
@set MYLINK=link /nologo
@set MYMT=mt /nologo
@set LUA_CORE=lapi.c lcode.c lctype.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
@set LUA_LIB=lauxlib.c lbaselib.c lbitlib.c lcorolib.c ldblib.c liolib.c^
lmathlib.c loslib.c lstrlib.c ltablib.c lutf8lib.c loadlib.c linit.c
@set LUA_A=lua53
@set LUA_T=lua
@set LUA_C=luac
cd src
@rem build the DLL and the LIB files.
%MYCOMPILE% /DLUA_BUILD_AS_DLL %LUA_CORE% %LUA_LIB%
%MYLINK% /DLL /out:%LUA_A%.dll *.obj
if exist %LUA_A%.dll.manifest^
%MYMT% -manifest %LUA_A%.dll.manifest -outputresource:%LUA_A%.dll;2
del *.obj *.manifest
@rem Build Lua.exe
%MYCOMPILE% %LUA_T%.c
%MYLINK% /out:%LUA_T%.exe %LUA_T%.obj %LUA_A%.lib
if exist %LUA_T%.exe.manifest^
%MYMT% -manifest %LUA_T%.exe.manifest -outputresource:%LUA_T%.exe
del *.obj *.manifest
@rem Build Luac.exe with %LUA_A%.lib
:: using %LUA_A%.lib will generate some link errors for data structures.
::%MYCOMPILE% %LUA_C%.c
::%MYLINK% /out:%LUA_C%.exe %LUA_C%.obj %LUA_A%.lib
@rem Build Luac.exe with *.obj
:: using *.obj makes the data structures visible for the linker.
%MYCOMPILE% %LUA_C%.c %LUA_CORE% %LUA_LIB%
%MYLINK% /out:%LUA_C%.exe *.obj
if exist %LUA_C%.exe.manifest^
%MYMT% -manifest %LUA_C%.exe.manifest -outputresource:%LUA_C%.exe
del *.obj *.manifest
cd ..
--->8===