 |
lua-l archive |
|
|
||
|
On Mar 25, 2013 12:04 PM, "steve donovan" <steve.j.donovan@gmail.com> wrote:
>
> On Mon, Mar 25, 2013 at 5:09 PM, Jay Carlson <nop@nop.com> wrote:
> > I have a feeling the only Unix system the (technically nonofficial) official
> > Lua shared object technique really works right on is SunOS 4. Maybe some of
> > the little vendor 4.3BSD ports too.
>
> Hm, but I've never noticed any problems with Linux, Lua and .so use.
All the world is not a VAX, nor is it always running Solaris's children.
>
> Is it one of those 'in theory it should not work, but in practice does' things?
It doesn't work in the sense you need the -Wl, export hack.
It's also great fun if you have a (say) GIMP plugin using Lua internally for scripting. That plugin normally would have a dependency on liblua.so.5.1 (since /usr/bin/gimp doesn't). Now you try to import lposix.so. lposix.so either has a dependency on liblua.so.5.1 or not. If it does not, it probably can't find the symbols from inside the plugin. If it does, it's *theoretically* unusable with /usr/bin/lua or anything else statically linking the core into the main program, because lposix.so will call in a second core. (But see below.)
I don't wanna hear about how heroic use of dlopen flags and linker symbol munging in the gimp plugin could fix this. It All Just Works if /usr/bin/lua is just another user of liblua.so.5.1.
But in fact, it does just happen to work in the /usr/bin/lua case if lposix.so *does* require liblua.so.5.1 because /usr/bin/lua's symbols are first in the search order; lposix.so just needs not to go out of its way to force resolution only via dependencies. So it should always be safe to link lposix.so with liblua.so.5.1.....
It also all just works in SunOS because shared libraries have a completely flat symbol namespace and do not record dependencies. Which sucks in other ways but at least it's an ethos.