lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Aug 4, 2012 7:10 AM, "Carsten Fuchs" <carsten.fuchs@cafu.de> wrote:
>
> Am 2012-08-04 11:12, schrieb Doug:
>>
>> Binding everything up and statically linking the extension to the
>> binary does seem to be the only way to make it work properly.
>> [...]
>>
>> Deeply frustrating to work with.
>
>
> Exactly my experience, too.
>
> It would help if Lua kept no internal static state, but it seems that the real problem is that DLLs under Windows and SOs under Linux (my main platforms, can't say much about others) are different enough so that "portable" support in an advanced application/setting for both is very problematic.
> Especially "mixing" is difficult: Linking everything statically or linking "everything" dynamically seems to work out relatively naturally, but linking the main application statically and using DLLs/SOs only for extensions/"plugins" comes with an astonishing number of platform-specific differences, and it is very hard to deal with all of them combined.
>
One thing that I have done in the past is to alter Lua such that its functions were all lumped into a function table in the "extra space" behind the Lua state pointer. A set of altered headers were used by extensions that I needed to dynamically link in.
This made it so that no matter what method by which the Lua state came into existence, all external code could get a handle on the same codebase running the VM. Though of course all extensions to use it required being built with the special headers. It also solves the potential problems that could arise if you wrote an extension for some other software and didn't want to possibly have symbol/dll-naming collision problems.
Someday I may set out to construct an open-source project to do this ... But it’s not on my schedule at the moment.