I'm at a loss. The app can use Lua as a DLL or by statically linking with it. The module can use Lua as a DLL or by statically linking with it. This gives 4 possible configurations. The _only_ one that works is the case where both the app and the module use Lua as a DLL, because in this case the app and the module can share the Lua code, which is what Kevin eluded to. If the app is using Lua by statically linking with it, then I have idea how to write my module so that it doesn't define duplicate symbols.
From: spencerparkin@outlook.com To: lua-l@lists.lua.org Date: Sat, 23 Mar 2013 19:52:31 -0600 Subject: RE: C++ Lua modules not compatible with every Lua interpreter?
Thanks Kevin. So if I'm not supposed to statically link my module DLL against the Lua library, then what am I supposed to link it against to get it to compile? Hopefully that's not a dumb question. Maybe I'll go ahead and take a look at what functions my DLL is using, and then try to only link against the lua (c->obj) files in the Lua distribution that implement those functions.
From: kev82@khn.org.uk Date: Sat, 23 Mar 2013 22:31:49 +0000 To: lua-l@lists.lua.org Subject: Re: C++ Lua modules not compatible with every Lua interpreter? On 23 Mar 2013, at 21:53, Spencer Parkin wrote:
Surely a compatibility issue arises when a Lua module was written for one version of Lua while you're trying to use it with some other version of Lua
Yes, I believe the solution is to build a version of the module against each version of Lua you want to tun.
In my admittedly simplistic view of Lua, there are just two different ways to compile the interpreter. The first statically links the Lua VM into the interpreter. The second builds an interpreter that run-time links with the Lua VM built as a shared library.
I not clear on what you mean by the VM and interpreter. In my head the VM is the bit that executes bytecode, but it's not really separable from the rest of the library. I don;' know what the interpreter is, as Lua is compiled, not interpreted.
The application using the Lua library can link to the library statically or dynamically, yes.
Now, what I've noticed is that if I write a C++ Lua module, it will only run with interpreters built in the latter style.
On my system, the Lua application is compiled statically with the Lua library (I think this is generally true) and has no issue loading modules dynamically. An application in which we embed Lua, links to the library dynamically, and can also load modules without issues. So I think it's your problem. Attempting to run my module with an interpreter built in the former style, I encounter the error, "multiple VMs detected", and the interpreter bails out.
If you type that error into Google, one of the first links is this http://stackoverflow.com/questions/14213559/lua5-2s-error-multiple-lua-vms-detected in which someone points out that the module is being linked against the Lua library, which it shouldn't be. This will cause there to be duplicate symbol definitions (one from app, one from module). I guess you're doing the same thing? I would hope that my module, however, would be compatible with any Lua interpreter.
It will work with the API it was compiled against. Did I make a mistake in creating/compiling/linking my C++ Lua module?
Probably, see the link 2 points above. Is the mistake I've made that of somehow creating an unneeded dependency between my module and the VM? Surely my C++ Lua module needs access to Lua functions.
The embedding application will have the Lua library in it (whether statically or dynamically linked), therefore, when the model is loaded, it will access the symbols through the application.
Anyhow, my question, simply put, is: how does one properly write a C++ Lua module that is compatible with any Lua interpreter, no matter how that interpreter was built?
See the above link, essentially don't like the module with Lua.
Kevin |
