[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Compiling LuaFileSystem on Windows 10
- From: Russell Haley <russ.haley@...>
- Date: Fri, 5 Jan 2018 23:45:35 -0800
On Thu, Jan 4, 2018 at 10:53 PM, Russell Haley <russ.haley@gmail.com> wrote:
> On Thu, Jan 4, 2018 at 10:49 PM, Russell Haley <russ.haley@gmail.com> wrote:
>> On Thu, Jan 4, 2018 at 10:48 PM, Russell Haley <russ.haley@gmail.com> wrote:
>>> On Thu, Jan 4, 2018 at 10:10 PM, Russell Haley <russ.haley@gmail.com> wrote:
>>>> On Mon, Jan 1, 2018 at 11:22 PM, KHMan <keinhong@gmail.com> wrote:
>>>>> On 1/2/2018 2:27 PM, Russell Haley wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I'm attempting to get some packages on Windows via luarocks and (as
>>>>>> warned by luarocks members) I am running into an issue trying to build
>>>>>> binaries - lfs in this case. My builds are failing in the linking step
>>>>>> with an error message as such (full output here
>>>>>> https://pastebin.com/vVFgfyS2):
>>>>>>
>>>>>> C:\Program Files (x86)\PUC-Lua\5.3.4\x86\lua53.dll : fatal error
>>>>>> LNK1107: invalid or corrupt file: cannot read at 0x448 (or some
>>>>>> address).
>>>>>>
>>>>>> I have run the build against three different builds of Lua:
>>>>>> - A 32 bit version compiled with mingw from
>>>>>> http://joedf.ahkscript.org/LuaBuilds/
>>>>>> - A 32 bit version I compiled with Visual Studio 2017
>>>>>> - A 64 bit version I compiled with Visual Studio 2017
>>>>>>
>>>>>> I copied the binaries to the same folder in between executions. Note
>>>>>> the different "cannot read" address in each attempt. Can someone tell
>>>>>> me what I am doing incorrectly?
>>>>>
>>>>>
>>>>> (Disclaimer: I'm not a Visual Studio user)
>>>>>
>>>>> From these, lemme just make a wild guess:
>>>>> https://msdn.microsoft.com/en-us/library/0h6ctxtk.aspx
>>>>> https://msdn.microsoft.com/en-us/library/hcce369f.aspx
>>>>>
>>>>> Maybe linker does not accept DLLs? *.lib instead? I have always assumed
>>>>> linking the DLL directly was an innovation of those who brought gcc to
>>>>> Windows.
>>>>
>>>> One question first: If I link to a static lib file, does that mean all
>>>> my executables *contain* lua53.lib?
>>>>
>>>> 1) I downloaded lfs from github and tried building it from the command
>>>> line which resulted in the same error (expected). I copied out the
>>>> commands.
>>>>
>>>> 2) I updated my Lua installation to have the following files:
>>>>
>>>> Directory of C:\Program Files (x86)\PUC-Lua\5.3.4\x86
>>>>
>>>> 2018-01-04 09:33 PM <DIR> .
>>>> 2018-01-04 09:33 PM <DIR> ..
>>>> 2018-01-01 10:07 PM 389,120 lua.exe
>>>> 2018-01-01 10:07 PM 919,444 lua.ilk
>>>> 2018-01-01 10:07 PM 978,944 lua.pdb
>>>> 2018-01-01 10:07 PM 349,184 lua53.dll
>>>> 2018-01-01 10:07 PM 757 lua53.exp
>>>> 2018-01-01 10:07 PM 602,488 lua53.ilk
>>>> 2018-01-01 10:07 PM 1,506 lua53.lib
>>>> 2018-01-01 10:07 PM 765,952 lua53.pdb
>>>> 2018-01-01 10:07 PM 358,400 luac.exe
>>>> 2018-01-01 10:07 PM 917,040 luac.ilk
>>>> 2018-01-01 10:07 PM 970,752 luac.pdb
>>>> 2018-01-04 10:03 PM <DIR> systree
>>>> 11 File(s) 6,253,587 bytes
>>>>
>>>> 3) I then ran modified cl and link commands in the git/lfs directory:
>>>>
>>>> cl /nologo /MD /O2 -c -Fosrc/lfs.obj -I"C:\Program Files
>>>> (x86)\PUC-Lua\5.3.4\include" src\lfs.c
>>>> link -dll -def:lfs.def -out:lfs.dll "C:\Program Files
>>>> (x86)\PUC-Lua\5.3.4\x86\lua53.lib" src/lfs.obj
>>>>
>>>>
>>>> C:\Users\russh\Git\luafilesystem>cl /nologo /MD /O2 -c -Fosrc/lfs.obj
>>>> -I"C:\Program Files (x86)\PUC-Lua\5.3.4\include" src\lfs.c
>>>> lfs.c
>>>>
>>>> C:\Users\russh\Git\luafilesystem>link -dll -def:lfs.def -out:lfs.dll
>>>> "C:\Program Files (x86)\PUC-Lua\5.3.4\x86\lua53.lib" src/lfs.obj
>>>> Microsoft (R) Incremental Linker Version 14.12.25831.0
>>>> Copyright (C) Microsoft Corporation. All rights reserved.
>>>>
>>>> Creating library lfs.lib and object lfs.exp
>>>> lfs.obj : error LNK2019: unresolved external symbol _lua_gettop
>>>> referenced in function _file_utime
>>>> lfs.obj : error LNK2019: unresolved external symbol _lua_settop
>>>> referenced in function __file_info_
>>>> lfs.obj : error LNK2019: unresolved external symbol _lua_pushvalue
>>>> referenced in function _luaopen_lfs
>>>> lfs.obj : error LNK2019: unresolved external symbol _lua_isstring
>>>> referenced in function _link_info
>>>> lfs.obj : error LNK2019: unresolved external symbol _lua_type
>>>> referenced in function _link_info
>>>> lfs.obj : error LNK2019: unresolved external symbol _lua_tolstring
>>>> referenced in function _link_info
>>>> lfs.obj : error LNK2019: unresolved external symbol _lua_touserdata
>>>> referenced in function _dir_close
>>>> lfs.obj : error LNK2019: unresolved external symbol _lua_pushnil
>>>> referenced in function _change_dir
>>>> lfs.obj : error LNK2019: unresolved external symbol _lua_pushinteger
>>>> referenced in function _get_dir
>>>> lfs.obj : error LNK2019: unresolved external symbol _lua_pushstring
>>>> referenced in function _get_dir
>>>> lfs.obj : error LNK2019: unresolved external symbol _lua_pushfstring
>>>> referenced in function _change_dir
>>>> lfs.obj : error LNK2019: unresolved external symbol _lua_pushcclosure
>>>> referenced in function _dir_iter_factory
>>>> lfs.obj : error LNK2019: unresolved external symbol _lua_pushboolean
>>>> referenced in function _change_dir
>>>> lfs.obj : error LNK2019: unresolved external symbol _lua_getfield
>>>> referenced in function _lfs_lock_dir
>>>> lfs.obj : error LNK2019: unresolved external symbol _lua_createtable
>>>> referenced in function __file_info_
>>>> lfs.obj : error LNK2019: unresolved external symbol _lua_newuserdata
>>>> referenced in function _lfs_lock_dir
>>>> lfs.obj : error LNK2019: unresolved external symbol _lua_setglobal
>>>> referenced in function _luaopen_lfs
>>>> lfs.obj : error LNK2019: unresolved external symbol _lua_setfield
>>>> referenced in function _dir_create_meta
>>>> lfs.obj : error LNK2019: unresolved external symbol _lua_rawset
>>>> referenced in function __file_info_
>>>> lfs.obj : error LNK2019: unresolved external symbol _lua_setmetatable
>>>> referenced in function _lfs_lock_dir
>>>> lfs.obj : error LNK2019: unresolved external symbol
>>>> _luaL_checkversion_ referenced in function _luaopen_lfs
>>>> lfs.obj : error LNK2019: unresolved external symbol _luaL_argerror
>>>> referenced in function _dir_iter
>>>> lfs.obj : error LNK2019: unresolved external symbol _luaL_checklstring
>>>> referenced in function _change_dir
>>>> lfs.obj : error LNK2019: unresolved external symbol _luaL_optnumber
>>>> referenced in function _file_utime
>>>> lfs.obj : error LNK2019: unresolved external symbol _luaL_optinteger
>>>> referenced in function _file_lock
>>>> lfs.obj : error LNK2019: unresolved external symbol _luaL_newmetatable
>>>> referenced in function _dir_create_meta
>>>> lfs.obj : error LNK2019: unresolved external symbol _luaL_checkudata
>>>> referenced in function _lfs_f_setmode
>>>> lfs.obj : error LNK2019: unresolved external symbol _luaL_error
>>>> referenced in function _lfs_f_setmode
>>>> lfs.obj : error LNK2019: unresolved external symbol _luaL_checkoption
>>>> referenced in function _lfs_f_setmode
>>>> lfs.obj : error LNK2019: unresolved external symbol _luaL_setfuncs
>>>> referenced in function _luaopen_lfs
>>>> lfs.dll : fatal error LNK1120: 30 unresolved externals
>>>>
>>>> Russ
>>>
>>> I *think* I've solved this. I changed my dll project to build a lib
>>> file instead, which generated a new lua53.lib file that was 926 Kb
>>> instead of 2 kb. That allowed the linking to complete, but linking lfs
>>> created an lfs.lib not a dll because of a different error. I rebuilt
>>> my lua53.dll file as well and the DLL built. The final lfs.dll file is
>>> 171,008 bytes. That seems large but I don't know any better. Will try
>>> it shortly...
>>>
>>> Russ
>>
>> Clarification: I changed my Lua 5.3 Visual Studio project to build a lib...
>
> I copied the lfs.dll file into my program files dir and ran lua:
>
> Lua 5.3.4 Copyright (C) 1994-2017 Lua.org, PUC-Rio
>> lfs = require("lfs")
> multiple Lua VMs detected
> stack traceback:
> [C]: in ?
> [C]: in function 'require'
> stdin:1: in main chunk
> [C]: in ?
>>
>
> Well that was fun, and clearly answers my question about static linking. :-/
>
> Night,
> Russ
So I think it comes down to two problems:
1) Both a static link library and an import library are called *.lib.
The *.lib file I was generating with my lua53.dll was only 2kb (later
when I ran dumpbin it turned out to be "empty"). I had confused the
two types of lib files and generated a static link library instead.
That was fine for generating the lua.exe file, but no so cool when
trying to link to a dll - which created my dual virtual machines (tm)
above.
2) My empty *include* library that is supposed to be generated with
lua53.dll comes down to the code not exporting anything. The following
article seems to set the stone wall:
https://docs.microsoft.com/en-us/cpp/build/exporting-c-functions-for-use-in-c-or-cpp-language-executables
Which, if I am reading it correctly, is saying that to succesful build
a DLL in Visual Studio I would either need to mark up the entire Lua
API in the header files with
__declspec( dllimport ) void _lua_func_here(...);
OR Every application (C++ only?) that is built under vs needs to be
patched to use
extern "C" { #include "MyCHeader.h" }
sigh.
The good news from all of this is I found MSYS2. I guess I'll start
looking at LuaDist...
Russ
>>>>> --
>>>>> Cheers,
>>>>> Kein-Hong Man (esq.)
>>>>> Selangor, Malaysia
>>>>>
>>>>>
