LuaBinaries and the RTL DLL for 5.2

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

LuaBinaries and the RTL DLL for 5.2

Antonio Scuri
  For those who use the LuaBinaries executables,

  I'm about to release the LuaBinaries for 5.2.0-work2 and have a question
regarding the DLL dependency.

  I think it is time to move from vc8 (VS 2005) to vc9 (VS 2008) and the 5.2
release is a great opportunity since it will force all modules to recompile
anyway.

  What do you think?

Best,
Scuri


Reply | Threaded
Open this post in threaded view
|

Re: LuaBinaries and the RTL DLL for 5.2

RJP Computing
On Thu, Jan 14, 2010 at 11:01 PM, Antonio Scuri <[hidden email]> wrote:
 For those who use the LuaBinaries executables,

 I'm about to release the LuaBinaries for 5.2.0-work2 and have a question
regarding the DLL dependency.

 I think it is time to move from vc8 (VS 2005) to vc9 (VS 2008) and the 5.2
release is a great opportunity since it will force all modules to recompile
anyway.

 What do you think?

I vote to compile and release with MinGW GCC. Drop the tough VC RTL issues. MinGW has updated to version 4.4 and is just as fast if not faster than VC. Please.
--
Regards,
Ryan
Reply | Threaded
Open this post in threaded view
|

Re: LuaBinaries and the RTL DLL for 5.2

steve donovan
On Fri, Jan 15, 2010 at 6:27 AM, RJP Computing <[hidden email]> wrote:
> I vote to compile and release with MinGW GCC. Drop the tough VC RTL issues.
> MinGW has updated to version 4.4 and is just as fast if not faster than VC.
> Please.

The voice of bitter experience ;)  This is a very attractive option
available to us, but:
- many Windows people like their existing tools
- particularly if they are integrating Lua into their existing Windows
applications

This doesn't apply to the pure scripter, of course. So the argument
for Lua for Windows going GCC is good, particularly if we can persuade
LuaRocks 2 to recognize mingw targets on Windows.

steve d.
Reply | Threaded
Open this post in threaded view
|

Re: LuaBinaries and the RTL DLL for 5.2

Jerome Vuarand
In reply to this post by Antonio Scuri
2010/1/15 Antonio Scuri <[hidden email]>:

>  For those who use the LuaBinaries executables,
>
>  I'm about to release the LuaBinaries for 5.2.0-work2 and have a question
> regarding the DLL dependency.
>
>  I think it is time to move from vc8 (VS 2005) to vc9 (VS 2008) and the 5.2
> release is a great opportunity since it will force all modules to recompile
> anyway.
>
>  What do you think?

Another option is to remove the dependency on the VC runtime by
linking with the static libc (whatever the compiler used, VC8, VC9 or
GCC). I'm doing that to release small apps based on Lua, and it's
working great.

The drawback is size. I made a comparison with VC9. With dynamic libc
(MSVCR90.DLL), the lua52.dll and lua.exe files are respectively 205kiB
and 12kiB big. With static libc they are respectively 405kiB and
75kiB.
Reply | Threaded
Open this post in threaded view
|

Re: LuaBinaries and the RTL DLL for 5.2

steve donovan
On Fri, Jan 15, 2010 at 1:33 PM, Jerome Vuarand
<[hidden email]> wrote:
> The drawback is size. I made a comparison with VC9. With dynamic libc
> (MSVCR90.DLL), the lua52.dll and lua.exe files are respectively 205kiB
> and 12kiB big. With static libc they are respectively 405kiB and
> 75kiB.

That's not too bad. I'm more worried about C extensions and their
runtime dependencies.  Statically linking them all will make a big
difference in overall size.
Reply | Threaded
Open this post in threaded view
|

Re: LuaBinaries and the RTL DLL for 5.2

Ignacio Burgueño
In reply to this post by Jerome Vuarand
On 15/01/2010 09:33, Jerome Vuarand wrote:

> Another option is to remove the dependency on the VC runtime by
> linking with the static libc (whatever the compiler used, VC8, VC9 or
> GCC). I'm doing that to release small apps based on Lua, and it's
> working great.

Please correct me, but Lua + LuaFileSystem will never work. LFS needs to
use the same C runtime that Lua uses.


Reply | Threaded
Open this post in threaded view
|

Re: LuaBinaries and the RTL DLL for 5.2

Ignacio Burgueño
In reply to this post by Antonio Scuri
On 15/01/2010 02:01, Antonio Scuri wrote:

