|
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
|