Re: [ANN] Lua 5.2.0 (rc1) now available

[David Manura <dm.lua@...>]

On Thu, Nov 24, 2011 at 4:33 PM, Ashwin Hirschi <lua-l@reflexis.com> wrote:
>> Actually, this does not solve our problem. We wanted to allow
>> redefinitions (through luaconf.h) *after* the inclusion of windows.h.
>> It seems that the best solution is to include windows.h in luaconf.h
>> itself.
> Yes, I agree that makes sense.

What is an example?  Exporting the windows.h behemoth is preferably
avoided; by implication it can mean that #include "lua.h" will define
things like min/max macros in the client, though that can be mitigated
with

#define WIN32_LEAN_AND_MEAN
#include <windows.h>
/* http://blogs.msdn.com/b/oldnewthing/archive/2009/11/30/9929944.aspx */

> Not all Windows compilers have the _fseeki64 and _ftelli64 functions that
> are defined there (in a LUA_WIN section)... I ran into this 3rd issue
> shortly after my previous post, but noticed Kein-Hong Man had already
> alluded to it in his post.

When cross-compiling with i586-mingw32msvc-gcc from Linux, you can add
a "-lmsvcr80" or "-lmsvcr90" after the "$(AR) $@ $?" (or add change it
in a gcc "specs" file), which will link against
msvcr80.dll/msvcr90.dll, which do have these functions.  Example:

cd src
i586-mingw32msvc-gcc -dumpspecs >specs
sed -i -e's,msvcrt,msvcr80,' specs
make CC="i586-mingw32msvc-gcc -specs=specs" AR="i586-mingw32msvc-ar
rcu" RANLIB="i586-mingw32msvc-strip --strip-unneeded" mingw

Hopefully there could be an easier way.  (IMHO, the Lua recursive
Makefiles can be more trouble than they're worth.)