According to Luiz, (not sure if I've offended him yet), the app that embeds Lua and that would load my DLL module should be compiled with "-Wl,-E". Of this the docs say... (italics added)...
-E
--export-dynamic
-
When creating a dynamically linked executable, add all symbols to the
dynamic symbol table. The dynamic symbol table is the set of symbols
which are visible from dynamic objects at run time.
If you do not use this option, the dynamic symbol table will normally
contain only those symbols which are referenced by some dynamic object
mentioned in the link.
If you use
dlopen to load a dynamic object which needs to refer
back to the symbols defined by the program, rather than some other
dynamic object, then you will probably need to use this option when
linking the program itself.
Hmmm. I wonder how I do this with Dev-Studio's linker. So...i tried my module with two different apps that use lua. The first was the lua.exe that compiles with LuaPlus. Perhaps it wasn't linked with the option named above? The second was with a lua.exe I created myself from the Lua sources that loads Lua as a DLL. The latter worked, of course, while the former failed with the duplicate VMs error. I guess my next step is to try compiling my lua.exe by statically linking it with Lua, but also somehow export all symbols to the symbol table so that when my DLL is loaded by lua.exe, it doesn't go out and load it lua as a DLL, because it will already find the symbols it needs in the lua.exe? Sorry, people are probably hating me more and more because of all the spam e-mail i'm sending to the list about this. I'll shut-up now unless anyone happens to respond.
From: spencerparkin@outlook.com To: lua-l@lists.lua.org Date: Sat, 23 Mar 2013 21:23:03 -0600 Subject: RE: C++ Lua modules not compatible with every Lua interpreter?
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 |
