[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: Wed, 3 Jan 2018 22:20:04 -0800
On Tue, Jan 2, 2018 at 10:27 AM, Thijs Schreijer
<thijs@thijsschreijer.nl> 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.
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.
Russ
> Thijs
>
>> On 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.
>>
>> --
>> Cheers,
>> Kein-Hong Man (esq.)
>> Selangor, Malaysia
>>
>>
>
>