Re: Using Lua in dynamic modules with static linking

[William Ahern <william@...>]

On Wed, Feb 27, 2019 at 05:04:19PM +0000, Chris Smith wrote:
> > On 27 Feb 2019, at 09:31, Viacheslav Usov <via.usov@gmail.com> wrote:
> > 
> > On Tue, Feb 26, 2019 at 1:42 PM Chris Smith <space.dandy@icloud.com <mailto: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 :)
> 
> 
> 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.

And if you have control over the module itself it would be easier to just
tweak the build and statically link it. The Debian Lua policy requires all
binary Lua module packages to build .a archives precisely so you can
statically link Lua modules.

Unfortunately, too many Lua modules unintentionally export their internal
routines (i.e. don't use static scope or don't provide the ability to
control visibility with macros like FOO_API and FOO_LOCAL). Some
distributions' Lua packages also miscompile liblua.a (e.g. Red Hat's) so
that it's useless for use in a multiple Lua library context. So you're stuck
building from source, patching the code or using linker scripts to control
scope.

If you write Lua C modules (or any C module or library), it's good practice
to prefix FOO_API (or FOO_PUBLIC) to your public interfaces and FOO_LOCAL to
non-static scoped internal interfaces. Even on systems that support a linker
script to enumerate exported interfaces, it still provides useful
flexibility to downstream packagers and builders.

See my post elsethread regarding the dlmopen alternative.