> I think the best way of doing this is to statically link both the application and the module against the Lua libraries.
As said by the others, there is a way to make this approach work. What you should also consider is the eventual need to use non-pure-Lua libraries. When both the main executable and the dynamic modules link Lua statically, they will have to link those libraries statically, too. Or, if you find a robust way to link Lua statically yet load non-pure-Lua libraries dynamically, I would very much appreciate having a look at your achievement :)
For my use case, Lua will never have to load binary libraries. If something can’t be done in pure Lua then my embedding application will implement it and inject a C function into the environment.
However, considering the problem anyway, I assume the issue is that if Lua is linked statically, then a binary module won’t have access to the Lua API? (There will be no reverse bindings, for want of a better term?) In that case, my first inclination would be to use traditional ‘interface’ semantics: pass a structure to the module on initialisation that contains the Lua state and pointers to the Lua API functions. That would provide a cleaner separation between module and application and allow for backwards compatibility if you update the Lua version used by application. This does imply that you have control over the modules as well, though — it wouldn’t work for a random third-party module.
Regards, |
