Re: Compiling LuaFileSystem on Windows 10

[Russell Haley <russ.haley@...>]

On Wed, Jan 3, 2018 at 11:47 PM, KHMan <keinhong@gmail.com> wrote:
> 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.

I apologize, I misunderstood what you were saying the first time.
Thank you for the clarification.

> 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.
>>
>> 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.
>>>> [snip]
>
>
> --
> Cheers,
> Kein-Hong Man (esq.)
> Selangor, Malaysia
>
>