[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Getting Started with Lua
- From: Peter Drahoš <drahosp@...>
- Date: Thu, 25 Jul 2013 16:14:38 +0200
On 25 Jul, 2013, at 15:49 , Lorenzo Donati <lorenzodonatibz@tiscali.it> wrote:
> On 25/07/2013 15.23, Peter Drahoš wrote:
>
> Thank you for all the pointers.
>
> [snip]
>
>> TDM GCC is a solid suggestion, the current LuaDist
>> binaries[1] are built with it and so far there have been no
>> issues with the distribution that are worth mentioning.
>> However I would now recommend to switch over to the
>> MinGW-builds[2] especially if you are aiming for 64bit
>> releases with SEH exception handling[3] which is also
>> suitable for LuaJIT. That is why upcoming LuaDist binaries
>> will use MinGW-builds 4.8.1.
>
>
> I forgot to mention that I used only the 32bit version, I never used TDM GCC 64bit, has it some issues?
> I used TDM GCC 4.7.1 (32bit) to build LuaJIT and everything was ok.
> I must admit that it was only to play a little with LuaJIT ffi, so I cannot say if the generated LuaJIT executable has issues.
32bit LuaJIT has no issues however 64bit LuaJIT builds were unsupported because of the exception handling mechanism, see LuaJIT list for details. The SEH exception handling that LuaJIT requires is only available in GCC 4.8 and up. That is why I suggested to use MinGW-builds instead of the TDM GCC distribution which is currently only offering GCC 4.7.1. Other than that the 64bit TDM GCC is fine for most projects and it will build Lua and related modules without any problems. Note that the 64bit MinGW releases can build both 32 and 64bit applications, the 32bit MinGW can only build 32bit apps.
>
>>
>>> It would help people which don't like/want or can't depend on MSVC tools, like OSS tools and/or are not too C-savy.
>>>
>> The installation and use of the MinGW tools cannot be easier,
>> unpack and add destination to PATH, there are also installers
>> available. Another problem you will face on Windows is the
>> lack of any decent make replacements if you do not want to
>> use Msys(which I will not go into), for that purpose CMake[3]
>> works well especially if the software aims to be portable to
>> other platforms. This works well with Code::Blocks IDE or
>> QtCreator
>
> The make in coreutils coming with TDM GCC 32bit seems ok.
It has issues but yes, generally it works well for straightforward builds. The fun starts when someone brings something like Autotools to the picture but that has already been discussed multiple times on the list. There are known issues with network drives and oddly named directories depending on your setup, as a rule keep the build environment local on a single drive and use ASCII only paths.
pd