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
