Re: LuaJIT and symbol versioning

  • From: Nagaev Boris <bnagaev@xxxxxxxxx>
  • To: luajit@xxxxxxxxxxxxx
  • Date: Sun, 16 Aug 2015 12:16:52 +0300

On Sun, Aug 16, 2015 at 12:04 PM, Enrico Tassi <gares@xxxxxxxxxxxx> wrote:

Hello LuaJIT experts, I package Lua and LuaJIT for Debian and I need
some guidance with respect to the symbols LuaJIT provides.

First, why symbol versioning. The Debian archive contains various Lua
versions (5.0 --> 5.3) compiled as shared libraries and they have symbol
names in common (e.g. luaopen_io). If a process happens to be linked
with both libraries, symbols are not correctly resolved at load time.
Note that this can happen indirectly: you link libA and libB, that in
turn happen to be extensible with, respectively, Lua 5.1 and 5.2.
The "solution" is to version symbols (ld flag --version-script) so
that symbols from 5.1 are morally named something like
luaopen_io@LUA_5.1 and the ones from 5.2 like luaopen_io@LUA_5.2, so
symbol resolution can work properly.

I'd like to version the symbols in the LuaJIT shared library too, with
label LUAJIT_5.1, so that if one happens to link both Lua and LuaJIT
symbols are not wrongly chosen by the loader. I've two questions:

Could you provide a use case of using both Lua 5.1 and LuaJIT in same

LuaJIT is binary backward compatible with Lua 5.1. Lua modules
compiled with Lua 5.1 can be loaded with LuaJIT. This feature would
not work if LuaJIT had another symbol label.

1. Would that work? Maybe there are other reasons that make LuaJIT and
Lua 5.X impossible to load in the same address space.

2. I've noticed that LuaJIT exports a few more symbols, and I don't know
what to do with them. In particular, here an excerpt from the
version-script I'm preparing, with questions in comment:

LUAJIT_5.1 {
/* Lua 5.1 symbols */

/* LuaJIT specific libraries */

/* LuaJIT specific C API */

/* I guess I should leave that one there */

/* Lua 5.2 symbols */

/* Can/Shoud I hide these symbols? They seem undocumented */

Thanks for your help,
Enrico Tassi


Best regards,
Boris Nagaev

Other related posts: