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

Reply via email to