Re: static Lua, shared extensions, platform pain

[Drake Wilson <drake@...>]

(Today's error rate is moderately high.  Add extra salt to taste.)

Quoth Luiz Henrique de Figueiredo <lhf@tecgraf.puc-rio.br>, on 2010-03-02 08:34:28 -0300:
> > >> Static Lua plus shared extensions will tend to blow up in your face
> > >> unless you are very careful.
> > >
> > > How so? We've all be doing this for years now.
> > 
> > Ah, but you count among the very careful.
> 
> But I mean the standard Lua interpreter: it supports static linking of the
> Lua core and dynamic linking of user modules out of the box on all major
> platforms (magic compilation and link flags are needed, but the Makefile
> knows about them).
[rearranged text]
> If you need to add Lua statically to your app then you need to look at the
> Lua Makefiles to figure out what magic flags are needed for this. For gcc
> in Linux it's -Wl,-E. You may also need to link with -ldl.

I probably misphrased my original sentence somewhat, but I would say
that J. Random Community Developer may not, say, have access to an AIX
box for testing whether their set of magic flags works there.  (That
and the core Lua folks will tend to both have and be able to depend on
the internals of the build, though that's a weaker consideration.
There's a second point in there somewhere about predictability of
overall linking strategy when the standard interpreter and the library
are ~guaranteed to come from the same distribution, but I can't seem
to dredge out its exact form at the moment.)

So certainly it is possible, but if you wish to be portable (which is
an assumption I should have made clearer) you must be very careful
about it (and deal with potentially a bunch of platform issues
depending on the complexity of your application build), whereas
shared-shared and static-static usage seem to result in much fewer
portability problems, which I think is most of what I meant above.

> The user-side issue is how to write Lua libraries as shared libraries
> in those platforms; again this may be require magic flags (and the Lua
> Makefile does not help here) but nothing really blows in your face.

Creating shared libraries can easily get nontrivial in the first place
(see libtool), though of course it depends on which platforms one is
targeting.  E.g., if you can assume only one case (such as GNU/Linux
with GNU toolchain, or Windows NT with Microsoft toolchain), it's much
easier, of course.

> For the record, the short answer is that in Linux you need to create the .so
> with -shared and probably -fPIC (see a recent thread). In Mac OS X, I use
>   env MACOSX_DEPLOYMENT_TARGET=10.3 $(CC) -bundle -undefined dynamic_lookup

That sort of magic counts as significant secondary work to me.  :-)

> The only real problem we have seen is when people mistakenly link another
> copy of the Lua core into their Lua modules: then things may indeed blow up
> in your face. Lua 5.2 will have safety mechanisms for that.

ISTR that some platforms refuse to allow symbols in shared libraries
that are not explicitly imported from somewhere (Windows NT?  AIX in
at least one linking model?), at which point I would expect it to get
awkward if you want to load third-party Lua extensions (as shared
libraries) at runtime but also link Lua-proper into the application
statically, no?  Maybe I'm misremembering that part.

   ---> Drake Wilson