Ross Berteig | 5 Sep 23:30

Re: LuaRocks with Windows/Visual Studio

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)


Gmane