 |
lua-l archive |
|
|
||
|
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.
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.
IMHO statically linking Lua runtime makes sense only when everything else is also statically linked in, i.e. no dynamically loaded modules are allowed.
Pavel