lua-users home
lua-l archive

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


Sorry I was sloppy/unclear the MSVCR80.DLL is the version of
Microsoft's C runtime library for Visual Studio 2005 compiler and
linker. So I'm using same runtime & compiler version.

I wanted to load the plain lua51.dll to avoid duplicating lua51.dll.
So if I'd like to have only one lua51.dll, is it best to just
substitute lua51.dll from LuaJIT compilation or statically link LuaJIT
or have LuaJit check version of plain lua51.dll directly?

The directory structure, lua modules, lua files, examples, docs etc
already exist in Lua for Windows setup. What is your opinion on how
LuaJIT would best be included in a Lua distribution?

Cheers
Andrew

On Thu, Dec 18, 2008 at 8:24 PM, Mike Pall <mikelu-0812@mike.de> wrote:
> Andrew Wilson wrote:
>> I've compiled LuaJit with MSVC 2005, and it seems to work with
>> standard 5.1.4 MSVC 8 runtime, the same runtime which Lua for Windows
>> uses, the only change necessary was removing function call
>> LUAJIT_VERSION_SYM(); from LuaJIT's lua.c that was added to guarantee
>> using synced 5.1.4 libraries.
>>
>> Mike Pall or any other LuaJit expert:
>>  Can LUAJIT_VERSION_SYM(); call safely be removed from LuaJIT's lua.c
>> file if you know you've supplied correct .dll & other binaries as in
>> Lua for Windows distribution?
>
> The call was put there for a purpose: to make sure the luajit.exe
> and the lua51.dll match up. And in particular to make sure you
> don't load the lua51.dll from a plain Lua installation by accident.
>
> LuaJIT compiles fine under MSVC out-of-the-box. There should
> _never_ be any need to remove this call. If there is, then the EXE
> is obviously not loading the right DLL. So better find out why
> this happens. If you remove the call, you are curing the symptom,
> not the cause.
>
> Note that this is unrelated to the fact that you are attempting to
> compile with one MSVC version against the MSVC runtime of another
> version. This is a bad idea for various reasons -- don't do it.
>
> --Mike
>