Re: [ANN] LuaBinaries

[Mike Pall <mikelu-0504@...>]

Hi,

Andre Carregal wrote:
> Assume for example that the standalone executable is linked statically and
> you need to do a require"socket" on a script called from the executable.
> 
> How should LuaSocket be linked so it works on this setup?

The linking step for shared libraries on ELF platforms (and others,
e.g. Mac OS X) does not require knowledge of the eventual origin
of unresolved symbols. This is because the search happens when you
load the library (the 'real' dynamic link step) and not when you
build it.

All currently loaded symbols (whether from executables or other
shared libraries) are automatically part of the search list.

Thus it does not matter whether (say) "lua_gettop" is exported
from 'lua' (an executable containing the core, linked with -E)
or from 'liblua51.so' (a shared library containing the core).
A loaded module can't tell the difference.

BTW: That's what the ominous '-Wl,-E' is for: export all Lua core
     symbols from an executable so they can be picked up by modules.
     Other toolchains (e.g.  Mac OS X) do this by default.
     Shared libraries export all public symbols by default (except
     on Windows where you have to mark all of them or create an
     export list).

> Would everything still work if LuaSocket was linked dynamically?

Yes. When 'luasocket.so' is loaded, all symbols are resolved. By then
either an executable with exported symbols or a shared library
exporting the core symbols is already present in process memory.

> Would that imply that every other Lua host executable (a Kepler launcher for
> example) would have to be statically linked too?

No, you can choose. You can share modules between the two different
setups. It is sufficient to build only one set of modules (the Lua core
versions must match of course).

The performance tradeoffs between statically and dynamically linking
the Lua core still remain.

[Compiling without -fPIC on x86 may be an option when you are able
 to set your own policies and not running excessive multi-process
 scenarios.]

> Sorry if the questions are totally naive, but its a brave new world for some
> of us... :o)

This is not a naive question. E.g. on Windows all unresolved symbols
need an associated image name where they can be loaded from. Thus you
need to know the name of the DLL where the core symbols are located
(e.g. 'lua51.dll').

This is the reason why you need to specify the name of the core DLL
when linking a module on Windows (have a look at
  http://lua-users.org/wiki/BuildingModules
under 'Windows DLLs with gcc'). You don't need to do this on all other
supported platforms.

BTW: In fact you can import symbols from executables, too, on Windows.
     But some toolchains have difficulties with this approach, so
     it's not recommended practice.

Bye,
     Mike