On Tue, Apr 26, 2011 at 3:13 PM, steve donovan <[email protected]> wrote: > 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.
Contributions of a better uname.exe for the Windows package are welcome! (A pointer where to find one is good enough!) > 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. Thanks for all the work on it. Surely you guys know what's needed for Windows/mingw better than me. I can grant you push access if you want to take care of the mingw side of things in LR. -- -- Hisham http://hisham.hm/ _______________________________________________ Luarocks-developers mailing list [email protected] http://lists.luaforge.net/cgi-bin/mailman/listinfo/luarocks-developers
