 |
lua-l archive |
|
|
||
|
On 1/4/2018 2:20 PM, Russell Haley wrote:
On Tue, Jan 2, 2018 at 10:27 AM, Thijs Schreijer wrote:Not sure, but if KH Man is right, then make sure that you: 1. build Lua, and 2. install LuaRocks, and 3. install the rock All with the same toolchain.My last two attempts were built with Lua compiled in VS 2017 on the same computer moments earlier. Perhaps this is a question for a Microsoft forum. I'll try again later in my MSYS2 environment and compare. I question if the DLLs have been built correctly.
You should try it on a compiler for which something like this have worked for you in the past.
So far nobody has addressed the VS2017's linker ability to link directly to DLLs supplied on the command line. That's the obvious point of failure. Not a problem with lua53.dll. AFAIK you cannot put lua53.dll on the command line for a Microsoft linker, you must use a lua53.lib file or something like that. For sure you need to use a *.lib file for VS2015, and I doubt it changed for VS2017.
If you want to link to lua53.dll on the command line, please use MinGW or MSYS2 or TDM-gcc or equivalent.
A random shot in the dark: are there Windows binaries available via LuaRocks packages (and can they be filtered for)? Is there stomach for such things? I can see the appeal of something like LuaForWindows and also how it could get quite unwieldy. I was considering going down that road with a Windows installer. My preference would be to include LuaRocks in the installer. If simple things like LuaFileSystem can't be grabbed easily then that presents other challenges. My next consideration is to build some simple components and include them [1]. The final thought is to create some Win64 binaries of the tools I like and publish the rocks. [1] Or build them right into Lua? That breaks APIs though. I understand the reason lfs isn't built into the language, but perhaps it could be included with the sources and an optional target created? Perhaps a tools directory? Just a thought. RussThijsOn 2 Jan 2018, at 08:22, 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. [snip]
-- Cheers, Kein-Hong Man (esq.) Selangor, Malaysia