[tlbuild] Stripping the luatex binary

[Philipp Stephani]

Am 09.04.2011 um 13:31 schrieb Peter Breitenlohner:

> On Sat, 9 Apr 2011, Taco Hoekwater wrote:
> 
>> On 04/08/2011 12:03 PM, Philipp Stephani wrote:
>>> Am 08.04.2011 um 10:46 schrieb Taco Hoekwater:
>>>>> That's why Lua uses a shared library instead on Windows, and I think it should do so on OS X, too.
>>>> That is planned for next year's luatex.
> 
> Hi Taco,
> 
> first, can you please clarify: does lua plan to have a shared library for
> Unix (I suppose all of them, not just OS X), or do you want to do this just
> for luaTeX?  And related: are the current extension modules a general lua
> feature or something special for luaTeX?

I'm not Taco, but I try to answer the Lua-related questions nevertheless.

The canonical Lua interpreter is able to load extension modules which are basically shared/dynamic libraries that have to export a specific function. Because there is no way to dynamically load libraries using only standard C functions, the extension module support comprises the only platform-specific code in Lua. It is an important feature because it opens the whole world of libraries that support the C conventions to Lua.

In order to work, extension modules have to call Lua functions and therefore need access to an existing Lua interpreter or library. On Windows, this is not a problem since the Lua library is a shared library which both the interpreter and the extension modules link against. On Unix-like systems, however, the Lua library is static and extension modules don't include the Lua library. This means that the Lua support functions are undefined until the extension module is loaded. This behavior is supported on both OS X and Linux, but it requires a specific linker flag on OS X because the OS X linker resolves symbols  at link time, like Windows does. This means that on OS X, both the interpreter program and all extension modules require special treatment. The distribution system LuaRocks knows about this.

>>> Do you know whether that requires recompilation of the extension modules? That is, could LuaTeX still load traditional extension modules that don't link against the shared LuaTeX library?
>> 
>> I could enable luatex to allow use without recompilations in theory, but it would only work for trivial modules, not for more complicated ones like gui interfaces. There are small differences between our lua and the stock lua that make such modules fail unless they are built against our own version of lua (that is even true today). Because of that, I would actually prefer to create a lua library that is specific to luatex.
>> 
>> Sure having to recompile can be annoying, but 100% reliability is much easier on the maintenance side. Once luatex has been altered this way (next year, as said) I am positive that some people will start creating pre-built packages for luatex that will then appear on tlcontrib and eventually perhaps even in texlive itself.
> 
> If shared extension modules and lua library are general lua features, it is
> extemely unpleasant to have different versions around (one for lua and one
> for luaTeX).

I agree. I'm not sure whether Lua and LuaTeX libraries would be incompatible with each other, but at least an extension module that links against the shared LuaTeX library would be incompatible with Lua since the symbols would be defined twice. Lua extension modules can be installed via LuaRocks or (on Linux) the distribution package manager, and it would be quite annoying if those distribution channels could not be used and everybody had to compile everything from source. In essence, this would mean the creation of a different programming language that is only similar to Lua. I think having to keep in sync two different libraries and two distribution channels for each extension module would even increase maintenance costs.