lua-users home
lua-l archive

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

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                     
Cheshire Engineering Corp.