Windows DLLs for LuaBinaries with GCC and MSVCR80.DLL

[Ross Berteig <Ross@...>]

The subject of Lua's C Runtime dependance has come up in the 
past, especially in the context of trying to build a module with 
GCC instead of Visual Studio 2005 or later. This is important 
because GCC defaults to an older version of the C runtime DLL, 
which can become a source of extremely difficult to track down bugs.

Past versions of LuaBinaries distributions for Windows were 
simpler to deal with. The popular package depended only on 
MSVCRT.DLL which is now a system component of Windows and can be 
assumed to be present on any healthy Windows installation. Since 
GCC as distributed by both the MinGW project and Cygwin defaults 
to that same runtime DLL, everything just works.

The distributions for Lua 5.1.3 have moved (and probably 
sensibly) to assuming MSVCR80.DLL is present, and provide the 
required manifest resource to properly handle side by side 
versioning of the runtime. This does require that C modules be 
at minimum relinked with the correct C runtime DLL. For modules 
that were developed under Visual Studio in the first place, this 
isn't a huge burden. However, it isn't obvious how to achieve 
this for modules developed with GCC. One answer is to just port 
the module to Visual C, but that assumes that you are willing 
and able to add a Visual Studio installation (even the free VS 
is a heavy download) and that you didn't depend in some way on a 
GCC-specific feature. The better way would be to teach GCC to 
use the new C runtime.

Surprisingly, this turns out to be easy to do with from both 
MinGW and Cygwin. I have verified that it works for building 
DLLs by profiling lua5.1.exe from LuaBinaries loading a simple C 
module using the MS Platform SDK tool Depends.exe which can 
track all references to DLLs and reports the true dependencies.

The recipe for GCC from MinGW is:

        gcc -o my.dll -shared my.o ... /path/to/lua/lua5.1.dll 
-lmsvcr80

If building on Cygwin for use outside of the Cygwin environment, 
you want to include the -mno-cygwin option as well.

Naturally you will need to add at least one -I option to refer 
to your Lua distribution's include folder, as well as properly 
identifying lua5.1.dll.

Since your DLL has to be hosted by some application that uses 
Lua, you don't need to worry about SxS (side by side 
assemblies), manifests, or any of the other interesting 
complications introduced in recent versions of Windows. Having 
linked against the right C runtime, it looks like all the right 
linkages just magically happen at run time.

The story for building and distributing a complete application 
with GCC for MSVCR80.DLL is more complicated, but I think that 
is sufficiently far away from the topic to be left for another day.

Ross Berteig                               Ross@CheshireEng.com
Cheshire Engineering Corp.           http://www.CheshireEng.com/