lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Sometime on 9/3/2008, David Given <> wrote:
>>Ross Berteig wrote:
>> However, getting MinGW to properly link against MSVCR80.DLL (or 
>> any of the newer MS CRT flavors) remains a bit of a pain.
>I had absolutely no trouble with this --- I just compiled it and it
>worked. There don't even seem to be any dependencies on the MingW
>runtime DLL. I'm not well up on Windows toolchains, so I could 
>well be making a static executable, but the entire program comes 
>out as a single 266kB binary --- and that includes a Lua interpreter 
>and 5600 lines of Lua bytecode embedded in it.

Right. That is use case #1, where you just want a self-contained, 
working, Windows-platform-portable binary. In that case, the 
MinGW version of libc is a collection of aliases for (and thin 
veneer over) the functions provided by MSVCRT.DLL. That was the 
CRT for VC6, and is now a system component and installed on Win2K 
(I think), WinXP, and Vista along with the OS.

However, LuaBinaries have moved on to a more current runtime 
library. So if you want to build either an application containing 
Lua that can load LuaBinaries-compatible module DLLs, or a DLL 
for use by a LuaBinaries-compatible host application, then you 
need to be able to link code against the matching CRT DLL or all 
kinds of hard to diagnose bugs can occur.

To validate the implicit DLL linkage, you need a tool called 
Dependency Walker, which is included in the MS Platform SDK, and 
available (with improvements) at 
(There is also a tool called cygcheck in Cygwin that can be used 
to do the same verification, IIRC.) It will show you that using 
the off-the-shelf MinGW with -lmsvcrt80 gets you applications and 
DLLs that are *mostly* free of dependency on MSVCRT.DLL. Getting 
them completely free requires more effort.

Ross Berteig                     
Cheshire Engineering Corp.