lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Hi,

Adolf Mathias wrote:
> A general loadlib request: Lua 5.1 has an OS-independent wrapper for DL 
> calls. Since I'm in the process of integrating Bruno Haible's av_call 
> into 5.1, I would need the Lua dl functions split up into the dl access 
> and the symbol lookup part.

Well, the current loadlib() stuff in Lua was never designed for anything
except loading a Lua extension. And ffcall has too many dependencies to
be merged into the Lua core in the standard distribution.

But 5.1-work3 already has a userdata object with a boxed handle to the
loaded library. It even has a metatable with a __gc call to support
unloading (only if you close the Lua universe, but not during runtime).
Adding an __index method would be quite easy.

There are some issues left:

- The library handle is only stored in the registry. It needs to be returned
  to the user, too. Passing a nil symbol name for loadlib() is currently
  illegal and could be used for this purpose. Or maybe the empty string?

- The resolved symbols need to get an appropriate type. Unless we want
  to merge ffcall into the core the only reasonable choice is LIGHTUSERDATA.

- On Mac OS X you probably want to load both bundles and dylibs. I have
  not verified this, but I guess I could do this 'automagically' with
  the low-level _dylib_* API.

  BTW: That would solve the bundle vs. dylib issue, too. You can use both
       and you decide which to use when compiling the extension. :-)

I think this modification is very lightweight and would mainly reuse
existing code. One still needs the ffcall extension to make use of the
returned symbols, though.

Opinions?

Bye,
     Mike