Re: Using Lua in dynamic modules with static linking

[William Ahern <william@...>]

On Wed, Feb 27, 2019 at 10:31:17AM +0100, Viacheslav Usov wrote:
> On Tue, Feb 26, 2019 at 1:42 PM Chris Smith <space.dandy@icloud.com> wrote:
> 
> > 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
> :)

Solaris and Linux/glibc have dlmopen, which loads a shared object in a
unique symbol namespace. This permits loading a module with its own exported
Lua symbols (which could have been dynamically loaded as a shared library
dependency), and it could dynamically load more modules, including Lua
modules. I think you'd need to ensure that code within this namespace
consistently used dlmopen with the correct identifier, perhaps by patching
Lua or interposing dlopen.

I've never tried dlmopen so can't testify to its reliability.