lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Fri, Nov 26, 2010 at 9:43 AM, Pavel Holejsovsky
<> 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