That is the case at the moment. Of course, at some point
MSVCR80.DLL will be out of date. VS2008 uses MSVCR90.DLL by
default, for instance, and the next version of VS will likely
include a yet newer CRT. Scuri builds LuaBinaries for a
disturbingly large number of compilers and runtime libraries on
Windows alone, but LfW has standardized on MSVCR80.DLL
(technically the SxS assembly known as Microsoft.VC80.CRT) as the
preferred runtime for their package.

Any library that is intended to just work with LfW must be
buildable against that CRT. Any binary distribution of such a
library must be built against that CRT.

>> 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.
>
>What I understand from this, is that any rocks I install (compile)
>using MinGW will either depend on an old VC6 runtime (MSVCRT.DLL), or
>on *both* the old and the new one (MSVCRT80.DLL), depending on
>whether or not by whatever magic the -lmsvcrt80 option is used.

It is clear that the MinGW team was trying to make -lmsvcrt80 be
sufficient to eliminate dependency on the old CRT. Unfortunately,
they missed a couple of things, and if you step on one of those
your program still links but is now dependent on both CRT
versions in an unhealthy way.

Under the covers, MSVCR80.DLL itself is linked against
MSVCRT.DLL, but that dependency is presumably healthy because it
came from MS that way, and MSVCRT.DLL is a system component
installed in C:\Windows\System32. Of course, since exactly one
function (named _getdrives()) is imported implicitly from the old
runtime, it is completely possible that this is due to an
oversight and has never been corrected because it doesn't
actually cause problems.

Steve Donovan (IIRC) identified a list of 19 CRT functions that
have their names incorrectly documented in MSVCR80.DLL, and hence
they are mis-wrapped in libmsvcr80.a. Using any of those
functions will produce a dependency on MSVCRT.DLL, and in some
cases will cause the implementations of malloc() and free() to be
mixed between the two CRT versions which cannot be good even if
it appears to work.

In my projects, I follow Steve's list of functions to alias with
macros at compile time, and use a link line that ends with:

       $(LUADLL) -lgcc -lmsvcr80 $(MSVCR80)

Where LUADLL is a fully qualified name of lua.5.1.dll and MSVCR80
is the fully qualified name of MSVCR80.DLL. Since I use LfW, I
find both of those DLLs in its installed tree, based off the
LUA_DEV environment variable it defined. The result is a
dependency tree that has two implicit loads of MSVCR80.DLL, and
only loads MSVCRT.DLL due to MSVCR80's need. If I leave out
libgcc.a or otherwise move it after either reference to MSVCR80,
then I find unhealthy dependencies on MSVCRT.DLL.

Your mileage will vary, so I strongly recommend checking DLL
dependency carefully before releasing a binary.

I suppose I ought to go put this into the wiki page... (see
http://lua-users.org/wiki/BuildingModules).

>And if I use
>Visual Studio, many rocks will not compile at all. So.... stop me if
>I'm missing something, but basically my choices are:

LuaRocks is still young. Personally, my hope is that Lua for
Windows will adopt LuaRocks on the Windows platform. Even then,
it is going to take some effort to make sure that binary
compatible rocks are available so that the end users do not need
to recompile rocks themselves. That will take all the pressure
off the end users, and put it on the maintainers of the LuaRocks
repository.

However, builders of rocks still have to deal with the issues you
are worried about, and so far LuaRocks is not the whole answer.

>1: Use Visual Studio and not a lot of rocks....

At the moment (ca. v1.0), LuaRocks sort of assumes that the
Windows platform implies that you have VS installed and
available. If you get it installed and working, then just using
VS for your own project work should work out ok.

<snip>

Ryan has said that LuaRocks is in his plans for Lua for
Windows... We all just need to gently encourage that because the
combination will be ideal. The end user gets an easily installed
and complete Lua, and then can extend it at will from the
community of modules, which then keep themselves up to date.