Re: Lua libraries

[Jay Carlson <nop@...>]

On Tuesday, January 29, 2002, at 08:43 AM, Daniel Silverstone wrote:

> On Tue, Jan 29, 2002 at 08:23:49AM -0500, CRIBBSJ wrote:
> > This would also satisfy a lot of the people, like me, who don't
> > necessarily want to learn the ins and outs of C compiling.  We just 
> > want
> > a version of lua that has the libraries that we need.
>
> As the Debian maintainer of the Lua packages I have the following 
> timeline:
>
> 1. Implement a lua40 package set and migrate the lua41 stuff to be 
> called
> lua41 instead of lua4

Done, for potato.

The big question for me is whether to package pure Lua 4.0, or what I've 
been calling Lua 4.0.1: liblua40.so with lua_loadbuffer and lua_loadfile 
exposed, in order to support the new readline, line-spanning 
/usr/bin/lua.

> 2. Implement a loadlibrary like thing (prolly use loadlib since it's 
> there)

I ended up using edrx's 2-argument loadlib:

  loadlib2(path_to_so, function_to_call)

The implementation is very simple, especially on systems like Linux and 
Solaris that have good dlopen() implementations.  extensionname.so is 
explicitly linked against whatever shared libraries it needs, so that 
when you load lua_fltk.so, the dynamic loader will automatically bring 
in libfltk.so.1, libX11.so.1 etc.  On platforms without ELF DT_NEEDED 
support in dlopen, the extension itself would have to do this.  (All 
Debian platforms support this; the issue is with older/oddball systems 
like AIX and the Agenda snow library system.)

There are two annoyances I see in loadlib2:

a) You have to know both the name of the extension AND the name of its 
initialization function.  Most other dynamic loading systems (Python's, 
for example) construct the name of the initialization function from the 
name of the extension.  In the above example, loading "lua_fltk.so" 
would automatically call init_lua_fltk(S).

For debian packaging this isn't a big deal; just put loadlib2("lxp.so", 
"lua_initexpatlib") in /usr/share/lua40/lxp.lua, and have user code just 
require "lxp.lua" instead of having to know whether an extension is C or 
Lua code.

b) There's no way to close the library.

> 3. Make that the default lua for debian

Yeah, I was kinda unclear on whether I should do that.  As you saw in my 
packages, I have a "purist" lua 4.0 installation, and then "dlua40" 
being the debianized, extensible version, with the usual alternatives 
dance.

> 4. Take as many extensions as I can find and add them to Debian as
> loadlib'able extensions.

The process isn't too hard, but it does take a little time.  Actually 
lua-fltk is problematic in that it currently needs a new lua.c to 
support the right select() goo to be able to interact with the 
interpreter while the fltk main loop is running.

> Unfortunately I don't know how much time I do/don't have to do it all 
> in :(

Would it help if I shipped woody source packages?  I now have a couple 
of boxes tracking the testing distro, so it would be pretty easy.

Jay