[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Windows DLLs for LuaBinaries with GCC and MSVCR80.DLL
- From: Ross Berteig <Ross@...>
- Date: Fri, 20 Jun 2008 15:24:22 -0700
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
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
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/