modifying package's lib loading (was Re: [ANN] Lua 5.1.2-rc5 now available)

[Sam Roberts <sroberts@...>]

On Fri, Mar 30, 2007 at 08:55:02PM +0200, Jose Luis Hidalgo wrote:
> 2007/3/30, Luiz Henrique de Figueiredo <lhf@tecgraf.puc-rio.br>:
> >>    Is there any chance that you can reconsider what we've talked about:
> >> http://lua-users.org/lists/lua-l/2006-11/msg00174.html
> >
> >Not now, because this is not a bug. Also, I'm still not convinced that
> >using RTLD_GLOBAL is a good thing, on the contrary, and others seemed
> >to agree. Your application has quite specific needs.

I don't think his app is so specific, its not like using C++ in lua is
unusual, or that using RTTI, a standard language feature, is unusual
either.

As a digression, this reminds me of the difficulty I had with lua
faulting on OS X when unloading modules that called obj-c, which you
would *think* would be common on OS X. It makes me suspect that modules
aren't used as often as it might be thought. It seems that folks using
lua in the recommended way statically link the core into their
application, and if you are doing that, you might as well statically
link all the modules you provide into the app, as well. Besides, do you
really want users loading their own binary modules into your apps
run-time? Can you do that with WoW or lightroom?


> Well, from the mail:
> http://lua-users.org/lists/lua-l/2006-11/msg00210.html

This proposal, if I understand it, means that before doing

  require'a_c++_module'

the user of the module would need to know it needs special flags, and
call os.setdlopenflags() before the require? Thats pretty ugly, and I
think you can cause this effect yourself *without* modifying the core,
just replace package.loadlib() with a version of the function that does
dlopen() with the _GLOBAL flag.  You'd have to copy loadlib.c out of
core, modify it slightly, and statically link it into a replacement
module, but you wouldn't have to modify the core.

Still, I wonder if there isn't a way to contain the needs of the module
inside the module.

What happens if a .so is dlopen()ed twice, with different flags? Can you
call dlopen() again inside your packages open_ function with _GLOBAL
set, and cause all its symbols to be exported? That would be the easy
way, if it worked!

Sam