Re: How to avoid DLL hell?

[Fabio Mascarenhas <mascarenhas@...>]

On Fri, Nov 26, 2010 at 9:43 AM, Pavel Holejsovsky
<pavel.holejsovsky@gmail.com> wrote:
> On 11/26/2010 11:19 AM, Enrico Colombini wrote:
>>
>> Do you mean I can use a Lua executable + DLL compiled with mingw32 +
>> MSVCRT and load, say, lfs (or any other Lua library, such as wxLua)
>> compiled with the lastest VC and runtime (or vice versa) with no trouble?
>
> Yes.  The only problem with mixed allocator happens if one chunk of memory
> is allocated by runtime A and freed by runtime B.  This is not the case in
> your scenario; all memory allocated by Lua is allocated and freed by the
> allocator from runtime against which is *lua runtime* linked; the runtime to
> which is calling extension/application linked does not matter.

The problem is not just memory... the layout of C runtime structures
(FILE, for example) can also be different. lfs.lock, for example, may
not work if lfs was compiled with a different C runtime as the Lua
DLL, because it shares FILE structures with the Lua IO subsystem. File
descriptors are also problematic.

Most Lua modules won't have a problem being linked with a different C
runtime, though, as long as everything is sharing the same Lua DLL.

>> Does this also apply if Lua is statically compiled (no Lua DLL)?
>
> No. Actually, statically compiled Lua means that Lua runtime is statically
> linked ... into what?  Main application?  Ok, but in this case it is not
> reachable to any loadable module.  This would mean that every loadable
> module would have to carry its own copy of Lua runtime (either statically or
> dynamically linked), and you'd have to ensure that these runtimes are
> compatible and linked against the same C runtime. You are basically
> *creating* the problem here you were originally trying to solve; i.e. now
> you have more instances of (this time Lua) runtimes operating on shared
> state.

Actually having multiple copies of the Lua runtime is *VERY* bad,
independently of whether they use the same C runtime or no. There are
several documented cases on this list. Either compile everything
against the same Lua DLL, or compile everything statically and do not
use DLLs at all.

--
Fabio Mascarenhas