Re: C++ Lua modules not compatible with every Lua interpreter?

[Paul K <paulclinger@...>]

> 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?

Maybe this can help: http://lua-users.org/wiki/LuaProxyDllFour?

Paul.

On Sat, Mar 23, 2013 at 9:04 PM, Spencer Parkin
<spencerparkin@outlook.com> wrote:
> 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