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.
Date: Sat, 23 Mar 2013 22:31:49 +0000
Subject: Re: C++ Lua modules not compatible with every Lua interpreter?
On 23 Mar 2013, at 21:53, Spencer Parkin wrote:
Yes, I believe the solution is to build a version of the module against each version of Lua you want to tun.
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.
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.
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?
It will work with the API it was compiled against.
Probably, see the link 2 points above.
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.
See the above link, essentially don't like the module with Lua.