Re: msvc*.dll versioning conflicts

["Paul Moore" <p.f.moore@...>]

On 05/08/2008, David Manura <dm.lua@math2.org> wrote:
> Since the msvc*.dll issue is becoming a recurring topic, some notes/links are
> now collected here: http://lua-users.org/wiki/BuildingModules .  Feel free to
> expand.

The big problem I find isn't generally with standalone Lua, but with
embedding. I had some very bizarre crashes from Lua when I used
modules (or the Lua DLL) built with msvcr80 embedded into an
application which didn't use the MS C runtimes at all (it uses direct
Win32 API calls, so I understand). My guess is that this is because
msvcr80 expects to have had some initialisation done at application
startup time, which isn't done when it's loaded as part of a DLL load
(the embedded Lua). But that is nothing more han a guess.

My experience is that msvcrt (the VC6/mingw default) is far less prone
to such oddities.

> Though it's quite preferable to use the same C runtime, in theory I see nothing
> incorrect with mixing libraries linked against different C runtimes provided
> some strong assurances are given from those libraries.

But isn't the whole issue that MS don't *give* such assurances???

>  Perhaps it's ideal, *when possible*, for a C extension DLL to dynamically link to
> no C run-time at  all (i.e. /nodefaultlib /entry:... linker options in MSVC).  It may
> be worthwhile for someone to clarify this all in practice.

Possibly, but Lua needs a C runtime from somewhere. Statically linking
it doesn't help, and dynamic linking needs something.

To be honest, my view is that msvcrt is by far the best option. Except
that MS compilers no longer use it. Does anyone know a way of
persuading newer MS C compilers to use it?

Paul