RE: lua modules and linking to the lua dll on windows

["Jerome Vuarand" <jerome.vuarand@...>]

Wesley Smith wrote:
>> Wesley Smith wrote:
>>> The way I'm building modules right now with GCC uses -undefined
>>> dynamic_lookup to avoid having to link with a lua library since it's
>>> embedded in my app and I want modules to get their symbols from
>>> there. Is there an equivalent functionality on Windows?  Can an app
>>> export symbols which a dll (i.e. module) can then find when it's
>>> loaded by the app?
>> 
>> You can export symbols from your exe with either
>> __declspec(dllexport) directives or a .def file. The linker should
>> generate an import library that you can use to link your module. The
>> drawback of that method is that the modules will have the exe
>> filename hardcoded in their import section, so you cannot rename the
>> exe afterwards. 
>> 
>> (This is valid for VC++, for MinGW GCC symbol export is the same, but
>> for linking your modules just pass the exe as input file instead of
>> the .lib)
>> 
> 
> Thanks Jerome.  This is very helpful.  Thinking a bit ahead, I'd like
> my module builds to be usable for distribution with LuaRocks.  From
> you answer, I'm speculating that going the route described above
> would make it incompatible.  Is the only solution then to link
> against a lua.dll?    

The problem is specific to Windows, because imported symbols must be
qualified with the module name. AFAIK on ELF systems imported symbols
are just described with the symbol name, so the dynamic linker is free
to take them from any binary it feels is suitable. Default Lua makefiles
on these systems already take advantage of that.

The solution on Windows is to use a standardized module name for the Lua
binary. This is an issue because currently Lua default makefiles use
lua51.dll as the module name, while iirc LuaBinaries use lua5.1.dll. I
don't know the convention used by LuaRocks on Windows. Maybe a simpler
solution to your problem is to distribute your rocks as source files and
let LuaRocks compile them (with a single but host-specific linking
architecture depending on the LuaRocks configuration).