Hi, folks
Let me put something into discussion.. please, tell me if I am talking
nonsense.
I will start by the end of the story: wouldn't it be a good thing to,
while loading binary modules via require(), indicate a set of lua
function addresses for this module to bind to? Namely: the LuaVM.
Now the beginning:
We work with lua for about an year now. We use the MinGW toolset to
build our products for the windows platform. Our applications are made
to have minimal system and enviromental dependencies. As a result of
that constraint we statically built the luavm into our executables. The
collateral effect is that, whenever I try to use some binary module
compiled elsewhere we used to have some strange errors. Initially we
thought the problem was binary compatibility between the executables
built with different compilers, but then I thought "hey! this is C, not
C++". And indeed, BPI was not a issue in this particular case. Nor I
believe was the runtime - for MinGW binds to MSCRT.DLL, as well as MS
Visual C 6.
The it hit me: Lua modules were built using lua5.1.dll binding, and my
executable was not. Easy solution: I would have to build all my modules
again with static linking, right? Not quite.
Some of them worked, but some of them don't.
As I tried to make the time for a more controlled experience I had the
idea: what if the LuaVM control data were standing on two different
sets of memory addresses? I would probably mean that, even if both
modules shared the LuaState (which we pass on every function) there
must be some internal control for the LuaVm that hasn't been shared,
thus creating a very tricky problem. but how would we solve it?
There could be only one answer: to be able to change somehow the
addresses on the modules at runtime. For that, we would have to,
either, build them bound to an independent set of functions -
LuaVM-neutral functions - or build them with some sort of virtual LuaVM
, that would be set at load time to the currrent LuaVM .
What do you think?
--
Luís Eduardo Jason Santos