Re: LuaJIT and symbol versioning
- From: Enrico Tassi <gares@xxxxxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Sun, 16 Aug 2015 13:45:38 +0200
On Sun, Aug 16, 2015 at 12:16:52PM +0300, Nagaev Boris wrote:
Could you provide a use case of using both Lua 5.1 and LuaJIT in same
application?
I have no use case. What we want to do is to avoid having things blow
up if/when this happens. The point being that it may not be under your
control, as a developer of application A, if library L1 and L2 you both
link use now, or in the future, Lua and/or LuaJIT. You may not even be
using Lua in A. Imagine that, at some point in time, L1 and L2 both use
Lua 5.1, and that clearly works. Then, L2 switches to LuaJIT for
performance reasons. You end up having both Lua and LuaJIT loaded in
the address space of A.
Just to avoid being "academic", there are already in the archive
softwares that have plugins to load extensions in Lua 5.1, 5.2 and
LuaJIT. A quick grep finds uwsgi.
But more importantly, my priority are the people that develop software
using Debian, that may get segfauls by linking their application with
both, say, librpm (uses Lua 5.2) and libcsound (using 5.1). In this
example there is no LuaJIT involved, and I've picked the first two libs
I found, but I hope your get the idea.
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.
I'm not versioning the symbols of Lua extensions.
For the records Lua extensions are not linked against liblua5.1.so.0 nor
libluajit-5.1.so.0. Among other things, this lets you load the very
same .so library in both lua5.1 and luajit, or any other binary
populating the symbol table with the right symbols (via linking
liblua5.1.so.0 or by directly providing the symbols via the ld -E flag).
Best,
--
Enrico Tassi
Other related posts:
