5 Sep 23:30
Re: LuaRocks with Windows/Visual Studio
From: Ross Berteig <Ross <at> CheshireEng.com>
Subject: Re: LuaRocks with Windows/Visual Studio
Newsgroups: gmane.comp.lang.lua.general
Date: 2008-09-05 21:30:16 GMT
Subject: Re: LuaRocks with Windows/Visual Studio
Newsgroups: gmane.comp.lang.lua.general
Date: 2008-09-05 21:30:16 GMT
Sometime on 9/5/2008, "RJP Computing" <rjpcomputing <at> gmail.com> wrote: >On Thu, Sep 4, 2008 at 5:49 PM, Ross Berteig wrote: >> .... >> In my projects, I follow Steve's list of functions to alias with >> macros at compile time, and use a link line that ends with: >> >> $(LUADLL) -lgcc -lmsvcr80 $(MSVCR80) >> .... > >How come you need -lmsvcr80 and $(MSVCR80)? shouldn't $(MSVCR80) >be enough? Can you explain a bit more? Either could have been sufficient, but gcc doesn't seem to get the linkage even remotely right without any reference to libmsvcr80.a. If only MSVCR80.DLL is on the link line, the link has actually satisfied all CRT symbols from MSVCRT.DLL and nearly completely ignored MSVCR80.DLL. The 19 functions identified by Steve all have the property that they are documented in the MSDN with names of the form foo() along with a companion function named _foo64(), but the functions actually exported by MSVCR80.DLL are named _foo32() and _foo64(). Unfortunately, MSVCRT.DLL which is linked by libc.a (and/or libmsvcrt.a) *does* export a function named foo(). Any code which uses one of those functions (I needed mktime() most recently) then gets at least part of its runtime from the wrong DLL. Steve's kludge simply uses #define to map each foo() to _foo32() at compile time, but now _foo32() is not an exported symbol of any library in the link unless MSVCR80.DLL is explicitly included.(Continue reading)
RSS Feed