>    For those who use the LuaBinaries executables,
>
>    I'm about to release the LuaBinaries for 5.2.0-work2 and have a question
> regarding the DLL dependency.
>
>    I think it is time to move from vc8 (VS 2005) to vc9 (VS 2008) and the 5.2
> release is a great opportunity since it will force all modules to recompile
> anyway.
>
>    What do you think?

Well, VS 2010 is coming anytime. I don't know if there will be a free
edition (I think it will). Possibly it will bring yet another runtime
(MSVCR10 ??) But I once read (can't find the link though) that VS2010
will let you choose the runtime used when linking.

I don't know what to say, honestly. Here at work we use Lua linked
against msvcrt. We require a lot of libraries written in C, and they
link to msvcrt or msvcr90 and we have no issues. But the option of going
GCC seems best in the long run. I would miss, though, being able to
debug using Visual Studio.

Regards,
Ignacio


Reply | Threaded
Open this post in threaded view
|

RE: LuaBinaries and the RTL DLL for 5.2

Antonio Scuri
In reply to this post by RJP Computing

  As always the problem is not the compiler. MingW still uses the MSVCRT.DLL. This RTL has two great pros for re-distributing DLLs: it is already installed on the system and does not depends on a manifest. This would be heaven… But I think it has many cons.

 

  It is an old DLL with known bugs and it is not maintained anymore. The main development environment for Windows is still Visual C++. The free Windows SDK already includes a command line version of VC. Visual C++ Express edition is a free fully featured IDE. And for those who are used to develop in Visual C++ to build DLLs with several dependencies using gcc is not an easy task.

 

  BTW the official stable version of MingW still uses GCC version 3. I just downloaded version 5.1.6 to check that. If I’m not mistaken GCC 4 must be manually installed.

 

  Maybe in 2010 we see some improvements on that (VC or MingW). But for now we have vc8 and vc9. So back to the issue, what do you think of moving from vc8 to vc9?

 

Best,

scuri

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of RJP Computing
Sent: sexta-feira, 15 de janeiro de 2010 02:27
To: Lua list
Subject: Re: LuaBinaries and the RTL DLL for 5.2

 

On Thu, Jan 14, 2010 at 11:01 PM, Antonio Scuri <[hidden email]> wrote:

 For those who use the LuaBinaries executables,

 I'm about to release the LuaBinaries for 5.2.0-work2 and have a question
regarding the DLL dependency.

 I think it is time to move from vc8 (VS 2005) to vc9 (VS 2008) and the 5.2
release is a great opportunity since it will force all modules to recompile
anyway.

 What do you think?

 

I vote to compile and release with MinGW GCC. Drop the tough VC RTL issues. MinGW has updated to version 4.4 and is just as fast if not faster than VC. Please.

--
Regards,
Ryan

Reply | Threaded
Open this post in threaded view
|

Re: LuaBinaries and the RTL DLL for 5.2

Andrew Wilson-4
Generally I'd rather move to an open source compiler solution,I'd also
like to get away from dependency on a specific MSVC runtime version.
Is it possible to have MSWindows images that aren't dependent on a
specific runtime version? How broken is MSVCRT.DLL? Do these
MSVCRT.dll issues cause real problems?

Andrew

On Fri, Jan 15, 2010 at 9:25 AM, Antonio Scuri <[hidden email]> wrote:

>   As always the problem is not the compiler. MingW still uses the
> MSVCRT.DLL. This RTL has two great pros for re-distributing DLLs: it is
> already installed on the system and does not depends on a manifest. This
> would be heaven… But I think it has many cons.
>
>
>
>   It is an old DLL with known bugs and it is not maintained anymore. The
> main development environment for Windows is still Visual C++. The free
> Windows SDK already includes a command line version of VC. Visual C++
> Express edition is a free fully featured IDE. And for those who are used to
> develop in Visual C++ to build DLLs with several dependencies using gcc is
> not an easy task.
>
>
>
>   BTW the official stable version of MingW still uses GCC version 3. I just
> downloaded version 5.1.6 to check that. If I’m not mistaken GCC 4 must be
> manually installed.
>
>
>
>   Maybe in 2010 we see some improvements on that (VC or MingW). But for now
> we have vc8 and vc9. So back to the issue, what do you think of moving from
> vc8 to vc9?
>
>
>
> Best,
>
> scuri
>
>
>
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of RJP Computing
> Sent: sexta-feira, 15 de janeiro de 2010 02:27
> To: Lua list
> Subject: Re: LuaBinaries and the RTL DLL for 5.2
>
>
>
> On Thu, Jan 14, 2010 at 11:01 PM, Antonio Scuri <[hidden email]>
> wrote:
>
>  For those who use the LuaBinaries executables,
>
>  I'm about to release the LuaBinaries for 5.2.0-work2 and have a question
> regarding the DLL dependency.
>
>  I think it is time to move from vc8 (VS 2005) to vc9 (VS 2008) and the 5.2
> release is a great opportunity since it will force all modules to recompile
> anyway.
>
>  What do you think?
>
>
>
> I vote to compile and release with MinGW GCC. Drop the tough VC RTL issues.
> MinGW has updated to version 4.4 and is just as fast if not faster than VC.
> Please.
>
> --
> Regards,
> Ryan
Reply | Threaded
Open this post in threaded view
|

Re: LuaBinaries and the RTL DLL for 5.2

Luís Eduardo Jason Santos
In reply to this post by Antonio Scuri
Antonio Scuri escreveu:
>
>   As always the problem is not the compiler. MingW still uses the
> MSVCRT.DLL.
>
In fact, MinGW lets you choose your C runtime at compilation time. (I
don't know exactly since when).
..  -lmsvcr90

--
Luís Eduardo Jason Santos
Reply | Threaded
Open this post in threaded view
|

Re: LuaBinaries and the RTL DLL for 5.2

Andrew Wilson-4
MSVC runtime usage for other Windows scripting solutions...

  Python 2.6 uses msvcr90.dll
  Strawberry Perl 5.10 uses msvcrt.dll
  Lua 5.1 (for windows) uses msvc80.dll

If perl can use msvcrt.dll why shouldn't Lua?

One argument that Lua, as an extension language, should be directly
linkable to existing software.
Another argument that Lua, as a standalone system, should use simplest
runtime environment with least dependencies.

Andrew

2010/1/15 Luís Eduardo Jason Santos <[hidden email]>:

> Antonio Scuri escreveu:
>>
>>  As always the problem is not the compiler. MingW still uses the
>> MSVCRT.DLL.
>>
> In fact, MinGW lets you choose your C runtime at compilation time. (I don't
> know exactly since when).
> ..  -lmsvcr90
>
> --
> Luís Eduardo Jason Santos
>
Reply | Threaded
Open this post in threaded view
|

Re: LuaBinaries and the RTL DLL for 5.2

Jerome Vuarand
In reply to this post by Ignacio Burgueño
2010/1/15 Ignacio Burgueño <[hidden email]>:
> On 15/01/2010 09:33, Jerome Vuarand wrote:
>
>> Another option is to remove the dependency on the VC runtime by
>> linking with the static libc (whatever the compiler used, VC8, VC9 or
>> GCC). I'm doing that to release small apps based on Lua, and it's
>> working great.
>
> Please correct me, but Lua + LuaFileSystem will never work. LFS needs to use
> the same C runtime that Lua uses.

I can't tell for sure, but from a quick look at the LFS manual I think
the lock, unlock and setmode functions will require a common C
runtime. I already used projects with Lua, LFS and the libc statically
linked in, but I never used these three functions.
Reply | Threaded
Open this post in threaded view
|

Re: LuaBinaries and the RTL DLL for 5.2

Jerome Vuarand
In reply to this post by Andrew Wilson-4
2010/1/15 Andrew Wilson <[hidden email]>:
> Generally I'd rather move to an open source compiler solution,I'd also
> like to get away from dependency on a specific MSVC runtime version.
> Is it possible to have MSWindows images that aren't dependent on a
> specific runtime version?

You can statically link in the C library, but you won't be able to
share objects managed by it (heap memory blocks, file handlers, etc.).
For memory that's not a problem since Lua frees itself all the memory
it allocates, and only that. For other objects it's up to the modules
to do it right (and I don't think extracting whatever C object is
embedded in a Lua 'file' userdata is a good idea).

> How broken is MSVCRT.DLL? Do these
> MSVCRT.dll issues cause real problems?

Problems can arise if you modules linked to different runtimes share
some C objects (e.g. file descriptors). Also not all runtimes are
pre-installed on all Windows, so that can be a deployment issue.
Reply | Threaded
Open this post in threaded view
|

Re: LuaBinaries and the RTL DLL for 5.2

Ignacio Burgueño
In reply to this post by Jerome Vuarand
On 15/01/2010 13:43, Jerome Vuarand wrote:

>
> I can't tell for sure, but from a quick look at the LFS manual I think
> the lock, unlock and setmode functions will require a common C
> runtime. I already used projects with Lua, LFS and the libc statically
> linked in, but I never used these three functions.
>

Indeed, those are the problematic functions IIRC (there was a message
some time ago on the Kepler list regarding this issue). Keep in mind
that the static single threaded C runtime is deprecated.



Reply | Threaded
Open this post in threaded view
|

RE: LuaBinaries and the RTL DLL for 5.2

Antonio Scuri
In reply to this post by Andrew Wilson-4
> MSVC runtime usage for other Windows scripting solutions...
>
>   Python 2.6 uses msvcr90.dll
>   Strawberry Perl 5.10 uses msvcrt.dll
>   Lua 5.1 (for windows) uses msvc80.dll
>
> If perl can use msvcrt.dll why shouldn't Lua?

  Well If Python uses msvcr90.dll why shouldn't Lua? :)

  BTW I guess that Python has a much more interesting distribution package
than Perl.

 
> One argument that Lua, as an extension language, should be directly
> linkable to existing software.

  But what existing software use as RTL? This is not easily answered.


> Another argument that Lua, as a standalone system, should use simplest
> runtime environment with least dependencies.

  Agree, don't get me wrong I would love to use MSVCRT.DLL but I still think
that there are more cons than pros.
 

> Andrew
>
> 2010/1/15 Luís Eduardo Jason Santos <[hidden email]>:
> > Antonio Scuri escreveu:
> >>
> >>  As always the problem is not the compiler. MingW still uses the
> >> MSVCRT.DLL.
> >>
> > In fact, MinGW lets you choose your C runtime at compilation time. (I
> don't
> > know exactly since when).
> > ..  -lmsvcr90
> >
> > --
> > Luís Eduardo Jason Santos
> >

Reply | Threaded
Open this post in threaded view
|

Re: LuaBinaries and the RTL DLL for 5.2

Jerome Vuarand
In reply to this post by Ignacio Burgueño
2010/1/15 Ignacio Burgueño <[hidden email]>:

> On 15/01/2010 13:43, Jerome Vuarand wrote:
>
>>
>> I can't tell for sure, but from a quick look at the LFS manual I think
>> the lock, unlock and setmode functions will require a common C
>> runtime. I already used projects with Lua, LFS and the libc statically
>> linked in, but I never used these three functions.
>>
>
> Indeed, those are the problematic functions IIRC (there was a message some
> time ago on the Kepler list regarding this issue).

And I guess that they're extracting (undocumented) information from
the file userdata created by the IO library. So the issue is not to
have LFS and Lua use the same runtime, but LFS and the standard io
module (I for one build all standard modules, including io, as
separate DLLs).

> Keep in mind that the
> static single threaded C runtime is deprecated.

I've been using the multi-threaded one.
Reply | Threaded
Open this post in threaded view
|

Re: LuaBinaries and the RTL DLL for 5.2

Petr Štetiar
In reply to this post by Antonio Scuri
Antonio Scuri <[hidden email]> [2010-01-15 02:01:27]:

Hi,

>   For those who use the LuaBinaries executables,

I use LuaBinaries just for testing as a scripting environment. No offence, but
I would never link to library I didn't compiled myself except for some
proprietary, closed source stuff.

>   I think it is time to move from vc8 (VS 2005) to vc9 (VS 2008) and the 5.2
> release is a great opportunity since it will force all modules to recompile
> anyway.

Why would you  want to force everybody to use VC9? I'm still happy with VC6,
but forced to use VC8 or higher versions just because other projects do so.

>   What do you think?

It's your project, you're making decision and I simply don't care, because I
don't link against LuaBinaries. As the enduser I would be happy to get new
versions of LuaBinaries and I nevermind which development environment it was
build on.

-- ynezz
Reply | Threaded
Open this post in threaded view
|

RE: LuaBinaries and the RTL DLL for 5.2

Antonio Scuri
In reply to this post by Andrew Wilson-4
> Generally I'd rather move to an open source compiler solution, I'd also
> like to get away from dependency on a specific MSVC runtime version.

  Ok, but GCC 4 is not stable in MingW. And I still believe that Visual C++
is the major compiler in Windows, it is not open source but it has a free
version.


> Is it possible to have MSWindows images that aren't dependent on a
> specific runtime version?

  If you want to get the best of the DLLs you must use a common RTL in a
DLL.


> How broken is MSVCRT.DLL? Do these MSVCRT.dll issues cause real problems?

  Yes they do. Specially if you go multithread. Since MSVCRT.dll does not
uses a manifest, I think that it cannot exist more than one in the system,
and there are applications who install their own version of MSVCRT.dll
breaking other applications.

Best,
Scuri

> Andrew
>
> On Fri, Jan 15, 2010 at 9:25 AM, Antonio Scuri <[hidden email]-
> rio.br> wrote:
> >   As always the problem is not the compiler. MingW still uses the
> > MSVCRT.DLL. This RTL has two great pros for re-distributing DLLs: it
> is
> > already installed on the system and does not depends on a manifest.
> This
> > would be heaven… But I think it has many cons.
> >
> >
> >
> >   It is an old DLL with known bugs and it is not maintained anymore.
> The
> > main development environment for Windows is still Visual C++. The
> free
> > Windows SDK already includes a command line version of VC. Visual C++
> > Express edition is a free fully featured IDE. And for those who are
> used to
> > develop in Visual C++ to build DLLs with several dependencies using
> gcc is
> > not an easy task.
> >
> >
> >
> >   BTW the official stable version of MingW still uses GCC version 3.
> I just
> > downloaded version 5.1.6 to check that. If I’m not mistaken GCC 4
> must be
> > manually installed.
> >
> >
> >
> >   Maybe in 2010 we see some improvements on that (VC or MingW). But
> for now
> > we have vc8 and vc9. So back to the issue, what do you think of
> moving from
> > vc8 to vc9?
> >
> >
> >
> > Best,
> >
> > scuri
> >
> >
> >
> > From: [hidden email]
> > [mailto:[hidden email]] On Behalf Of RJP
> Computing
> > Sent: sexta-feira, 15 de janeiro de 2010 02:27
> > To: Lua list
> > Subject: Re: LuaBinaries and the RTL DLL for 5.2
> >
> >
> >
> > On Thu, Jan 14, 2010 at 11:01 PM, Antonio Scuri <[hidden email]-
> rio.br>
> > wrote:
> >
> >  For those who use the LuaBinaries executables,
> >
> >  I'm about to release the LuaBinaries for 5.2.0-work2 and have a
> question
> > regarding the DLL dependency.
> >
> >  I think it is time to move from vc8 (VS 2005) to vc9 (VS 2008) and
> the 5.2
> > release is a great opportunity since it will force all modules to
> recompile
> > anyway.
> >
> >  What do you think?
> >
> >
> >
> > I vote to compile and release with MinGW GCC. Drop the tough VC RTL
> issues.
> > MinGW has updated to version 4.4 and is just as fast if not faster
> than VC.
> > Please.
> >
> > --
> > Regards,
> > Ryan

Reply | Threaded
Open this post in threaded view
|

Re: LuaBinaries and the RTL DLL for 5.2

RJP Computing
In reply to this post by Antonio Scuri


On Fri, Jan 15, 2010 at 9:25 AM, Antonio Scuri <[hidden email]> wrote:

  As always the problem is not the compiler. MingW still uses the MSVCRT.DLL. This RTL has two great pros for re-distributing DLLs: it is already installed on the system and does not depends on a manifest. This would be heaven… But I think it has many cons.

Those pros out way the cons by a long shot for many. In fact the manifests caused so many issues because MS pushed updated to your machine that are not labeled as run-time updates and uprev the run-time version. [1](See the comments too)

   It is an old DLL with known bugs and it is not maintained anymore. The main development environment for Windows is still Visual C++. The free Windows SDK already includes a command line version of VC. Visual C++ Express edition is a free fully featured IDE. And for those who are used to develop in Visual C++ to build DLLs with several dependencies using gcc is not an easy task.

The same things can be said for GCC though. It has many free and good IDEs. The compiler has always been free. etc... In my experience the age of the run-time has never caused issues. Do you have specific cases where this has been an issue for you?

   BTW the official stable version of MingW still uses GCC version 3. I just downloaded version 5.1.6 to check that. If I’m not mistaken GCC 4 must be manually installed.

Yes you need to manually install, but I found an installer from GCC 4.4.x. But from reading the mailing list it is clear to me that they are not going to release an installer anymore (which is a shame, but doesn't change the fact that GCC3.x is not the official release anymore) On the mailing list they clearly state that GCC 3 is not the official release. You can see this in the file release section of SourceForge. The GCC v4.x is not a "technology preview" anymore.

  Maybe in 2010 we see some improvements on that (VC or MingW). But for now we have vc8 and vc9. So back to the issue, what do you think of moving from vc8 to vc9?

I didn't notice any improvement as I am testing the beta of VS2010. Just another run-time to choose from.
--
Regards,
Ryan

Reply | Threaded
Open this post in threaded view
|

Re: LuaBinaries and the RTL DLL for 5.2

Petr Štetiar
In reply to this post by Ignacio Burgueño
Ignacio Burgueño <[hidden email]> [2010-01-15 12:07:58]:

> I would miss, though, being able to debug using Visual Studio.

Take a look at QtCreator. It's opensource, uses MinGW and gdb as debugger. BTW
it can use also MS compiller and debugger.

-- ynezz
12