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

[Spencer Parkin <spencerparkin@...>]

Thank you for the link.

After reading that and LuaProxyDLL(1-3), and reading about the Visual Studio linker's inability to automatically export all symbols into the dynamic symbols table (which capability is enjoyed by the Linux linker), I get the feeling that this problem of run-time linking has been gracefully solved on Linux, but not on windows, and that on windows one must resort to a number of hacks to make a Lua language extension module work for any given app that embeds Lua, if it does so statically.  At this point I feel that the best I can do is to given a requirement of my extension module as being that of only runnable in an app on windows that dynamically links with lua52.dll.  Perhaps run-time linking technology is behind on windows.

> Date: Sat, 23 Mar 2013 21:50:23 -0700
> From: paulclinger@yahoo.com
> To: lua-l@lists.lua.org
> Subject: Re: C++ Lua modules not compatible with every Lua interpreter?
>
> > 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
>