Yes, I'm that same Spencer Parkin that offended the creators of Lua on this mailing list a few weeks ago. Assuming I haven't alienating everyone on the list, a question follows...
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, but the Lua version is not the issue here. The issue is that of encountering multiple VMs.
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. 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. 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. I would hope that my module, however, would be compatible with any Lua interpreter. Did I make a mistake in creating/compiling/linking my C++ Lua module? 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.
I can see, I think, why my module is working with Lua interpreters built to run-time link against the VM. The interpreter starts up, loads it's VM as a DLL, then load's my module as a DLL, which in turn requests a load of the already-loaded VM as a DLL, and so the OS is smart enough to say, "Mr. process, you already have that DLL loaded. Here's the handle.", and so the process never uses two different copies of the same VM. Something to that affect, perhaps. I don't know.
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?
--Spencer <-- Complete and utter jerk.