[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: LuaBinaries and the RTL DLL for 5.2
- From: "Antonio Scuri" <scuri@...>
- Date: Sat, 16 Jan 2010 11:16:43 -0200
Just to clear things. LuaBinaries will still contains binaries for all
platforms it supports today. I mean the "dll9" package for instance is the
DLL generated by VC9 depending on msvcr9.dll, the "dll8" by vc8 dep. on
msvcr8.dll, and so on.
The discussion here is only about the executable, that we distribute only
one. So we have to choose the DLL it will use. And since Lua for Windows
uses our executable then this decision affects LfW users.
Once thing that I forgot is that I don't know how to build 64 bits
executables in Windows using gcc, only with vc8 or vc9. So the 64 bits
executable package will still have to use one of those. For now is not a big
deal because LfW only distributes 32 bits. Any clues on this?
> -----Original Message-----
> From: firstname.lastname@example.org [mailto:lua-
> email@example.com] On Behalf Of steve donovan
> Sent: sábado, 16 de janeiro de 2010 05:33
> To: Lua list
> Subject: Re: LuaBinaries and the RTL DLL for 5.2
> On Sat, Jan 16, 2010 at 4:29 AM, Antonio Scuri <firstname.lastname@example.org-
> rio.br> wrote:
> > I guess I have enough information to move on. But before adopting
> > mscvrt.dll I have to make some tests here. Because although vc8
> brought us
> > the manifest problems, it was stable. Moving to vc9 is more or less a
> > ground. So I?ll give mingw a try.
> The VC runtime is a ever changing target. For instance, the LfW
> standard (vc8) is no longer very compatible with the compiler that
> most Windows devs would be using now. (They tend to upgrade to the
> latest and greatest, often precisely because of incompatible runtimes;
> technically dubious strategy, brilliant for forcing upgrades ;))
> If the idea was to provide a good solid Lua implementation, then I
> would totally agree with Ryan; much less fuss to use GCC. For a set
> of binaries that can be used with the MS tools, then vc9 is a good
> compromise. It's easy to say 'use a free compiler' but devs get very
> attached to their existing tools, which are actually quite addictive.
> It's like asking a Java dev to forsake Eclipse.
> But then if someone is embedding Lua in their MS project, then they
> may as well just compile it themselves, very straightforward.
> So I remain slightly confused. BTW, I will try get the Lua 5.1 test
> suite working on Windows so that we can evaluate the latest GCC
> versions more thoroughly. For instance, whether the more aggressive
> optimizations are without issues.
> steve d.