Re: LuaRocks with Windows/Visual Studio

[Ross Berteig <Ross@...>]

Sometime on 9/4/2008, "Mark Meijer" <meijer78@gmail.com> wrote:
>2008/9/3 Ross Berteig <Ross@cheshireeng.com>:
>> Unfortunately, once you get into an open system where it is
>> expected that other components just plug in, then everything
>> that loads within a single process must comply with the same
>> standards.
>
>I'm assuming that standard for LuaRocks on Windows is MSVCRT80.DLL,
>for the provided interpreter (LuaBinaries) as well as any 
precompiled
>dll's in the default repository (is this true?). However:

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.

>2: Use MinGW and two different C runtimes.

Better, use MinGW and get the linkage right so that you only use
one runtime. It is easiest, of course, to just use MSVCRT.DLL in
this case, since you don't have to worry about getting the
linkage right. Of course, you then need to build Lua and all DLLs
yourself, and possibly deal with any that have portability issues
if they depended on a feature of VS2003 or later.

>3: Go the cygwin route.... This is assuming it solves the
>problems of both options 1 and 2, though I don't know that it
>actually does.

Nope. You still have all the same kinds of runtime environment
compatibility issues. If you compile everything yourself, then
you are fine. The moment you use something compiled by anyone
else, then you have to make sure they made the same runtime
assumptions you did.

If you compile under Cygwin with the -mno-cygwin option, then you
are really just using MinGW from the Cygwin shell, and still have
to choose among the CRT versions and check to make certain that
the result is clean and consistent.

>4? Realizing that LuaRocks has only recently hit version 1.0,
>wait for some future version (of LuaRocks and/or some policy for
>inclusion of rocks in the default repository) to somehow solve
>this? (what are my chances here...?)

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.


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