Hi all, The first discovery is that just because a command calls itself 'uname' does not mean that it is trustworthy.
The MSYS version gives: MINGW32_NT-6.1 STEVE-HP 1.0.12(0.46/3/2) 2010-02-05 01:08 i686 unknown the one that comes with the LR Windows package: WindowsNT steve-HP 1 6 x86 Which is not so good, because LR is depending on uname to work out whether we should use mingw or not. Both of these unames lie, of course, because it's a x86_64 machine. I will look at the options here, may need to add some heuristics like looking at %PROCESSOR_ARCHITECTURE%, which is given as AMD64 here. Also, if there's a env variable called 'ProgramFiles(x86)' then it's almost certain to be 64-bit Windows; this is the location of any 32-bit programs hanging around. The second observation is that currently a few assumptions about mingw are wired into LR. It is assumed that people always want to link against libmsvcr80.a (or some other MS runtime, controlled by the MSVCRT variable) and there's no way to get around this. Also, the DLLs are linked against 'lua5.1.lib', which is another MS-ism. (I think Fabio did exactly what we told him to do, so I can't complain ;)) Actually the problem is that LR builds are underspecified: on POSIX systems you may cheerfully leave out references to the shared library, knowing that it will all be sorted out by the dynamic linker, but on Windows there must be an import library at link-time. mingw is smart enough to understand MS-style .LIB files, standard .a files and also the DLL itself, but it does need some reference to the Lua DLL at this point. But although there is a LUA variable, there is no LUADLL variable. Once I had added a suitable LUADLL to my config.lua's variables, I was able to make a special command build for LuaSocket and move ahead with my life ;) These modifications may be of interest, because it's still a little annoying to use LR on Windows with mingw. We still have a lot of 'make' builds in LR and for the mingw platform the assumption then is that there's a 'Makefile.win' - which usually there isn't. So avoiding 'make' leads to more happiness. The idea is still to move Lua for Windows off its MS habit and over to mingw (LfW is using an obsolete MS runtime anyway) so this will become important and some point. steve d. _______________________________________________ Luarocks-developers mailing list [email protected] http://lists.luaforge.net/cgi-bin/mailman/listinfo/luarocks-developers
