Question

I’m getting errors in the lua plugin that I’m writing that are symptomatic of linking in two copies of the lua runtime, as per this message:
http://lua-users.org/lists/lua-l/2008-01/msg00671.html

Quote:

Which in turn means the equality test for dummynode is failing.
This is the usual symptom, if you’ve linked two copies of the Lua
core into your application (causing two instances of dummynode to
appear).

A common error is to link C extension modules (shared libraries)
with the static library. The linker command line for extension
modules must not ever contain -llua or anything similar!

The Lua core symbols (lua_insert() and so on) are only to be
exported from the executable which contains the Lua core itself.
All C extension modules loaded afterwards can then access these
symbols. Under ELF systems this is what -Wl,-E is for on the
linker line. MACH-O systems don’t need this since all non-static
symbols are exported.

This is exactly the error I’m seeing… what I don’t know is what I should be doing instead.

I’ve added the lua src directory to the include path of the DLL that is the c component of my lua plugin, but when I link it I get a pile of errors like:

Creating library file: libmo.dll.a
CMakeFiles/moshared.dir/objects.a(LTools.c.obj): In function `moLTools_dump':
d:/projects/mo-pong/deps/mo/src/mo/lua/LTools.c:38: undefined reference to `lua_gettop'
d:/projects/mo-pong/deps/mo/src/mo/lua/LTools.c:47: undefined reference to `lua_type'
d:/projects/mo-pong/deps/mo/src/mo/lua/LTools.c:48: undefined reference to `lua_typename'
d:/projects/mo-pong/deps/mo/src/mo/lua/LTools.c:49: undefined reference to `lua_tolstring'

So, in summary, I have this situation:

1. A parent binary that is statically linked to the lua runtime.

2. A lua library that loads a DLL with C code in it.

3. The C code in the DLL needs to invoke the lua c api (eg. lua_gettop())

How do I link that? Surely the dynamic library can’t ‘see’ the symbols in the parent binary, because the parent binary isn’t loading them from a DLL, they’re statically linked.

…but if I link the symbols in as part of the plugin, I get the error above.

Help? This seems like a problem that should turn up a lot (dll depends on symbols in parent binary, how do you link it?) but I can’t seem to see any useful threads about it.

(before you ask, no, I dont have control over the parent binary and I cant get it to load the lua symbols from the DLL)

Answer 1

It’s probably best to use libtool for this to make your linking easier and more portable. The executable needs to be linked with -export-dynamic to export all the symbols in it, including the Lua symbols from the static library. The module needs to then be linked with -module -shared -avoid-version and, if on Windows, additionall -no-undefined; if on MacOS, additionally -no-undefined -flat_namespace -undefined suppress -bundle; Linux and FreeBSD need no other symbols. This will leave the module with undefined symbols that are satisfied in the parent. If there are any missing, the module will fail to be dlopened by the parent.

The semantics are slightly different for each environment, so it might take some fiddling. Sometimes order of the flags matters. Again, libtool is recommended since it hides much of the inconsistency.