lua-users home
lua-l archive

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

2009/12/10 Joshua Jensen <>:
> ----- Original Message -----
> From: steve donovan
> Date: 12/9/2009 5:02 AM
>> On another note, the Windows .dll model is irritating because an
>> extension must be compiled to link against a specific .dll, unlike
>> with Unix where the extension finds its dependencies dynamically from
>> its link context.  This makes it trivial to have both luajit and lua
>> executables together on Linux, but this would be a bitch to get right
>> on Windows.
> What I would like to see (and experimented with once) is for Lua to load the
> Lua module and call the luaopen_ function by passing in a structure of
> pointers to all the exported Lua functions.
> struct lua_Exports
> {
>    ...
>    void  (*lua_pushvalue) (lua_State *L, int idx);
> };
> int luaopen_mymodule(lua_State *L, lua_Exports *exports);
> A helper function called by luaopen_mymodule could be made available to
> expand that structure into global variables:
> /* lua_exportglobals.h */
> void (*lua_pushvalue)(lua_State *L, int idx);
> void lua_copyexportstoglobals(lua_Exports *exports)
> {
>    lua_pushvalue = exports->lua_pushvalue;
> }
> Then all other Lua use is the same.
> There are important benefits to this approach.  The Lua module would never
> need to link against the Lua DLL.  An embedded static Lua distribution in an
> executable could load any Lua module as easily as lua5.1.dll; this can't
> happen right now as the Lua module .dll/.so embeds the Lua DLL name.  Worse,
> on Mac OS X, the full path to the Lua shared library is embedded in the
> module.  The shared library MUST be at that location.  To run a Lua
> distribution local to my application, I have to recompile everything and use
> @executable_path (which isn't always convenient).
> Thoughts?

I think TCL is now using a similar approach.

Another solution, would be to use a custom DLL loader for Lua modules,
and whenever a symbol is imported from lua51 module, it would instead
of loading it look for that symbol in all currently loaded modules of
the process.

Actually, I wonder if the stock Windows DLL loader doesn't already
have, I don't know, a special module name or something similar that
could be used in the import section to trigger such a mechanism. This
would allow to build unix-like shared libraries.