Re: More about packaging (fwd)

["D Burgess" <db@...>]

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.