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

["Wesley Smith" <wesley.hoke@...>]

This is a bit offtopic, but I can't seem to find any info on it.  Is
it "ok" to mix dlls/binaries compiled with vs8 and vs9?  Or does the
windows system choke and crap out?

thanks,
wes

On Jan 29, 2008 1:44 PM, Jerome Vuarand <jerome.vuarand@ubisoft.com> wrote:
>
> 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).
>