Re: static Lua, shared extensions, platform pain

[Drake Wilson <drake@...>]

Quoth Sean Conner <sean@conman.org>, on 2010-03-02 04:29:27 -0500:
> > >From my experience it was better to link against the .so, because the
> > static link only satisfied the Lua calls I had explicitly made. Tried
> > to run some scripts and load some extensions, and couldn't find some
> > symbols.  So there must be a caveat attached to this recommendation
> > (unless there is some link subtlety I missed)
> 
>   There is.  When compiling your app with GCC, and compiling statically
> against Lua, you need to use the "-rdynamic" option to the compiler to
> export the Lua API to the extenstions.

If you link with a static library, often the linker will only pull in
object files with symbols known to be used in the linked object.  In
this case, doing an export-dynamic may not help by itself.  Mixing
static and shared libraries tends to be tricky and platform-dependent.

E.g., with the GNU linker, you can force all object files from a
static library to be linked in using --whole-archive (or
-Wl,--whole-archive from a suitable compiler line), and then turn that
off for subsequently-named archives using --no-whole-archive (simil.,
-Wl,--no-whole-archive), AIUI.  (Not that I've tried this case with
dynamic symbol re-export from the executable.)

I tend to interpret a recommendation for static linking to mean that
you should statically link the entire binary or at least everything
dependent on the static bit.  Static Lua plus shared extensions will
tend to blow up in your face unless you are very careful.  Static Lua
plus static extensions and possibly suitable preloading in C should
work fine.

>   -spc (It should work after that ... )

Glance at the Libtool source and then tell me that again.  :-P

   ---> Drake Wilson