Re: Statically linked executables

[William Ahern <william@...>]

On Tue, Jun 27, 2017 at 12:47:23PM -0700, orenbenkiki wrote:
> I just created stubs similar to the above (I also added printing logging nice
> error messages, just in case...) and it works fine so far.
> 
> Stubbing `-ldl` would seem to be the recommended way to provide a fully
> statically linked executable with embedded Lua, then.
> 
> Many thanks!

Recommended in so far as you have no control over how Lua is compiled.
Presumably you're using a system-managed Lua that was compiled with dynamic
module support. But if you control how Lua is compiled then the recommended
method would be as Luiz and Roberto describe.

FWIW, IMHO, most Linux distributions do a horrible job of packaging Lua.
Debian only recently recognized Lua 5.1, 5.2, and 5.3 as wholly distinct
languages, finally treating them similarly to Python 2 and 3. So Lua 5.1 is
installed as liblua5.1.so and liblua5.1.a with headers under lua5.1/, and
dependent Lua 5.1 modules require liblua5.1 or liblua5.1-dev. Moreover,
Debian Stretch changed the packaging policy so that installing a Lua library
package like lua-foo will install modules for Lua 5.1, 5.2, and 5.3 (if
possible), which brings them full circle--they both recognize that Lua 5.1,
5.2, and 5.3 are distinct, but actually attempt to address packaging
confusion of those unfamiliar with the details of Lua versioning.

Red Hat- and Fedora-based distributions still treat the Lua 5.x series as a
single language, and largely for that reason still require third-party
packages for Lua 5.2 and Lua 5.3. By their reasoning Lua 5.2 or 5.3 would
necessarily replace Lua 5.1 (i.e. the lua and lua-devel packages are
implicitly Lua 5.x), which they don't want to do because too many apps rely
on the Lua 5.1 API and won't be upgraded. The circular reasoning is
mind-boggling. But in any event they're committed to the notion (AFAICT,
primarily out of ignorance) that there should be a single lua package, and
so IMO Red Hat and Fedora distributions have a fundamentally broken Lua
packaging policy.

Also, inexplicably, on Red Hat- and Fedora-based distributions /usr/bin/lua
has an RPATH set to /usr/lib64, which breaks search ordering viz-a-viz
LD_LIBRARY_PATH. The proper way to add an explicit library search directory
for an interpreter is to set RUNPATH (not RPATH), as RUNPATH doesn't
override LD_LIBRARY_PATH. Both Perl and Python uses RUNPATH, even on Red Hat
and Fedora. This is more evidence regarding the brokeness of Red Hat's Lua
packaging, especially given how odd it is to hardcode /usr/lib64 in the
interpreter at all. Perl and Python set RUNPATH in order to make visible
non-standard directories (e.g. /usr/lib64/perl5/CORE). They don't have a
RUNPATH to /usr/lib64.

NetBSD arguably made the same mistake when importing Lua into their base
system as "-llua". Though at least they've moved to Lua 5.3. Perhaps they
knew what they were doing. Given that NetBSD base is one monolithic project
and that they already made the leap to 5.3 without changing library names it
might have been a knowing, intentional, and perhaps defensible choice.