Re: Lua libraries

[Victor Bogado da Silva Lins <bogado@...>]

On Tue, 2002-01-29 at 12:41, Jay Carlson wrote:
> On Tuesday, January 29, 2002, at 08:43 AM, Daniel Silverstone wrote:
> 
> 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

	I would add that the loadlib should receive a logical name, I mean it
should be 

	loadlib ("fltk")

		instead of 

	loadlib ("/xxx/yyy/liblua_fltk.so")

	The loading mechanism would transate the logical name "fltk" to the
path of the library needed it could be liblua_fltk.so in a unix
enviroment or lua_fltk.dll in windows or even something diferent like
loading a library in a palmos enviroment that does not have files at
all.

-- 
[]'s Victor Bogado da Silva Lins
victor@visgraf.impa.br