Re: A crash when loading dll from LuaJIT (works with "regular" Lua)
- From: Mike Pall <mike-1212@xxxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Mon, 31 Dec 2012 14:00:41 +0100
Paul Kulchenko wrote:
> So, what is the right method to do this? I need to be able to
> provide my own DLL (and .so and .dylib) that works with engines
> that have Lua VM statically compiled in (like it's done in
> love2d or gsl-shell)
I'm moderately sure these provide either a proxy luaXX.dll for
loadable C modules or they simply don't allow those.
In Windows, all symbols are tagged with a DLL name and unbound
symbols will only resolve towards that DLL. In ELF/MACH-O systems,
symbols are untagged (global) and will resolve to whatever global
symbol is already present. That way it works with either a VM
that's part of the executable or that's part of a shared library.
For Windows, you have to play games with proxy DLLs to make that
work at all.
> Is there a proper way to accommodate all these cases? Or should
> I simply provide two different dlls linked statically against
> lua and lujit and switch at run time if luajit is detected? I've
> read various wiki pages on building lua proxy dlls, but they
> cover a slightly different issue.
You must not, under any circumstances, load two copies of either
Lua or LuaJIT or a mix of both into the same address space and use
them with the same Lua state. Statically linking any VM into a DLL
is a recipe for disaster, in case there's another VM loaded from
an executable or a luaXX.dll (i.e. always for your use case).
--Mike
Other related posts:
