static & dynamic linkage

[Asko Kauppi <asko.kauppi@...>]

Just for a reference, this is how LuaX allows static/dynamic linkage of 
a module:

- No changed necessary in module source code (this is important!)

- By default, modules are compiled dynamically, 'GluaModule()' being 
their entry point.

- Defining 'GLUA_MODULE_NAME=GluaModule_sys' (or similar) at 
compilation, the entry point can be changed and the module linked 
statically.

I use static linkage for the 'sys' module only, because its an easy way 
to get directory access etc. services. If one wants, multiple modules 
can be linked statically, since each entry point may be uniquely named.

LuaX does not use the regular 'loadlib' approach for linkage, so this 
approach may not suit others.

-ak


7.6.2004 kello 02:12, D Burgess kirjoitti:

>  I concur with Edgars comments.
>
> However, it seems that this minor issue has hijacked Diegos
> original agenda, namely; the best way to manage (and mask) the
> difference between static and dynamically loaded libraries.
>
> Unload support would be a nice addition but is not critical.
>
> The original question was in
>
> http://lua-users.org/lists/lua-l/2004-06/msg00041.html
>
> regards
> David B
>
> Edgar Toernig <froese@gmx.de> wrote:
>
> > Mike Pall wrote:
> > > - An extensive framework to support automatic unloading is very 
> > > difficult
> > >   to get right and will not benefit most developers.
> >
> > Sorry?  2-5 lines of code in the Lua core plus the dlclose handling in
> > the loader library.  That's all!
> >
> > > - There is no way we can prevent everyone from shooting themselves 
> > > in the
> > >   foot. There are far more loopholes than we could possibly close.
> >
> > Hmm?  Afaik, any way to crash the app from a Lua script is considered
> > a serious bug.
> >
> > > The current solution already passes a handle to the library as an 
> > > upvalue
> > > to the function loaded from the library. So this function has the 
> > > ability
> > > to provide support for unloading. It's just that no libraries I know 
> > > of do
> > > that. Maybe because it's undocumented?
> >
> > A library cannot unload itself.  The code to perform that has to be
> > in another segment, else the dlclose call returns to just unmapped
> > memory.  Beside that, you would require system dependant code in
> > each library.
> >
> > > And about the danger of crashing Lua: If you can use loadlib(), you 
> > > can
> > > always provoke a crash by referencing an innocent symbol:
> > >   loadlib("libc.so.6", "read")() -> Segmentation fault
> >
> > That's only because of the trivial loadlib implementation.  A sane
> > version would perform checks similar to those in the precompiled-
> > script loader.  I.e. in my implementation, every dynamically loaded
> > binary has a structure with a fixed name in the .so that describes
> > the library: version info, number size and type, start function.
> > That data is checked and only if everything's ok, the cclosure of
> > the start function is returned.
> >
> > Ciao, ET.
>