Windows build
kyra
kyrab at mail.ru
Tue Nov 12 09:38:30 UTC 2013
It looks the second option (native win32 python) works.
I've installed native win32 python, reverted my edit, leaving only
*your* edit in place, *and* disabled msys2 python simply moving all
msys2 python executables out of the path. It seems, all works now (I
didn't wait the finish of tests, though).
Cheers,
Kyra
On 11/12/2013 12:58, Simon Peyton-Jones wrote:
>
> Thanks Kyra, you are a star.
>
> Yes, msys2 has been updated to fix the ctypes bug. I have the version
> from 20131022.
>
> With your edit I now get this:
>
> Traceback (most recent call last):
>
> File "../driver/runtests.py", line 164, in <module>
>
> if mydll.kernel32.SetConsoleCP(65001) == 0:
>
> File "/usr/lib/python2.7/ctypes/__init__.py", line 435, in __getattr__
>
> dll = self._dlltype(name)
>
> File "/usr/lib/python2.7/ctypes/__init__.py", line 365, in __init__
>
> self._handle = _dlopen(self._name, mode)
>
> OSError: No such file or directory
>
> Any ideas about what to do now? I guess you can reproduce if you
> install the later msys2.
>
> thanks
>
> Simon
>
> *From:*ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *kyra
> *Sent:* 12 November 2013 06:45
> *To:* ghc-devs at haskell.org
> *Subject:* Re: Windows build
>
> I've looked into this.
>
> Current test script picks msys2-compiled python, which, after your
> modification, can't find 'windll', because msys2-compiled python is
> cygwin-like and it's 'ctypes' has no 'windll'. If we rewrite the
> relevant part of script thus:
>
> config.msys2 = False
> ....
> elif v.startswith("MINGW"):
> config.msys2 = True
> ....
> # Try to use UTF8
> if windows:
> import ctypes
> if config.cygwin or config.msys2:
> # Is this actually right? Which calling convention does it use?
> # As of the time of writing, ctypes.windll doesn't exist in the
> # cygwin python, anyway.
> mydll = ctypes.cdll
> else:
> mydll = ctypes.windll
>
> then we go slightly further and fail with:
>
> Traceback (most recent call last):
> File "../driver/runtests.py", line 151, in <module>
> import ctypes
> File "/usr/lib/python2.7/ctypes/__init__.py", line 451, in <module>
> pythonapi = PyDLL("libpython%d.%d.dll" % _sys.version_info[:2])
> File "/usr/lib/python2.7/ctypes/__init__.py", line 365, in __init__
> self._handle = _dlopen(self._name, mode)
> OSError: No such file or directory
>
> And this is definitely a bug in msys2 python, because there is no such
> a file ("libpython*.dll) anywhere in msys2 distribution.
>
> What could be possible solutions?
>
> 1. I'm seeing a new version of Msys2 appearing right now here
> http://sourceforge.net/projects/msys2/files/REPOS/MSYS2/i686/. It is
> now a bunch of separate packages, I've looked into python 2.7.5
> package and found ctypes-related things definitely changed. Thus we
> could wait a couple of days until Msys2 release process is finished
> and installation information is available, hoping it's python is
> working properly.
>
> 2. Another approach is to modify testing infrastructure to use some
> pure win32/mingw based python distribution. But I'm in no way an
> expert here, sorry.
>
> Cheers,
> Kyra
>
>
> On 11/12/2013 02:10, Simon Peyton-Jones wrote:
>
> Austin, or others,
>
> It would be SO GREAT if it was possible to validate on Windows again.
>
> Currently I'm using msys2, which builds GHC fine, but things fail
> badly in the testsuite.
>
> Traceback (most recent call last):
>
> File "../driver/runtests.py", line 144, in <module>
>
> raise Exception("Can't detect Windows terminal type")
>
> Exception: Can't detect Windows terminal type
>
> uname --s returns MINGW_NT-6.2
>
> Changing the test from
>
> elif v.startswith("MINGW32"):
>
> to
>
> elif v.startswith("MINGW"):
>
> just produces a new error
>
> Traceback (most recent call last):
>
> File "../driver/runtests.py", line 155, in <module>
>
> mydll = ctypes.windll
>
> AttributeError: 'module' object has no attribute 'windll'
>
> ../mk/test.mk:242: recipe for target 'test' failed
>
> It's all very frustrating because I can't validate. Can anyone help?
>
> Simon
>
>
>
>
> _______________________________________________
>
> ghc-devs mailing list
>
> ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131112/aeec595e/attachment-0001.html>
More information about the ghc-devs
mailing list