Windows
Windows build is working againthank you! (To be fair, I'm still building stage2, so have not tried the testsuite yet, but I live in hope.) Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Windows
I've just got a new laptop (the old one's hard disk died) so I'm trying to get to the point of being able to build GHC again. I'm currently stuck here: ./configure configure: loading site script /usr/local/etc/config.site checking for gfind... no checking for find... /usr/bin/find checking for sort... /usr/bin/sort checking for GHC version date... inferred 8.5.20180323 checking for GHC Git commit id... inferred affdea82bb70e5a912b679a169c6e9a230e4c93e checking for ghc... /c/fp/HP-8.2.2/bin/ghc checking version of ghc... 8.2.2 GHC path canonicalised to: c:/fp/HP-8.2.2/bin/ghc checking build system type... x86_64-pc-msys checking host system type... x86_64-pc-msys checking target system type... x86_64-pc-msys Unknown OS msys Any ideas? Thanks Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Windows breakage
This breakage didn't use to happen. Might someone fix it? Thanks. For now I'm going through changing a dozen "Trustworthy" to "Safe". Is that right? Simon librariesWin32SystemWin32Console.hsc:2:14: Warning: 'System.Win32.Console' is marked as Trustworthy but has been inferred as safe! : Failing due to -Werror. libraries/Win32/ghc.mk:4: recipe for target 'libraries/Win32/dist-install/build/System/Win32/Console.o' failed ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Windows failures
On Windows I'm getting these failures. Details below. Simon Unexpected failures: ../../libraries/base/testsT7773 [exit code non-0] (normal) ../../libraries/random/tests rangeTest [bad exit code] (normal) cabal/cabal01 cabal01 [bad stdout] (normal) ghc-api/T7478 T7478 [bad exit code] (normal) ghci.debugger/scripts dynbrk009 [bad exit code] (ghci) ghci/scripts T5975a [bad stderr] (ghci) rts T4850 [bad stdout] (normal) => T7773(normal) 3517 of 3614 [2, 18, 0] cd ../../libraries/base/tests && 'C:/code/HEAD/inplace/bin/ghc-stage2.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o T7773 T7773.hs>T7773.comp.stderr 2>&1 Compile failed (status 256) errors were: T7773.hs:2:8: Could not find moduleSystem.Posix.IO Use -v to see a list of the files searched for. *** unexpected failure for T7773(normal) => rangeTest(normal) 3386 of 3589 [2, 25, 0] cd ../../libraries/random/tests && 'C:/code/HEAD/inplace/bin/ghc-stage2.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o rangeTest rangeTest.hs>rangeTest.comp.stderr 2>&1 cd ../../libraries/random/tests && ./rangeTestrangeTest.run.stdout 2>rangeTest.run.stderr Wrong exit code (expected 0 , actual 1 ) Stdout: Int: Passed Integer: Passed Int8: Passed Int16: Passed Int32: Passed Int64: Passed Word: Passed Word8: Passed Word16: Passed Word32: Passed Word64: Passed Double: Passed Float: Passed CChar: Passed CSChar: Passed CUChar: Passed CShort: Passed CUShort: Passed CInt: Passed CUInt: Passed CLong: Passed CULong: Passed CPtrdiff: Passed CSize: Passed CWchar: Passed CSigAtomic: Passed CLLong: Passed CULLong: Passed CIntPtr: Passed CUIntPtr: Passed CIntMax: Passed CUIntMax: Passed Int R: Passed Integer R: Passed Int8 R: Passed Int8 Rsmall: Passed Int8 Rmini: Passed Int8 Rtrivial: Passed Int16 R: Passed Int32 R: Passed Int64 R: Passed Word R: Passed Word8 R: Passed Word16 R: Passed Word32 R: Passed Word64 R: Passed Double R: Passed Float R: Passed CChar R: Passed CSChar R: Passed CUChar R: Passed CShort R: Passed CUShort R: Passed CInt R: Passed CUInt R: Passed CLong R: Passed CULong R: Passed CPtrdiff R: Passed CSize R: Passed CWchar R: Stderr: rangeTest.exe: broke lower bound: 100 => cabal01(normal) 81 of 3614 [0, 0, 0] cd ./cabal/cabal01 && $MAKE -s --no-print-directory cabal01 VANILLA=--enable-library-vanilla PROF=--disable-library-profiling DYN=--disable-shared CLEANUP=1cabal01.run.stdout 2>cabal01.run.stderr Actual stdout output differs from expected: --- ./cabal/cabal01/cabal01.stdout-mingw32 2012-06-22 00:08:51 +0100 +++ ./cabal/cabal01/cabal01.run.stdout 2013-05-15 07:18:31 +0100 @@ -1,9 +1,9 @@ install1: bin -test-1.0 +i386-windows-ghc-7.7.20130514 install2: bin -test-1.0 +i386-windows-ghc-7.7.20130514 dist: build package.conf.inplace *** unexpected failure for cabal01(normal) => T7478(normal) 6 of 6 [0, 0, 0] cd ./T7478 && $MAKE -s --no-print-directory T7478T7478.run.stdout 2>T7478.run.stderr Wrong exit code (expected 0 , actual 2 ) Stdout: - 0 -- (0,"[1 of 2] Compiling B( B.hs, B.o )") (0,"[2 of 2] Compiling Main ( A.hs, A.o )") - 1 -- (1,"[2 of 2] Compiling Main ( A.hs, A.o )") - 2 -- (2,"[1 of 1] Compiling Main ( C.hs, C.o )") (2,"Linking A.exe ...") Stderr: T7478.exe: T7478.exe: phase `Linker' failed (exitcode = 1) make[1]: *** [T7478] Error 1 *** unexpected failure for T7478(normal) => dynbrk009(ghci) 67 of 76 [0, 0, 0] cd ./scripts && HC='C:/code/HEAD/inplace/bin/ghc-stage2.exe' HC_OPTS='-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history ' 'C:/code/HEAD/inplace/bin/ghc-stage2.exe' --interactive -v0 -ignore-dot-ghci -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -ignore-dot-ghci dynbrk009.run.stdout 2>dynbrk009.run.stderr Wrong exit code (expected 0 , actual 1 ) Stdout: Stopped at dynbrk009.hs:8:22 _result :: Int = _ Stopped at dynbrk009.hs:8:27-36 _result :: Int = _ Stopped at dynbrk009.hs:8:31-35 Stopped at dynbrk009.hs:6:1-9 Stopped at dynbrk009.hs:6:9 Segmentation fault/access violation in generated code => T5975a(ghci) 84 of 100 [0, 0, 0] cd . && touch fb r1.hs cd . && HC='C:/code/HEAD/inplace/bin/ghc-stage2.exe' HC_OPTS='-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history ' 'C:/code/HEAD/inplace/bin/ghc-stage2.exe' --interactive -v0 -ignore-dot
Windows failures
Ian This is 'sh validate" on 64bit Windows. Rather a lot of failures. Might you look? The perf tests seem to fail because it's comparing with the *32* bit numbers, even though this is definitely a *64* bit laptop. Whether the entire build system thinks it's a 32 bit machine, or just the testsuite, I can't tell. Thanks Simon Unexpected failures: cabal/cabal01cabal01 [bad exit code] (normal) cabal/cabal04cabal04 [bad exit code] (normal) driver dynHelloWorld [exit code non-0] (dyn) driver/dynamicToodynamicToo002 [bad stdout] (normal) driver/dynamicToodynamicToo003 [bad exit code] (normal) dynlibs T4464 [bad exit code] (normal) dynlibs T5373 [bad exit code] (normal) ghc-api/T7478T7478 [bad exit code] (normal) ghci.debugger/scriptsbreak008 [bad exit code] (ghci) ghci.debugger/scriptsdynbrk009 [bad exit code] (ghci) ghci/scripts T5975a [bad stderr] (ghci) llvm/should_compile T5486 [exit code non-0] (optllvm) llvm/should_compile T5681 [exit code non-0] (optllvm) llvm/should_compile T6158 [exit code non-0] (optllvm) llvm/should_compile T7571 [exit code non-0] (optllvm) llvm/should_compile T7575 [exit code non-0] (optllvm) perf/compilerT1969 [stat not good enough] (normal) perf/compilerT3294 [stat not good enough] (normal) perf/compilerT4801 [stat too good] (normal) perf/haddock haddock.Cabal [stat not good enough] (normal) perf/haddock haddock.base [stat not good enough] (normal) perf/haddock haddock.compiler [stat not good enough] (normal) perf/should_run T7797 [stat too good] (normal) rts T4850 [bad stdout] (normal) rts derefnull [bad exit code] (normal) rts divbyzero [bad exit code] (normal) runghc T7859 [bad stderr] (normal) safeHaskell/check/pkg01 ImpSafeOnly01 [exit code non-0] (normal) safeHaskell/check/pkg01 ImpSafeOnly02 [exit code non-0] (normal) safeHaskell/check/pkg01 ImpSafeOnly03 [stderr mismatch] (normal) safeHaskell/check/pkg01 ImpSafeOnly04 [exit code non-0] (normal) safeHaskell/check/pkg01 ImpSafeOnly05 [stderr mismatch] (normal) safeHaskell/check/pkg01 ImpSafeOnly06 [exit code non-0] (normal) safeHaskell/check/pkg01 ImpSafeOnly07 [stderr mismatch] (normal) safeHaskell/check/pkg01 ImpSafeOnly08 [stderr mismatch] (normal) safeHaskell/check/pkg01 ImpSafeOnly09 [stderr mismatch] (normal) safeHaskell/check/pkg01 ImpSafeOnly10 [exit code non-0] (normal) safeHaskell/check/pkg01 safePkg01 [bad exit code] (normal) ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Windows linking
Austin Ok with the new msys2 I get the too-many-symbols thing below. This didn't happen before. Maybe I can switch off dynamic linking? How? Simon Too many symbols in DLL compiler/stage2/build/libHSghc-7.7.20131107-0-ghc7.7.20131107.dll [5263] ghczm7zi7zi20131107_Var_zdfUniquableVar_closure [5264] ghczm7zi7zi20131107_Var_zdfUniquableVar_info [5265] ghczm7zi7zi20131107_Var_zdwsetVarUnique_closure [5266] ghczm7zi7zi20131107_Var_zdwsetVarUnique_info [5267] ghczm7zi7zi20131107_Var_zdwupdateTyVarKindM_closure [5268] ghczm7zi7zi20131107_Var_zdwupdateTyVarKindM_info [5269] ghczm7zi7zi20131107_Var_zdwzdcgmapMp_closure [5270] ghczm7zi7zi20131107_Var_zdwzdcgmapMp_info [5271] setHeapSize compiler/ghc.mk:472: recipe for target 'compiler/stage2/build/libHSghc-7.7.20131107-0-ghc7.7.20131107.dll' failed make[1]: *** [compiler/stage2/build/libHSghc-7.7.20131107-0-ghc7.7.20131107.dll] Error 1 make[1]: *** Deleting file 'compiler/stage2/build/libHSghc-7.7.20131107-0-ghc7.7.20131107.dll' Makefile:64: recipe for target 'all' failed make: *** [all] Error 2 HEAD $ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
windows agiain
Austin
I'm crashing in the testsuite as below. On Windows with the new msys. Any
ideas?
How do I set my "Windows terminal type"?
Simon
python2 ../../../driver/runtests.py -e
ghc_compiler_always_flags="'-fforce-recomp -dcore-lint -dcmm-lint
-dno-debug-output -no-user-package-db -rtsopts '" -e ghc_debugged=False -e
ghc_with_native_codegen=1 -e ghc_with_vanilla=1 -e ghc_with_dynamic=1 -e
ghc_with_profiling=0 -e ghc_with_threaded_rts=1 -e ghc_with_dynamic_rts=1 -e
ghc_with_interpreter=0 -e ghc_unregisterised=0 -e ghc_dynamic_by_default=False
-e ghc_dynamic=False -e ghc_with_smp=1 -e ghc_with_llvm=0 -e windows=True -e
darwin=False -e in_tree_compiler=True -e clean_only=False --rootdir=.
--config=../../../config/ghc -e 'config.confdir="../../../config"' -e
'config.compiler="C:/code/HEAD/inplace/bin/ghc-stage1.exe"' -e
'config.ghc_pkg="C:/code/HEAD/inplace/bin/ghc-pkg.exe"' -e
'config.hp2ps="C:/code/HEAD/inplace/bin/hp2ps.exe"' -e
'config.hpc="C:/code/HEAD/inplace/bin/hpc.exe"' -e 'config.gs="gs"' -e
'config.platform="i386-unknown-mingw32"' -e 'config.os="mingw32"' -e
'config.arch="i386"' -e 'config.wordsize="32"' -e 'default_testopts.cleanup=""'
-e 'config.timeout=int() or config.timeout' -e
'config.timeout_prog="../../../timeout/install-inplace/bin/timeout.exe"' -e
'config.exeext=".exe"' -e 'config.top="C:/code/HEAD/testsuite"' \
--only=T8037 \
\
\
\
\
\
Traceback (most recent call last):
File "../../../driver/runtests.py", line 144, in
raise Exception("Can't detect Windows terminal type")
Exception: Can't detect Windows terminal type
../../../mk/test.mk:242: recipe for target 'test' failed
make: *** [test] Error 1
should_compile $
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Windows build
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
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
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@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Windows breakage
Stefan, Guys This commit breaks the Windows build (ie my laptop) commit 9fd507e5758f4141ac2619f0db57136bcab035c6 Author: Sergei Trofimovich Date: Fri May 23 23:58:06 2014 +0300 Raise exceptions when blocked in bad FDs (fixes Trac #4934) The breakage is this: C:/code/HEAD/rts/dist/build/libHSrts.a(RtsStartup.o):RtsStartup.c:(.text+0x2aa): undefined reference to `base_GHCziEventziThread_blockedOnBadFD_closure' The reason is, I think that that this line in RtsStartup.c should be inside the guard #ifndef mingw32_HOST_OS getStablePtr((StgPtr)blockedOnBadFD_closure); I'd do that myself but I am not confident that the fix is correct; and I would like to add a comment to explain why the getStablePtr is non-windows-only. Can someone do this, please? Thanks Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Windows failures
Tamar Things are getting better. Here's my list of testsuite failure on Windows, based on last night's HEAD. Still 16 failures. Simon Unexpected failures: plugins/plugin-recomp-change.runplugin-recomp-change [bad exit code] (normal) rts/T10672/T10672_x64.run T10672_x64 [bad exit code] (normal) simplCore/should_compile/T7702.run T7702 [exit code non-0] (normal) th/T10596.run T10596 [exit code non-0] (normal) th/TH_spliceE1.run TH_spliceE1 [exit code non-0] (ext-interp) th/TH_PromotedList.run TH_PromotedList [exit code non-0] (ext-interp) libraries/Win32/tests/T4452.run T4452 [bad exit code] (normal) plugins/plugins07.run plugins07 [bad exit code] (normal) plugins/plugins09.run plugins09 [bad exit code] (normal) plugins/plugins10.run plugins10 [bad stdout] (normal) plugins/plugins11.run plugins11 [bad stdout] (normal) plugins/T10420.run T10420 [bad exit code] (normal) plugins/T10294a.run T10294a [bad exit code] (normal) plugins/plugin-recomp-pure.run plugin-recomp-pure [bad exit code] (normal) plugins/plugin-recomp-impure.runplugin-recomp-impure [bad exit code] (normal) plugins/plugin-recomp-flags.run plugin-recomp-flags [bad exit code] (normal) ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Windows build
I've completed a successful build on my Surface Book! Thank you. One last glitch. I'm getting the validate failure bellow. No other test requires gcc in my path. GHC itself carefully navigates to its own private gcc. Do we really want this family of tests (half a dozen variants of T11223) to rely on some random gcc, which might or might not be the same as GHC is using? Shouldn't we use 'ghc foo.c'? Simon => T11223_simple_unused_duplicate_lib(normal) 3371 of 5211 [0, 6, 1] cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-hFCtmi/test spaces/./rts/T11223/T11223_simple_unused_duplicate_lib.run" && $MAKE -s --no-print-directory t_11223_simple_unused_duplicate_lib Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: /bin/sh: gcc: command not found make[2]: *** [Makefile:42: t_11223_simple_unused_duplicate_lib] Error 127 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Windows build
On Windows I now get a lot of framework failures, below. I have not tried them all, but some work fine when run individually; e.g. make TEST=AssocTyDef09 Simon Unexpected passes: rts/T7037.run T7037 [unexpected] (normal) Unexpected failures: ghci/prog003/prog003.run prog003 [bad exit code] (ghci) plugins/plugins07.run plugins07 [bad exit code] (normal) Unexpected stat failures: perf/haddock/haddock.compiler.run haddock.compiler [stat not good enough] (normal) Framework failures: ./cabal/T5442b.run T5442b [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./codeGen/should_run/cgrun040.runcgrun040 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./concurrent/should_run/conc027.run conc027 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./deSugar/should_run/dsrun010.rundsrun010 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./dph/sumnats/dph-sumnats-vseg.run dph-sumnats-vseg [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./dph/words/dph-words-copy-fast.run dph-words-copy-fast [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./driver/T9963.run T9963 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./ghci/scripts/ghci044a.run ghci044a [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./ghci/scripts/T4127.run T4127 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./ghci/should_run/ghcirun001.run ghcirun001 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./overloadedlists/should_fail/overloadedlistsfail02.run overloadedlistsfail02 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./package/package07e.run package07e [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./parser/should_fail/ParserNoForallUnicode.run ParserNoForallUnicode [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./parser/should_fail/T12051.run T12051 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./perf/should_run/T4830.run T4830 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./plugins/plugins07.run plugins07 [normal] (pre_cmd failed: 2) ./rts/stack003.run stack003 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./rts/ffishutdown.runffishutdown [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./simplCore/should_compile/T3234.run T3234 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./typecheck/should_compile/tc217.run tc217 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./typecheck/should_fail/tcfail013.runtcfail013 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./typecheck/should_fail/tcfail110.runtcfail110 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./typecheck/should_fail/AssocTyDef09.run AssocTyDef09 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ../../libraries/base/tests/stableptr003.run stableptr003 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ../../libraries/base/tests/IO/ioeGetErrorString001.run ioeGetErrorString001 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Windows build
Thanks for all the work you've been doing on the Windows build. As requested by Tamar I removed ghc-tarballs, and reconfigured. Then I built from scratch. I get the following testsuite failures Simon Unexpected failures: ghci/prog003/prog003.runprog003 [bad exit code] (ghci) plugins/plugins05.run plugins05 [exit code non-0] (normal) plugins/plugins01.run plugins01 [bad exit code] (normal) plugins/plugins07.run plugins07 [bad exit code] (normal) plugins/T10420.run T10420 [bad exit code] (normal) plugins/T10294a.run T10294a [bad exit code] (normal) plugins/T11244.run T11244 [bad stderr] (normal) plugins/T12567a.run T12567a [bad exit code] (normal) rts/testmblockalloc.run testmblockalloc [bad exit code] (normal) simplCore/should_compile/T7702.run T7702 [exit code non-0] (normal) Unexpected stat failures: perf/haddock/haddock.compiler.run haddock.compiler [stat not good enough] (normal) Framework failures: ghci/scripts/ghci062.run ghci062 [ghci-ext] ([Errno 17] File exists: '/c/Users/simonpj/AppData/Local/Temp/ghctest-anc5s5mh/test spaces/./ghci/scripts/ghci062.run') plugins/plugins07.run plugins07 [normal] (pre_cmd failed: 2) plugins/T10420.runT10420 [normal] (pre_cmd failed: 2) plugins/T10294a.run T10294a [normal] (pre_cmd failed: 2) plugins/T11244.runT11244 [normal] (pre_cmd failed: 2) th/TH_repPrim.run TH_repPrim [ext-interp] ([Errno 17] File exists: '/c/Users/simonpj/AppData/Local/Temp/ghctest-anc5s5mh/test spaces/./th/TH_repPrim.run') th/TH_repPatSig.run TH_repPatSig [ext-interp] ([Errno 17] File exists: '/c/Users/simonpj/AppData/Local/Temp/ghctest-anc5s5mh/test spaces/./th/TH_repPatSig.run') --- Begin Message --- Hi Windows devs, The Windows GCC has been updated to 6.2.0 and binutils to 2.27. At some point please rebuild using these binaries. Do throw away your old toolchain cache before getting the new one: rm -rf ghc-tarballs && ./configure --enable-tarballs-autodownload The plan is to ship these versions with GHC 8.2, though binutils will likely Get another minor bump. Thanks, Tamar ___ ghc-devs mailing list ghc-devs@haskell.org https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01%7Csimonpj%40microsoft.com%7C6e35138d79b04221212f08d418ff6c98%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636160932701710045&sdata=YZItT1igKS9nT6FrcdECJI%2BHX6NWE0U0RB1eI3f3beM%3D&reserved=0 --- End Message --- ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Windows build
Hi Tamar The current state of a clean Windows build has improved - but still has multiple failures. See below Thanks for your work on this. I can send more details if that'd be helpful Simon Unexpected failures: plugins/plugins07.run plugins07 [bad exit code] (normal) plugins/T10420.run T10420 [bad exit code] (normal) plugins/T10294a.runT10294a [bad exit code] (normal) plugins/T11244.run T11244 [bad stderr] (normal) Framework failures: backpack/cabal/bkpcabal03/bkpcabal03.run bkpcabal03 [runTest] (Unhandled exception: [Errno 90] Directory not empty: 'autogen') plugins/plugins07.run plugins07 [normal] (pre_cmd failed: 2) plugins/T10420.run T10420 [normal] (pre_cmd failed: 2) plugins/T10294a.runT10294a [normal] (pre_cmd failed: 2) plugins/plugins07.run plugins07 [runTest] (Unhandled exception: [Errno 90] Directory not empty: 'rule-defining-plugin-0.1') plugins/T11244.run T11244 [normal] (pre_cmd failed: 2) safeHaskell/check/pkg01/ImpSafeOnly03.run ImpSafeOnly03 [runTest] (Unhandled exception: [Errno 90] Directory not empty: 'safePkg01-1.0-COK8JB4prM8EuKYKd3XaX3') ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Windows build
Dear Windows folk, Here's my testsuite output for a clean build on Windows last night. Rather a lot of failures - can we reduce them? Simon SUMMARY for test run started at Wed Apr 5 01:37:30 2017 GMTST 0:50:08 spent to go through 5822 total tests, which gave rise to 16777 test cases, of which 11077 were skipped 52 had missing libraries 5486 expected passes 152 expected failures 17 caused framework failures 0 caused framework warnings 0 unexpected passes 9 unexpected failures 1 unexpected stat failures Unexpected failures: ./backpack/cabal/bkpcabal07/bkpcabal07.run bkpcabal07 [bad exit code] (normal) ./backpack/cabal/bkpcabal06/bkpcabal06.run bkpcabal06 [bad exit code] (normal) ./plugins/T10420.runT10420 [bad exit code] (normal) ./plugins/plugins07.run plugins07 [bad exit code] (normal) ./plugins/T10294a.run T10294a [bad exit code] (normal) ./plugins/T11244.runT11244 [bad stderr] (normal) ./th/T13366.run T13366 [bad exit code] (normal) ./th/T13366.run T13366 [bad exit code] (ext-interp) ../../libraries/base/tests/IO/readwrite002.run readwrite002 [bad stdout] (normal) Unexpected stat failures: perf/compiler/T5837.run T5837 [stat too good] (normal) Framework failures: . registry001 [duplicate] (There are multiple tests with this name) . helloworld [duplicate] (There are multiple tests with this name) . lasterror [duplicate] (There are multiple tests with this name) . T4452 [duplicate] (There are multiple tests with this name) . PokeTZI [duplicate] (There are multiple tests with this name) . HandleConversion [duplicate] (There are multiple tests with this name) ./indexed-types/should_fail/T13102/T13102.run T13102 [runTest] (Unhandled exception: [Errno 90] Directory not empty: '/c/Users/simonpj/AppData/Local/Temp/ghctest-1gr0gzv9/test spaces/./indexed-types/should_fail/T13102/T13102.run/orphan/dist/package.conf.inplace') ./plugins/T10420.run T10420 [normal] (pre_cmd failed: 2) ./plugins/plugins07.runplugins07 [normal] (pre_cmd failed: 2) ./plugins/T10294a.run T10294a [normal] (pre_cmd failed: 2) ./plugins/T11244.run T11244 [normal] (pre_cmd failed: 2) ./safeHaskell/check/pkg01/safePkg01.runsafePkg01 [runTest] (Unhandled exception: [Errno 90] Directory not empty: '/c/Users/simonpj/AppData/Local/Temp/ghctest-1gr0gzv9/test spaces/./safeHaskell/check/pkg01/safePkg01.run/pdb.safePkg01/install/x86_64-windows-ghc-8.3.20170324/safePkg01-1.0-EBB2cBBfiph67c3CwCtZOx') ./safeHaskell/check/pkg01/ImpSafeOnly06.runImpSafeOnly06 [runTest] (Unhandled exception: [Errno 90] Directory not empty: '/c/Users/simonpj/AppData/Local/Temp/ghctest-1gr0gzv9/test spaces/./safeHaskell/check/pkg01/ImpSafeOnly06.run/pdb.ImpSafeOnly06/install/x86_64-windows-ghc-8.3.20170324/safePkg01-1.0-EBB2cBBfiph67c3CwCtZOx') ./safeHaskell/check/pkg01/ImpSafeOnly08.runImpSafeOnly08 [runTest] (Unhandled exception: [Errno 90] Directory not empty: '/c/Users/simonpj/AppData/Local/Temp/ghctest-1gr0gzv9/test spaces/./safeHaskell/check/pkg01/ImpSafeOnly08.run/pdb.ImpSafeOnly08/install/x86_64-windows-ghc-8.3.20170324') ./simplCore/should_compile/T7702.run T7702 [runTest] (Unhandled exception: [Errno 90] Directory not empty: '/c/Users/simonpj/AppData/Local/Temp/ghctest-1gr0gzv9/test spaces/./simplCore/should_compile/T7702.run/T7702plugin/pkg.T7702/dist/package.conf.inplace') ../../libraries/Win32/tests/registry001.runregistry001 [runTest] (Unhandled exception: [Errno 2] No such file or directory: '/c/Users/simonpj/AppData/Local/Temp/ghctest-1gr0gzv9/test spaces/../../libraries/Win32/tests/registry001.run/registry001.o') ../../libraries/base/tests/IO/hDuplicateTo001.run hDuplicateTo001 [runTest] (Unhandled exception: [Err
Windows broken
Help please!
Suddenly my Windows build has stopped working. See below. What should I do?
I'm totally stuck.
This has never happened before.
I get this:
GHC path canonicalised to: c:/fp/ghc-8.0.2/bin/ghc
checking build system type... x86_64-pc-msys
checking host system type... x86_64-pc-msys
checking target system type... x86_64-pc-msys
Build platform inferred as: x86_64-unknown-mingw32
Host platform inferred as: x86_64-unknown-mingw32
Target platform inferred as: x86_64-unknown-mingw32
GHC build : x86_64-unknown-mingw32
GHC host : x86_64-unknown-mingw32
GHC target : x86_64-unknown-mingw32
LLVM target: x86_64-unknown-mingw32
checking for path to top of build tree... C:/code/HEAD
configure: Checking for Windows toolchain tarballs...
configure: Extracting Windows toolchain from archives (may take a while)...
configure: In-tree MingW-w64 tree created
configure: Making in-tree perl tree
configure: In-tree perl tree created
checking whether the C compiler works... no
configure: error: in `/c/code/HEAD':
configure: error: C compiler cannot create executables
See `config.log' for more details
Something wrong with the gcc.exe? Config.log has this
gcc version 6.3.0 (Rev2, Built by MSYS2 project)
configure:4950: $? = 0
configure:4939: C:/code/HEAD/inplace/mingw/bin/gcc.exe -V >&5
gcc.exe: error: unrecognized command line option '-V'
gcc.exe: fatal error: no input files
compilation terminated.
configure:4950: $? = 1
configure:4939: C:/code/HEAD/inplace/mingw/bin/gcc.exe -qversion >&5
gcc.exe: error: unrecognized command line option '-qversion'; did you mean
'--version'?
gcc.exe: fatal error: no input files
compilation terminated.
configure:4950: $? = 1
configure:4970: checking whether the C compiler works
configure:4992: C:/code/HEAD/inplace/mingw/bin/gcc.execonftest.c >&5
configure:4996: $? = 1
configure:5034: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "The Glorious Glasgow Haskell Compilation System"
| #define PACKAGE_TARNAME "ghc-8.3"
| #define PACKAGE_VERSION "8.3"
| #define PACKAGE_STRING "The Glorious Glasgow Haskell Compilation System 8.3"
| #define PACKAGE_BUGREPORT "glasgow-haskell-b...@haskell.org"
| #define PACKAGE_URL ""
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:5039: error: in `/c/code/HEAD':
configure:5041: error: C compiler cannot create executables
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
More windows
Now in my Windows build, staring with "sh validate -fast -no-clean" I get [230 of 232] Compiling Distribution.PackageDescription.Parsec ( libraries\Cabal\Cabal\Distribution\PackageDescription\Parsec.hs, bootstrapping\Distribution\PackageDescription\Parsec.o ) [231 of 232] Compiling Distribution.Simple ( libraries\Cabal\Cabal\Distribution\Simple.hs, bootstrapping\Distribution\Simple.o ) [232 of 232] Compiling Main ( utils\ghc-cabal\Main.hs, bootstrapping\Main.o ) Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ... "inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe utils/genprimopcode/ghc.mk:19: utils/genprimopcode/dist/package-data.mk: No such file or directory make[1]: *** [utils/ghc-cabal/ghc.mk:57: utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1 make[1]: *** Deleting file 'utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe' make: *** [Makefile:123: all] Error 2 Simply repeating, thus "sh validate -fast", I then get the same error /c/code/HEAD$ ls -l utils/ghc-cabal/dist/build/tmp/ total 0 /c/code/HEAD$ sh validate --fast --no-clean using THREADS=5 make: Entering directory '/c/code/HEAD/utils/checkUniques' ./check-uniques.py ../.. make: Leaving directory '/c/code/HEAD/utils/checkUniques' ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds "c:/fp/ghc-8.0.2/bin/ghc.exe" -O0 -H64m -Wall \ -optc-Wall -optc-Werror -optc-fno-stack-protector \ \ -hide-all-packages \ -package ghc-prim -package base -package array -package transformers -package time -package containers -package bytestring -package deepseq -package process -package pretty -package directory -package Win32 \ --make utils/ghc-cabal/Main.hs -o utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe \ -no-user-package-db \ -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \ -DCABAL_VERSION=2,0,0,2 \ -DCABAL_PARSEC \ -DBOOTSTRAPPING \ -odir bootstrapping \ -hidir bootstrapping \ bootstrapping/Cabal/Distribution/Parsec/Lexer.hs \ -ilibraries/Cabal/Cabal \ -ilibraries/binary/src \ -ilibraries/filepath \ -ilibraries/hpc \ -ilibraries/mtl \ -ilibraries/text \ libraries/text/cbits/cbits.c \ -Ilibraries/text/include \ -ilibraries/parsec \ \ Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ... "inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe make[1]: *** [utils/ghc-cabal/ghc.mk:57: utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1 make[1]: *** Deleting file 'utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe' make: *** [Makefile:123: all] Error 2 But trying "sh validate -fast" once more succeeds: /c/code/HEAD$ sh validate --fast --no-clean using THREADS=5 make: Entering directory '/c/code/HEAD/utils/checkUniques' ./check-uniques.py ../.. make: Leaving directory '/c/code/HEAD/utils/checkUniques' ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds "c:/fp/ghc-8.0.2/bin/ghc.exe" -O0 -H64m -Wall \ -optc-Wall -optc-Werror -optc-fno-stack-protector \ \ -hide-all-packages \ -package ghc-prim -package base -package array -package transformers -package time -package containers -package bytestring -package deepseq -package process -package pretty -package directory -package Win32 \ --make utils/ghc-cabal/Main.hs -o utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe \ -no-user-package-db \ -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \ -DCABAL_VERSION=2,0,0,2 \ -DCABAL_PARSEC \ -DBOOTSTRAPPING \ -odir bootstrapping \ -hidir bootstrapping \ bootstrapping/Cabal/Distribution/Parsec/Lexer.hs \ -ilibraries/Cabal/Cabal \ -ilibraries/binary/src \ -ilibraries/filepath \ -ilibraries/hpc \ -ilibraries/mtl \ -ilibraries/text \ libraries/text/cbits/cbits.c \ -Ilibraries/text/include \ -ilibraries/parsec \ \ Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ... "inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe "cp" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe inplace/bin/ghc-cabal.exe "inplace/bin/ghc-cabal.exe" configure libraries/binary dist-boot --with-ghc="c:/fp/ghc-8.0.2/bin/ghc.exe" --with-ghc-pkg="c:/fp/ghc-8.0.2/bin/ghc-pkg" --package-db=C:/code/HEAD/libraries/bootstrapping.conf --disable-library-for-ghci --enable-library-vanilla --enable-library-for-ghci --disable-library-profiling --
RE: Windows
Hi Simon, You need export MSYSTEM=MINGW64 in your bash profile. Regards, Tamar From: Simon Peyton Jones via ghc-devs Sent: Friday, March 23, 2018 22:21 To: ghc-devs@haskell.org Subject: Windows I’ve just got a new laptop (the old one’s hard disk died) so I’m trying to get to the point of being able to build GHC again. I’m currently stuck here: ./configure configure: loading site script /usr/local/etc/config.site checking for gfind... no checking for find... /usr/bin/find checking for sort... /usr/bin/sort checking for GHC version date... inferred 8.5.20180323 checking for GHC Git commit id... inferred affdea82bb70e5a912b679a169c6e9a230e4c93e checking for ghc... /c/fp/HP-8.2.2/bin/ghc checking version of ghc... 8.2.2 GHC path canonicalised to: c:/fp/HP-8.2.2/bin/ghc checking build system type... x86_64-pc-msys checking host system type... x86_64-pc-msys checking target system type... x86_64-pc-msys Unknown OS msys Any ideas? Thanks Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Windows
Just an idea... could this hint be part of the `configure` error message? Gabor On 3/23/18, loneti...@gmail.com wrote: > Hi Simon, > > You need > > export MSYSTEM=MINGW64 > > in your bash profile. > > Regards, > Tamar > > From: Simon Peyton Jones via ghc-devs > Sent: Friday, March 23, 2018 22:21 > To: ghc-devs@haskell.org > Subject: Windows > > I’ve just got a new laptop (the old one’s hard disk died) so I’m trying to > get to the point of being able to build GHC again. > I’m currently stuck here: > ./configure > configure: loading site script /usr/local/etc/config.site > checking for gfind... no > checking for find... /usr/bin/find > checking for sort... /usr/bin/sort > checking for GHC version date... inferred 8.5.20180323 > checking for GHC Git commit id... inferred > affdea82bb70e5a912b679a169c6e9a230e4c93e > checking for ghc... /c/fp/HP-8.2.2/bin/ghc > checking version of ghc... 8.2.2 > GHC path canonicalised to: c:/fp/HP-8.2.2/bin/ghc > checking build system type... x86_64-pc-msys > checking host system type... x86_64-pc-msys > checking target system type... x86_64-pc-msys > Unknown OS msys > Any ideas? > Thanks > Simon > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Windows
Gabor Greif writes: > Just an idea... > > could this hint be part of the `configure` error message? > Indeed. See D4526. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Windows
Making it part of the error message would be v helpful. I have added a section to "Troubleshooting" on https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows But it should really be part of the instructions higher up to sa export MSYSTEM=MINGW64 Might someone do that? I wasn't quite sure where Simon | -Original Message- | From: ghc-devs On Behalf Of Ben Gamari | Sent: 24 March 2018 16:42 | To: Gabor Greif ; loneti...@gmail.com | Cc: ghc-devs@haskell.org | Subject: Re: Windows | | Gabor Greif writes: | | > Just an idea... | > | > could this hint be part of the `configure` error message? | > | Indeed. See D4526. | | Cheers, | | - Ben ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Windows
Hi Simon, If the build environment is managed by an MSYS2 installation, then the MinGW64 shell startup script automatically sets up "MSYSTEM" for you. It can be launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty". On Mon, Mar 26, 2018 at 5:46 PM, Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote: > Making it part of the error message would be v helpful. > > I have added a section to "Troubleshooting" on > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows > > But it should really be part of the instructions higher up to sa > export MSYSTEM=MINGW64 > > Might someone do that? I wasn't quite sure where > > Simon > > | -Original Message- > | From: ghc-devs On Behalf Of Ben Gamari > | Sent: 24 March 2018 16:42 > | To: Gabor Greif ; loneti...@gmail.com > | Cc: ghc-devs@haskell.org > | Subject: Re: Windows > | > | Gabor Greif writes: > | > | > Just an idea... > | > > | > could this hint be part of the `configure` error message? > | > > | Indeed. See D4526. > | > | Cheers, > | > | - Ben > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Windows
If the build environment is managed by an MSYS2 installation, then the MinGW64 shell startup script automatically sets up "MSYSTEM" for you. It can be launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty". Well I just followed the Method A instructions at https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows Are you saying that I should run “C:\msys64\msys2_shell.cmd -mingw64 -mintty" just once, after installing? Or repeatedly? Or that I should somehow us it as my main shell? And what does that commend actually do? Sorry to be dense Simon From: ghc-devs On Behalf Of Shao, Cheng Sent: 26 March 2018 10:59 To: ghc-devs@haskell.org Subject: Re: Windows Hi Simon, If the build environment is managed by an MSYS2 installation, then the MinGW64 shell startup script automatically sets up "MSYSTEM" for you. It can be launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty". On Mon, Mar 26, 2018 at 5:46 PM, Simon Peyton Jones via ghc-devs mailto:ghc-devs@haskell.org>> wrote: Making it part of the error message would be v helpful. I have added a section to "Troubleshooting" on https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows But it should really be part of the instructions higher up to sa export MSYSTEM=MINGW64 Might someone do that? I wasn't quite sure where Simon | -Original Message- | From: ghc-devs mailto:ghc-devs-boun...@haskell.org>> On Behalf Of Ben Gamari | Sent: 24 March 2018 16:42 | To: Gabor Greif mailto:ggr...@gmail.com>>; loneti...@gmail.com<mailto:loneti...@gmail.com> | Cc: ghc-devs@haskell.org<mailto:ghc-devs@haskell.org> | Subject: Re: Windows | | Gabor Greif mailto:ggr...@gmail.com>> writes: | | > Just an idea... | > | > could this hint be part of the `configure` error message? | > | Indeed. See D4526. | | Cheers, | | - Ben ___ ghc-devs mailing list ghc-devs@haskell.org<mailto:ghc-devs@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Windows
Hi Simon, Running “C:\msys64\msys2_shell.cmd -mingw64 -mintty" has the same effect as clicking on the "MinGW-w64 Win64 Shell" shortcut. It is the proper way to start an mingw64 shell. If you have run "pacman -S" to update the MSYS2 packages before, then the old shortcuts setup by the MSYS2 installer may cease to function, and you can put a new shortcut on your desktop with that command. On Mon, Mar 26, 2018 at 6:02 PM, Simon Peyton Jones wrote: > If the build environment is managed by an MSYS2 installation, then the > MinGW64 shell startup script automatically sets up "MSYSTEM" for you. It > can be launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty". > > Well I just followed the Method A instructions at > > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows > > > > Are you saying that I should run “C:\msys64\msys2_shell.cmd -mingw64 > -mintty" just once, after installing? Or repeatedly? Or that I should > somehow us it as my main shell? And what does that commend actually do? > > Sorry to be dense > > > > Simon > > > > *From:* ghc-devs *On Behalf Of *Shao, Cheng > *Sent:* 26 March 2018 10:59 > *To:* ghc-devs@haskell.org > *Subject:* Re: Windows > > > > Hi Simon, > > > > If the build environment is managed by an MSYS2 installation, then the > MinGW64 shell startup script automatically sets up "MSYSTEM" for you. It > can be launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty". > > > > On Mon, Mar 26, 2018 at 5:46 PM, Simon Peyton Jones via ghc-devs < > ghc-devs@haskell.org> wrote: > > Making it part of the error message would be v helpful. > > I have added a section to "Troubleshooting" on > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows > > But it should really be part of the instructions higher up to sa > export MSYSTEM=MINGW64 > > Might someone do that? I wasn't quite sure where > > Simon > > > | -Original Message- > | From: ghc-devs On Behalf Of Ben Gamari > | Sent: 24 March 2018 16:42 > | To: Gabor Greif ; loneti...@gmail.com > | Cc: ghc-devs@haskell.org > | Subject: Re: Windows > | > | Gabor Greif writes: > | > | > Just an idea... > | > > | > could this hint be part of the `configure` error message? > | > > | Indeed. See D4526. > | > | Cheers, > | > | - Ben > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Windows
One other thing. The instructions at https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows say to set PATH thus export PATH=/mingw64/bin:\$PATH But * in the installation tree I got from msys, there IS no c:/mingw64/bin. * I have a root directory c:/msys64. * Most binaries (eg bash, find) seem to be in c:/mingw64/usr/bin * But there is also c:/msys64/mingw64/bin, which (perhaps as a result of the pacman step) has lots more stuf like ar, cc, etc. All very confusing. For now I have put both c:/msys64/usr/bin and c:/msys64/mingw64/bin in my path. That seems to work, but is clearly not what the instructions say. Thanks Simon From: ghc-devs On Behalf Of Shao, Cheng Sent: 26 March 2018 10:59 To: ghc-devs@haskell.org Subject: Re: Windows Hi Simon, If the build environment is managed by an MSYS2 installation, then the MinGW64 shell startup script automatically sets up "MSYSTEM" for you. It can be launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty". On Mon, Mar 26, 2018 at 5:46 PM, Simon Peyton Jones via ghc-devs mailto:ghc-devs@haskell.org>> wrote: Making it part of the error message would be v helpful. I have added a section to "Troubleshooting" on https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows But it should really be part of the instructions higher up to sa export MSYSTEM=MINGW64 Might someone do that? I wasn't quite sure where Simon | -Original Message- | From: ghc-devs mailto:ghc-devs-boun...@haskell.org>> On Behalf Of Ben Gamari | Sent: 24 March 2018 16:42 | To: Gabor Greif mailto:ggr...@gmail.com>>; loneti...@gmail.com<mailto:loneti...@gmail.com> | Cc: ghc-devs@haskell.org<mailto:ghc-devs@haskell.org> | Subject: Re: Windows | | Gabor Greif mailto:ggr...@gmail.com>> writes: | | > Just an idea... | > | > could this hint be part of the `configure` error message? | > | Indeed. See D4526. | | Cheers, | | - Ben ___ ghc-devs mailing list ghc-devs@haskell.org<mailto:ghc-devs@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Windows
“C:\msys64\msys2_shell.cmd -mingw64 -mintty” Won’t work for you as it spawns a new process using mintty as your terminal emulator. If I remember correctly you have a setup where you use bash directly in emacs. In which case you just need To set the environment variables and add /mingw64/bin to your path. I would personally avoid the use of mintty because of how it implements pty. Lots of interactive programs don’t work Correctly under it, including ghci where we need specific hacks to work around some of it’s issues https://github.com/mintty/mintty/issues/56. From: Simon Peyton Jones via ghc-devs Sent: Monday, March 26, 2018 11:03 To: Shao, Cheng; ghc-devs@haskell.org Subject: RE: Windows If the build environment is managed by an MSYS2 installation, then the MinGW64 shell startup script automatically sets up "MSYSTEM" for you. It can be launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty". Well I just followed the Method A instructions at https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows Are you saying that I should run “C:\msys64\msys2_shell.cmd -mingw64 -mintty" just once, after installing? Or repeatedly? Or that I should somehow us it as my main shell? And what does that commend actually do? Sorry to be dense Simon From: ghc-devs On Behalf Of Shao, Cheng Sent: 26 March 2018 10:59 To: ghc-devs@haskell.org Subject: Re: Windows Hi Simon, If the build environment is managed by an MSYS2 installation, then the MinGW64 shell startup script automatically sets up "MSYSTEM" for you. It can be launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty". On Mon, Mar 26, 2018 at 5:46 PM, Simon Peyton Jones via ghc-devs wrote: Making it part of the error message would be v helpful. I have added a section to "Troubleshooting" on https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows But it should really be part of the instructions higher up to sa export MSYSTEM=MINGW64 Might someone do that? I wasn't quite sure where Simon | -Original Message- | From: ghc-devs On Behalf Of Ben Gamari | Sent: 24 March 2018 16:42 | To: Gabor Greif ; loneti...@gmail.com | Cc: ghc-devs@haskell.org | Subject: Re: Windows | | Gabor Greif writes: | | > Just an idea... | > | > could this hint be part of the `configure` error message? | > | Indeed. See D4526. | | Cheers, | | - Ben ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Windows
Running “C:\msys64\msys2_shell.cmd -mingw64 -mintty" has the same effect as clicking on the "MinGW-w64 Win64 Shell" shortcut. It is the proper way to start an mingw64 shell. Interesting. Most shells are started by ‘make’. I think it uses the SHELL envt variable to decide what to start. Currently I have that set to * c:/msys64/usr/bin/bash Are you saying that I should put * C:\msys64\msys2_shell.cmd -mingw64 -mintty into my SHELL envt variable? (Also: I always a shell within emacs, rather that an msys window, and it uses SHELL to decide what to run.) Also: is this related to the export MSYSTEM=MINGW64 question? Thanks Simon From: ghc-devs On Behalf Of Shao, Cheng Sent: 26 March 2018 11:07 To: ghc-devs@haskell.org Subject: Re: Windows Hi Simon, Running “C:\msys64\msys2_shell.cmd -mingw64 -mintty" has the same effect as clicking on the "MinGW-w64 Win64 Shell" shortcut. It is the proper way to start an mingw64 shell. If you have run "pacman -S" to update the MSYS2 packages before, then the old shortcuts setup by the MSYS2 installer may cease to function, and you can put a new shortcut on your desktop with that command. On Mon, Mar 26, 2018 at 6:02 PM, Simon Peyton Jones mailto:simo...@microsoft.com>> wrote: If the build environment is managed by an MSYS2 installation, then the MinGW64 shell startup script automatically sets up "MSYSTEM" for you. It can be launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty". Well I just followed the Method A instructions at https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows Are you saying that I should run “C:\msys64\msys2_shell.cmd -mingw64 -mintty" just once, after installing? Or repeatedly? Or that I should somehow us it as my main shell? And what does that commend actually do? Sorry to be dense Simon From: ghc-devs mailto:ghc-devs-boun...@haskell.org>> On Behalf Of Shao, Cheng Sent: 26 March 2018 10:59 To: ghc-devs@haskell.org<mailto:ghc-devs@haskell.org> Subject: Re: Windows Hi Simon, If the build environment is managed by an MSYS2 installation, then the MinGW64 shell startup script automatically sets up "MSYSTEM" for you. It can be launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty". On Mon, Mar 26, 2018 at 5:46 PM, Simon Peyton Jones via ghc-devs mailto:ghc-devs@haskell.org>> wrote: Making it part of the error message would be v helpful. I have added a section to "Troubleshooting" on https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows But it should really be part of the instructions higher up to sa export MSYSTEM=MINGW64 Might someone do that? I wasn't quite sure where Simon | -Original Message- | From: ghc-devs mailto:ghc-devs-boun...@haskell.org>> On Behalf Of Ben Gamari | Sent: 24 March 2018 16:42 | To: Gabor Greif mailto:ggr...@gmail.com>>; loneti...@gmail.com<mailto:loneti...@gmail.com> | Cc: ghc-devs@haskell.org<mailto:ghc-devs@haskell.org> | Subject: Re: Windows | | Gabor Greif mailto:ggr...@gmail.com>> writes: | | > Just an idea... | > | > could this hint be part of the `configure` error message? | > | Indeed. See D4526. | | Cheers, | | - Ben ___ ghc-devs mailing list ghc-devs@haskell.org<mailto:ghc-devs@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Windows
I would personally avoid the use of mintty because of how it implements pty OK thanks. If I remember correctly you have a setup where you use bash directly in emacs. Correct In which case you just need To set the environment variables and add /mingw64/bin to your path. But set which envt variables to what, precisely? As I say in another email, c:/mingw64 doesn’t exist. c:/msys64 does, and c:/msys64/mingw64. Very confusing! Thanks Simon From: loneti...@gmail.com Sent: 26 March 2018 11:09 To: Simon Peyton Jones ; Shao, Cheng ; ghc-devs@haskell.org Subject: RE: Windows “C:\msys64\msys2_shell.cmd -mingw64 -mintty” Won’t work for you as it spawns a new process using mintty as your terminal emulator. If I remember correctly you have a setup where you use bash directly in emacs. In which case you just need To set the environment variables and add /mingw64/bin to your path. I would personally avoid the use of mintty because of how it implements pty. Lots of interactive programs don’t work Correctly under it, including ghci where we need specific hacks to work around some of it’s issues https://github.com/mintty/mintty/issues/56. From: Simon Peyton Jones via ghc-devs<mailto:ghc-devs@haskell.org> Sent: Monday, March 26, 2018 11:03 To: Shao, Cheng<mailto:cheng.s...@tweag.io>; ghc-devs@haskell.org<mailto:ghc-devs@haskell.org> Subject: RE: Windows If the build environment is managed by an MSYS2 installation, then the MinGW64 shell startup script automatically sets up "MSYSTEM" for you. It can be launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty". Well I just followed the Method A instructions at https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows Are you saying that I should run “C:\msys64\msys2_shell.cmd -mingw64 -mintty" just once, after installing? Or repeatedly? Or that I should somehow us it as my main shell? And what does that commend actually do? Sorry to be dense Simon From: ghc-devs mailto:ghc-devs-boun...@haskell.org>> On Behalf Of Shao, Cheng Sent: 26 March 2018 10:59 To: ghc-devs@haskell.org<mailto:ghc-devs@haskell.org> Subject: Re: Windows Hi Simon, If the build environment is managed by an MSYS2 installation, then the MinGW64 shell startup script automatically sets up "MSYSTEM" for you. It can be launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty". On Mon, Mar 26, 2018 at 5:46 PM, Simon Peyton Jones via ghc-devs mailto:ghc-devs@haskell.org>> wrote: Making it part of the error message would be v helpful. I have added a section to "Troubleshooting" on https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows But it should really be part of the instructions higher up to sa export MSYSTEM=MINGW64 Might someone do that? I wasn't quite sure where Simon | -Original Message- | From: ghc-devs mailto:ghc-devs-boun...@haskell.org>> On Behalf Of Ben Gamari | Sent: 24 March 2018 16:42 | To: Gabor Greif mailto:ggr...@gmail.com>>; loneti...@gmail.com<mailto:loneti...@gmail.com> | Cc: ghc-devs@haskell.org<mailto:ghc-devs@haskell.org> | Subject: Re: Windows | | Gabor Greif mailto:ggr...@gmail.com>> writes: | | > Just an idea... | > | > could this hint be part of the `configure` error message? | > | Indeed. See D4526. | | Cheers, | | - Ben ___ ghc-devs mailing list ghc-devs@haskell.org<mailto:ghc-devs@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01%7Csimonpj%40microsoft.com%7Ceee757b199a44030ad4308d59301a528%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636576557630037503&sdata=LhSYEM%2Bt6PcvOkJulJDFO0Ox4F8jlYcp0KozK8KDciY%3D&reserved=0> ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Windows
On Mon, Mar 26, 2018 at 11:08 AM, Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote: > One other thing. The instructions at > > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows > > say to set PATH thus > > > > export PATH=/mingw64/bin:\$PATH > > > > But > >- in the installation tree I got from msys, *there IS no >c:/mingw64/bin*. >- I have a root directory c:/msys64. > > These are correct, the instructions are written from the point of view of a msys2 environment and not the Windows one. So /mingw64 refers to an msys2 path not a windows path. In windows the / would indeed be interpreted to %HOMEDRIVE%/mingw64 but in msys2 this refers to what the msy2 filesystem has been mounted to. This is usually C:\msys64. Tamar@Yelow ~/ghc2> cygpath -w /mingw64/bin/ E:\msys64\mingw64\bin\ the msys2 tool cygpath converts between the two usually on demand. but you can query it for paths. What the instructions intended was for you to modify your msys2 environment, not your Windows one, as generally putting Cygwin derived programs on your global windows path is not advisable. > >- >- Most binaries (eg *bash*, *find*) seem to be in c:/mingw64/usr/bin > > Yes, any binary that is a posix port, e.g. depends on newlib crt instead of the Microsoft runtime goes into the usual /usr/bin folder. This would include core-utils, make etc. > >- >- But there is also c:/msys64/mingw64/bin, which (perhaps as a result >of the pacman step) has lots more stuf like *ar*, *cc*, etc. > > This folder is meant to contain native ports, e.g. programs that have been "ported" to work on Windows using a standard windows runtime. These have no dependencies on newlib/Cygwin. This is the distinctions between these two folders. >- > > > > All very confusing. For now I have put both c:/msys64/usr/bin and > c:/msys64/mingw64/bin in my path. That seems to work, but is clearly not > what the instructions say. > The instruction could be somewhat clearer here, but they are intended to only affect your msys2 installation, and never your global Windows system. > > > Thanks > > > > Simon > > > > *From:* ghc-devs *On Behalf Of *Shao, Cheng > *Sent:* 26 March 2018 10:59 > *To:* ghc-devs@haskell.org > *Subject:* Re: Windows > > > > Hi Simon, > > > > If the build environment is managed by an MSYS2 installation, then the > MinGW64 shell startup script automatically sets up "MSYSTEM" for you. It > can be launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty". > > > > On Mon, Mar 26, 2018 at 5:46 PM, Simon Peyton Jones via ghc-devs < > ghc-devs@haskell.org> wrote: > > Making it part of the error message would be v helpful. > > I have added a section to "Troubleshooting" on > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows > > But it should really be part of the instructions higher up to sa > export MSYSTEM=MINGW64 > > Might someone do that? I wasn't quite sure where > > Simon > > > | -Original Message- > | From: ghc-devs On Behalf Of Ben Gamari > | Sent: 24 March 2018 16:42 > | To: Gabor Greif ; loneti...@gmail.com > | Cc: ghc-devs@haskell.org > | Subject: Re: Windows > | > | Gabor Greif writes: > | > | > Just an idea... > | > > | > could this hint be part of the `configure` error message? > | > > | Indeed. See D4526. > | > | Cheers, > | > | - Ben > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
More windows
Tamar I've noticed that "sh" (which is invoked at lot by make etc) takes AGES to start up. At least I think it's 'sh' that is causing the delay. I think it's c:/msys64/usr/bin/sh.exe >From searching the web (eg >https://www2.cs.duke.edu/csl/docs/unix_course/intro-60.html) it seems likely >that it executes c:/msys64/etc/profile first. And If I put an 'echo' at the start and end of that file, they do seem to take place with a significant gap between them. I have not started sprinkling more echos, but does that ring any bells? Can I replace 'sh' with c:/msys64/usr/bin/bash.exe, which seems to be faster? (My evnt variable SHELL already points to bash.exe. ) And if so, how would I do that? An environment variable. Physically copy bash.exe to sh.exe? Or what? Thanks Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Windows rework merged ; fresh build necessary on Windows
Hi all, A few minutes ago I merged !7448 and the associated MRs, moving GHC to use the msys2 Clang64 toolchain on Windows. This work improves compilation time, maintainability, and fixes a numerous long-standing bugs affecting Windows and other platforms. However, as a result you may find that in an existing tree `configure` will fail with an error complaining that `clang` can not be found. This is due to the fact that the toolchain tarballs are stale and be fixed with: rm -R _build inplace/mingw win32-tarballs ./boot ./configure --enable-tarballs-autodownload Do let me know if you see any other issues; I'm a bit under the weather at the moment but I'll try to keep an eye on email. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Compiling on Windows
Hi, At ICFP Simon Peyton Jones encouraged me to compile GHC on Windows. I did so in the past about 5 years ago, and it was a painful experience. To help improve the path for those who come after me, I kept a log (which I'll share after I get a working build). My current state is that I get an error while running make while building stage2: "inplace/bin/ghc-stage1.exe" -hisuf hi -osuf o -hcsuf hc -static -H32m -O-this-package-key haske_9y30zKcKDr9BxdhpktYrNk -hide-all-packages -i -ilibraries/haskeline/. -ilibraries/haskeline/dist-install/build -ilibraries/haskeline/dist-install/build/autogen -Ilibraries/haskeline/dist-install/build -Ilibraries/haskeline/dist-install/build/autogen -Ilibraries/haskeline/includes -optP-DUSE_GHC_ENCODINGS -optP-DMINGW -optP-include -optPlibraries/haskeline/dist-install/build/autogen/cabal_macros.h -package-key Win32_43THQMouBnk2wpnouztX1X -package-key base_ESD4aQEEWwsHtYJVc1BwtJ -package-key bytes_Kc0PyaputnzDnBdZW0y2Gv -package-key conta_ChF4XLXB9JmByIycPzerow -package-key direc_6qC0tVrFkqbBNeWAGS0s7g -package-key filep_34DFDFT9FVD9pRLLgh8IdQ -package-key trans_5jw4w9yTgmZ89ByuixDAKP -Wall -XHaskell98 -XForeignFunctionInterface -XRank2Types -XFlexibleInstances -XTypeSynonymInstances -XFlexibleContexts -XExistentialQuantification -XScopedTypeVariables -XGeneralizedNewtypeDeriving -XMultiParamTypeClasses -XOverlappingInstances -XUndecidableInstances -XCPP -XDeriveDataTypeable -XPatternGuards -O2 -no-user-package-db -rtsopts -odir libraries/haskeline/dist-install/build -hidir libraries/haskeline/dist-install/build -stubdir libraries/haskeline/dist-install/build -split-objs -c libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.hs -o libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.o on the commandline: Warning: -XOverlappingInstances is deprecated: instead use per-instance pragmas OVERLAPPING/OVERLAPPABLE/OVERLAPS librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:15: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Monad (Draw m)) librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:21: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (MonadIO (Draw m)) librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:29: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (MonadException (Draw m)) librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:45: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (MonadReader Handles (Draw m)) libraries/haskeline/ghc.mk:4: recipe for target 'libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.o' failed make[1]: *** [libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.o] Error 1 Makefile:71: recipe for target 'all' failed make: *** [all] Error 2 Any idea how to overcome that? I note from the weekly update email that there was an email on Windows last night, but a "./sync-all pull" doesn't make it go away. Thanks, Neil ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Building on Windows
Hi, I just successfully built GHC on Windows. Last time I tried (5 years ago) it took days. This time, it took hours, plus a bit of waiting for a Windows specific breakage to be fixed. I made a log of what happened, what confused me, what wasn't clear etc - hopefully these provide suggestions for improving the wiki (if my thoughts are actually correct). The worst aspect is that the Windows wiki page has 6 sets of instructions, with no obvious way to pick the right one - everything else was pretty minor. Thanks, Neil My first step was to Google "build ghc on windows", which took me to https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows "The instructions are current for GHC 7.6" - so they are not current. "Other documentation for Windows includes:" - here are 5 alternate links, any of which may be better/worse than this one. I have no way to tell. As a piece of documentation, giving the uninformed user 6 options with no sensible way to make a decision is awful. Simon PJ had said "MSYS2" works well, so I clicked that one. Even though it appears to be the "wrong" one according to the wiki. Is it the correct one? If so, replace the Windows page with it. If not, perhaps indicate which one is. "It should get you running in ~5 minutes, modulo download speeds." - nice! It's a long way from being true, since you also need to include extraction times and build times (which on my machine far outweight download times). There were also enough hiccups that it took me about an hour of clicking/typing, excluding the Windows specific bug I ran into. If I have 64bit OS, should I pick 64bit Windows? Or only if I want to develop 64bit Windows, which isn't the default? Fortunately my machine is old enough to be 32 bits so I didn't have the difficult question. It's far easier to edit the PATH file manually with $ cygpath -w ~, which returns C:\msys32\home\Neil, than to echo stuff to it. In particular, if you echo anything wrong, you need to edit it anyway. "Do not install python, python2 or gcc!" - it's not entirely clear how to achieve that. It installed gcc-libs, is that a problem? I'd have liked a better "check" step, e.g. run "gcc --version", "ghc --version" and exactly what I should expect, what indicates a problem etc. e.g what should i be on the lookout for to say Python doesn't build. I followed the step to upgrade my system, but it failed: :: Starting full system upgrade... :: Replace msys2-base with msys/filesystem? [Y/n] (55/55) checking for file conflicts[##] 100% error: failed to commit transaction (conflicting files) bash-completion: /etc/profile.d/bash_completion.sh exists in filesystem coreutils: /etc/DIR_COLORS exists in filesystem ca-certificates: /etc/pki/ca-trust/extracted/java/cacerts exists in filesystem ca-certificates: /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt exists in filesystem ca-certificates: /etc/pki/ca-trust/extracted/pem/email-ca-bundle.pem exists in filesystem ca-certificates: /etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem exists in filesystem ca-certificates: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem exists in filesystem filesystem: /etc/profile.d/lang.sh exists in filesystem filesystem: /etc/profile.d/tzset.sh exists in filesystem filesystem: /etc/skel/.inputrc exists in filesystem filesystem: /mingw32_shell.bat exists in filesystem filesystem: /mingw64_shell.bat exists in filesystem filesystem: /msys2_shell.bat exists in filesystem grep: /usr/bin/egrep exists in filesystem grep: /usr/bin/fgrep exists in filesystem rebase: /autorebase.bat exists in filesystem Errors occurred, no packages were upgraded. I just ignored that, and continued, and that seemed to go OK... /ghc-7.6.3/ didn't work, I needed to go /c/ghc/ghc-7.6.3/ for the paths. Perhaps make it clear which are absolute paths, and which you have to edit. Perhaps you were hoping I'd symlink the GHC path? Any reason for the && commands in the final list of commands? isn't one per line cleaner? It also lets you retry the right bit when something fails. checking for version of happy... 1.18.4 configure: error: Happy version 1.19.4 or later is required to compile GHC. Nice - this was a useful check that made it easy to fix and continue. $ make -j3 + test -f mk/config.mk.old + cp -p mk/config.mk mk/config.mk.old touch -r mk/config.mk.old mk/config.mk + test -f mk/project.mk.old + cp -p mk/project.mk mk/project.mk.old touch -r mk/project.mk.old mk/project.mk 2 [main] make 6024 child_info_fork::abort: C:\msys32\bin\msys-unistring-2.dll: Loaded to different address: parent(0x25) != child(0x7C) make: fork: Resource temporarily unavailable This error repeated. On a hunch I ran "autorebase.bat" from msys32, and restarted my shell, then it worked - I have no idea wh
RE: Windows breakage
Hmm. When I got this libraries\hpc\Trace\Hpc\Mix.hs:3:14: Warning: 'Trace.Hpc.Mix' is marked as Trustworthy but has been inferred as safe! I changed "Trustworthy" to "Safe". But then I got libraries\hpc\Trace\Hpc\Mix.hs:24:1: Data.Time: Can't be safely imported! The module itself isn't safe. This seems unhelpful. After all it's been "inferred as safe". What should I do? Thanks. Simon From: Simon Peyton Jones Sent: 14 November 2014 16:51 To: ghc-devs@haskell.org Subject: Windows breakage This breakage didn't use to happen. Might someone fix it? Thanks. For now I'm going through changing a dozen "Trustworthy" to "Safe". Is that right? Simon librariesWin32SystemWin32Console.hsc:2:14: Warning: 'System.Win32.Console' is marked as Trustworthy but has been inferred as safe! : Failing due to -Werror. libraries/Win32/ghc.mk:4: recipe for target 'libraries/Win32/dist-install/build/System/Win32/Console.o' failed ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage
Looks like fallout from a new -Wall warning: 475dd93efa5158a0f9516f6819a24edfc30c1a76, pushed on Wednesday. Perhaps in the mean time we should just take it out of minusWallOpts so it doesn't trip validate. I think I'll do this for the time being. On Fri, Nov 14, 2014 at 11:40 AM, Simon Peyton Jones wrote: > Hmm. When I got this > > libraries\hpc\Trace\Hpc\Mix.hs:3:14: Warning: > > ‘Trace.Hpc.Mix’ is marked as Trustworthy but has been inferred as safe! > > I changed “Trustworthy” to “Safe”. But then I got > > libraries\hpc\Trace\Hpc\Mix.hs:24:1: > > Data.Time: Can't be safely imported! The module itself isn't safe. > > This seems unhelpful. After all it’s been “inferred as safe”. What should I > do? > > Thanks. > > Simon > > From: Simon Peyton Jones > Sent: 14 November 2014 16:51 > To: ghc-devs@haskell.org > Subject: Windows breakage > > > > This breakage didn’t use to happen. Might someone fix it? Thanks. For > now I’m going through changing a dozen “Trustworthy” to “Safe”. Is that > right? > > Simon > > librariesWin32SystemWin32Console.hsc:2:14: Warning: > > ‘System.Win32.Console’ is marked as Trustworthy but has been inferred as > safe! > > > > : > > Failing due to -Werror. > > libraries/Win32/ghc.mk:4: recipe for target > 'libraries/Win32/dist-install/build/System/Win32/Console.o' failed > > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage
David recently added a new -Wall flag for Trustworthiness. The reasoning is if it is in -Wall, it can actually get seen and will be used by folks to improve more things from 'Trustworthy' to 'Safe'. After all, everything that is merely `Trustworthy` needs to live in the trusted computing base. The status quo is that you pretty much have no way to know what you _don't_ need Trustworthy on, and efforts in the past to take large libraries and convert them to SafeHaskell have been fraught with long rebuild cycles, because the only way to see was to build, haddock, and look. What you are running when you go to _fix_ the error appears to be an actual bug in the safety inference code, though, and definitely needs to be looked at. It probably does belong in -Wall in the long term, and -Werror is notoriously fickle, but we should look at what is causing it to go wrong here and do a bit more due diligence. -Edward On Fri, Nov 14, 2014 at 12:40 PM, Simon Peyton Jones wrote: > Hmm. When I got this > > libraries\hpc\Trace\Hpc\Mix.hs:3:14: Warning: > > ‘Trace.Hpc.Mix’ is marked as Trustworthy but has been inferred as safe! > > I changed “Trustworthy” to “Safe”. But then I got > > libraries\hpc\Trace\Hpc\Mix.hs:24:1: > > Data.Time: Can't be safely imported! The module itself isn't safe. > > This seems unhelpful. After all it’s been “inferred as safe”. What should > I do? > > Thanks. > > Simon > > *From:* Simon Peyton Jones > *Sent:* 14 November 2014 16:51 > *To:* ghc-devs@haskell.org > *Subject:* Windows breakage > > > > This breakage didn’t use to happen. Might someone fix it? Thanks. For > now I’m going through changing a dozen “Trustworthy” to “Safe”. Is that > right? > > Simon > > librariesWin32SystemWin32Console.hsc:2:14: Warning: > > ‘System.Win32.Console’ is marked as Trustworthy but has been inferred > as safe! > > > > : > > Failing due to -Werror. > > libraries/Win32/ghc.mk:4: recipe for target > 'libraries/Win32/dist-install/build/System/Win32/Console.o' failed > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage
I've reverted the change in the mean time: 452d6aa95b754a08e1e61800680ccbf6f968aef0 - this doesn't revert the actual code, just the addition of the new flag to -Wall. This way, at least ./validate isn't broken for Windows in the mean time. On Fri, Nov 14, 2014 at 11:56 AM, Edward Kmett wrote: > David recently added a new -Wall flag for Trustworthiness. > > The reasoning is if it is in -Wall, it can actually get seen and will be > used by folks to improve more things from 'Trustworthy' to 'Safe'. After > all, everything that is merely `Trustworthy` needs to live in the trusted > computing base. > > The status quo is that you pretty much have no way to know what you _don't_ > need Trustworthy on, and efforts in the past to take large libraries and > convert them to SafeHaskell have been fraught with long rebuild cycles, > because the only way to see was to build, haddock, and look. > > What you are running when you go to _fix_ the error appears to be an actual > bug in the safety inference code, though, and definitely needs to be looked > at. > > It probably does belong in -Wall in the long term, and -Werror is > notoriously fickle, but we should look at what is causing it to go wrong > here and do a bit more due diligence. > > -Edward > > > On Fri, Nov 14, 2014 at 12:40 PM, Simon Peyton Jones > wrote: >> >> Hmm. When I got this >> >> libraries\hpc\Trace\Hpc\Mix.hs:3:14: Warning: >> >> ‘Trace.Hpc.Mix’ is marked as Trustworthy but has been inferred as >> safe! >> >> I changed “Trustworthy” to “Safe”. But then I got >> >> libraries\hpc\Trace\Hpc\Mix.hs:24:1: >> >> Data.Time: Can't be safely imported! The module itself isn't safe. >> >> This seems unhelpful. After all it’s been “inferred as safe”. What should >> I do? >> >> Thanks. >> >> Simon >> >> From: Simon Peyton Jones >> Sent: 14 November 2014 16:51 >> To: ghc-devs@haskell.org >> Subject: Windows breakage >> >> >> >> This breakage didn’t use to happen. Might someone fix it? Thanks. For >> now I’m going through changing a dozen “Trustworthy” to “Safe”. Is that >> right? >> >> Simon >> >> librariesWin32SystemWin32Console.hsc:2:14: Warning: >> >> ‘System.Win32.Console’ is marked as Trustworthy but has been inferred >> as safe! >> >> >> >> : >> >> Failing due to -Werror. >> >> libraries/Win32/ghc.mk:4: recipe for target >> 'libraries/Win32/dist-install/build/System/Win32/Console.o' failed >> >> >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Windows breakage agein
On Windows (sigh). Seems to be due to Simon Marlow's 2a6f193b rts\Schedule.c: In function 'suspendThread': rts\Schedule.c:2239:3: error: expected ';' before 'EnterCriticalSection' rts/ghc.mk:236: recipe for target 'rts/dist/build/Schedule.thr_o' failed ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage
I'll spin up a windows VM to fix this. Although, do we have any better approaches these days? Are there Travis machines I can push to or anything that will validate on windows? Simon, I suspect there is a stage ordering issue here, that ghc-stage0 has a time library that isn't safe, but stage-1's time library is safe. That, or I've got a bug in safe-inferring. Cheers, David On 14 November 2014 09:59, Austin Seipp wrote: > I've reverted the change in the mean time: > 452d6aa95b754a08e1e61800680ccbf6f968aef0 - this doesn't revert the > actual code, just the addition of the new flag to -Wall. > > This way, at least ./validate isn't broken for Windows in the mean time. > > On Fri, Nov 14, 2014 at 11:56 AM, Edward Kmett wrote: >> David recently added a new -Wall flag for Trustworthiness. >> >> The reasoning is if it is in -Wall, it can actually get seen and will be >> used by folks to improve more things from 'Trustworthy' to 'Safe'. After >> all, everything that is merely `Trustworthy` needs to live in the trusted >> computing base. >> >> The status quo is that you pretty much have no way to know what you _don't_ >> need Trustworthy on, and efforts in the past to take large libraries and >> convert them to SafeHaskell have been fraught with long rebuild cycles, >> because the only way to see was to build, haddock, and look. >> >> What you are running when you go to _fix_ the error appears to be an actual >> bug in the safety inference code, though, and definitely needs to be looked >> at. >> >> It probably does belong in -Wall in the long term, and -Werror is >> notoriously fickle, but we should look at what is causing it to go wrong >> here and do a bit more due diligence. >> >> -Edward >> >> >> On Fri, Nov 14, 2014 at 12:40 PM, Simon Peyton Jones >> wrote: >>> >>> Hmm. When I got this >>> >>> libraries\hpc\Trace\Hpc\Mix.hs:3:14: Warning: >>> >>> ‘Trace.Hpc.Mix’ is marked as Trustworthy but has been inferred as >>> safe! >>> >>> I changed “Trustworthy” to “Safe”. But then I got >>> >>> libraries\hpc\Trace\Hpc\Mix.hs:24:1: >>> >>> Data.Time: Can't be safely imported! The module itself isn't safe. >>> >>> This seems unhelpful. After all it’s been “inferred as safe”. What should >>> I do? >>> >>> Thanks. >>> >>> Simon >>> >>> From: Simon Peyton Jones >>> Sent: 14 November 2014 16:51 >>> To: ghc-devs@haskell.org >>> Subject: Windows breakage >>> >>> >>> >>> This breakage didn’t use to happen. Might someone fix it? Thanks. For >>> now I’m going through changing a dozen “Trustworthy” to “Safe”. Is that >>> right? >>> >>> Simon >>> >>> librariesWin32SystemWin32Console.hsc:2:14: Warning: >>> >>> ‘System.Win32.Console’ is marked as Trustworthy but has been inferred >>> as safe! >>> >>> >>> >>> : >>> >>> Failing due to -Werror. >>> >>> libraries/Win32/ghc.mk:4: recipe for target >>> 'libraries/Win32/dist-install/build/System/Win32/Console.o' failed >>> >>> >>> ___ >>> ghc-devs mailing list >>> ghc-devs@haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >> >> >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Windows build gotchas
Hello all, I've been spending some of my winter break trying my hand at compiling GHC, with a mind to hopefully contributing down the line. I've got it working, but I ran into a few things along the way that I figure might be worth fixing and/or documenting. In the approximate order I encountered them: - The first pacman mirror on the list bundled with MSYS2 is down, with the result that every download pacman makes takes ~10sec longer than it should. It downloads a lot, so that really adds up - but it's easy to fix, just "pacman -Sy pacman-mirrors" before doing anything else with it. Is that worth mentioning on the wiki? I was thinking a line on https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows could be helpful. - That page mentions "If you see errors related to fork(), try closing and reopening the shell" - I've determined that you can reliably avoid that problem by following the instructions at http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/#iii-updating-packages, ie by running "pacman --needed -S bash pacman msys2-runtime", then closing & re-opening the MSYS shell, before you tell pacman to install the GHC prerequisite packages. - A minor point: I found it helpful to include "man-db" in the list of packages to install - without it, "git help" breaks down with " failed to exec 'man'". - I note "./sync-all --help" says, under "Flags", that "--windows also clones the ghc-tarballs repository (enabled by default on Windows)", and I've confirmed that default behaviour experimentally - but https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources tells you to manually clone ghc-tarballs when on Windows. Is that line on the wiki obsolete, or am I overlooking something? - And finally, the big one: cabal and/or ghc-pkg put some files outside the MSYS root directory, and caused me no end of trouble in doing so... I made a bit of a mess at one point, and tried to fix it by starting over completely from scratch. I expected uninstalling & reinstalling MSYS to achieve this (it deletes its root directory when you uninstall it), but that left me with a huge pile of errors when I tried to run "cabal install -j --prefix=/usr/local alex happy", of the form "Could not find module `...': There are files missing in the `...' package". I noticed that the cabal output made reference to "C:\Users\Martin\AppData\Roaming\cabal\", so tried moving that out of the way, but it only made the problem worse. I did figure it out eventually: in addition to that directory, "%APPDATA%\cabal", there were also files left over in "%APPDATA%\ghc". Once I removed that directory as well, things started working again - but it took me a lot of time & frustration to get there. I'm not entirely sure, but I think the copy of Cabal I already had from installing the Platform may also have been storing files in those directories, in which case this process completely mangled them - which isn't great. It seems to me that, ideally, the "build GHC inside MSYS" procedure would keep itself entirely inside the MSYS directory structure: if it were wholly self-contained, you'd know where everything is, and it couldn't break anything outside. As far as I can tell, the only breach is those two directories courtesy of Cabal, so I didn't think it would be too difficult - but none of the things I've tried (the --package-db cabal flag, a custom cabal --config-file, setting the GHC_PACKAGE_PATH environment variable, maybe some others I've forgotten) had the desired effect. Is it possible? Is it even a good idea? If that's just how it has to be, I feel like there should be an obvious note somewhere for the sake of the next person to trip over it. I'd be happy to amend the wiki for any/all of the first four points, if people think it'd be appropriate; I'm not sure at all what to do about the last one. Any thoughts? - Martin ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Windows build broken
AAARGH! Windows build is broken again. Please can someone fix? In file included from rts\RtsMain.c:12:0: rts\PosixSource.h:31:0: error: "__USE_MINGW_ANSI_STDIO" redefined c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/_mingw.h:280:0: note: this is the location of the previous definition rts/ghc.mk:243: recipe for target 'rts/dist/build/RtsMain.o' failed make[1]: *** [rts/dist/build/RtsMain.o] Error 1 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Windows broken -- again
I get this breakage on Windows. I have no idea who is responsible. Can someone fix? It looks as if throwIOIO really is always unused. Simon utils\ghc-pkg\Main.hs:1982:1: Warning: Defined but not used: 'throwIOIO' ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Building on Windows
I'm trying to test a patch I wrote for Windows builds[1]. I'm following the preparation guide[2], but my configure step fails[3] with config.log contents[4]. Note that I'm building on the ghc-7.10 branch, not master. Is it possible that this would contribute to the unrecognized --enable-tarballs-autodownload option, and/or the inability to compile C files? [1] https://phabricator.haskell.org/D1158, handles long linker command line arguments [2] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows [3] http://lpaste.net/139330 [4] http://lpaste.net/139331 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Sphinx on Windows
The GHC wiki says you need Sphinx to build docs, https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Tools and refers to the Preparation doc for how to install Sphinx https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation But the Windows sub-page of Preparation does not say how to install Sphinx. Question: how does one install Sphinx on Windows? The sphinx-doc home page mutters about 'pip', but I've never used that. Does anyone have instructions? Thanks Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Haskeline on Windows
To get ‘haskeline’ to compile on Windows I have to apply the patch below.
Otherwise this alignment thing is defined twice and the build fails
Could someone fix it properly? Thanks!
Simon
modified System/Console/Haskeline/Backend/Win32.hsc
@@ -167,7 +167,7 @@ getKeyEvent p = do
data Coord = Coord {coordX, coordY :: Int}
deriving Show
-#let alignment t = "%lu", (unsigned long)offsetof(struct {char x__; t (y__);
}, y__)
+-- #let alignment t = "%lu", (unsigned long)offsetof(struct {char x__; t
(y__); }, y__)
instance Storable Coord where
sizeOf _ = (#size COORD)
alignment _ = (#alignment COORD)
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Windows failures
Yes, the test simply doesn't run at all on Windows. I've committed the patch
for you. Thanks!
Simon
From: Andreas Voellmy [mailto:andreas.voel...@gmail.com]
Sent: 15 May 2013 14:07
To: Simon Peyton-Jones
Subject: Re: Windows failures
Hi Simon,
I added 7773 recently. I should have noticed that it wouldn't work on Windows.
I don't have a Windows machine, so can you try this fix for me?
In libraries/base/tests/all.T, change the line for T7773 (line 125 for me) to
this:
test('T7773', when(opsys('mingw32'), skip), compile_and_run, [''])
Does that eliminate the 7773 failure for you. If so, I'll commit the patch. I
just want to double-check, because I am just getting my feet wet with the test
system.
-Andi
On Wed, May 15, 2013 at 7:21 AM, Simon Peyton-Jones
mailto:simo...@microsoft.com>> wrote:
On Windows I'm getting these failures. Details below.
Simon
Unexpected failures:
../../libraries/base/testsT7773 [exit code non-0] (normal)
../../libraries/random/tests rangeTest [bad exit code] (normal)
cabal/cabal01 cabal01 [bad stdout] (normal)
ghc-api/T7478 T7478 [bad exit code] (normal)
ghci.debugger/scripts dynbrk009 [bad exit code] (ghci)
ghci/scripts T5975a [bad stderr] (ghci)
rts T4850 [bad stdout] (normal)
=> T7773(normal) 3517 of 3614 [2, 18, 0]
cd ../../libraries/base/tests && 'C:/code/HEAD/inplace/bin/ghc-stage2.exe'
-fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db
-rtsopts -fno-ghci-history -o T7773 T7773.hs>T7773.comp.stderr 2>&1
Compile failed (status 256) errors were:
T7773.hs:2:8:
Could not find moduleSystem.Posix.IO<http://System.Posix.IO>
Use -v to see a list of the files searched for.
*** unexpected failure for T7773(normal)
=> rangeTest(normal) 3386 of 3589 [2, 25, 0]
cd ../../libraries/random/tests && 'C:/code/HEAD/inplace/bin/ghc-stage2.exe'
-fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db
-rtsopts -fno-ghci-history -o rangeTest rangeTest.hs>rangeTest.comp.stderr
2>&1
cd ../../libraries/random/tests && ./rangeTestrangeTest.run.stdout 2>rangeTest.run.stderr
Wrong exit code (expected 0 , actual 1 )
Stdout:
Int: Passed
Integer: Passed
Int8: Passed
Int16: Passed
Int32: Passed
Int64: Passed
Word: Passed
Word8: Passed
Word16: Passed
Word32: Passed
Word64: Passed
Double: Passed
Float: Passed
CChar: Passed
CSChar: Passed
CUChar: Passed
CShort: Passed
CUShort: Passed
CInt: Passed
CUInt: Passed
CLong: Passed
CULong: Passed
CPtrdiff: Passed
CSize: Passed
CWchar: Passed
CSigAtomic: Passed
CLLong: Passed
CULLong: Passed
CIntPtr: Passed
CUIntPtr: Passed
CIntMax: Passed
CUIntMax: Passed
Int R: Passed
Integer R: Passed
Int8 R: Passed
Int8 Rsmall: Passed
Int8 Rmini: Passed
Int8 Rtrivial: Passed
Int16 R: Passed
Int32 R: Passed
Int64 R: Passed
Word R: Passed
Word8 R: Passed
Word16 R: Passed
Word32 R: Passed
Word64 R: Passed
Double R: Passed
Float R: Passed
CChar R: Passed
CSChar R: Passed
CUChar R: Passed
CShort R: Passed
CUShort R: Passed
CInt R: Passed
CUInt R: Passed
CLong R: Passed
CULong R: Passed
CPtrdiff R: Passed
CSize R: Passed
CWchar R:
Stderr:
rangeTest.exe: broke lower bound: 100
=> cabal01(normal) 81 of 3614 [0, 0, 0]
cd ./cabal/cabal01 && $MAKE -s --no-print-directory cabal01
VANILLA=--enable-library-vanilla PROF=--disable-library-profiling
DYN=--disable-shared CLEANUP=1cabal01.run.stdout
2>cabal01.run.stderr
Actual stdout output differs from expected:
--- ./cabal/cabal01/cabal01.stdout-mingw32 2012-06-22 00:08:51 +0100
+++ ./cabal/cabal01/cabal01.run.stdout 2013-05-15 07:18:31 +0100
@@ -1,9 +1,9 @@
install1:
bin
-test-1.0
+i386-windows-ghc-7.7.20130514
install2:
bin
-test-1.0
+i386-windows-ghc-7.7.20130514
dist:
build
package.conf.inplace
*** unexpected failure for cabal01(normal)
=> T7478(normal) 6 of 6 [0, 0, 0]
cd ./T7478 && $MAKE -s --no-print-directory T7478T7478.run.stdout 2>T7478.run.stderr
Wrong exit code (expected 0 , actual 2 )
Stdout:
- 0 --
(0,"[1 of 2] Compiling B( B.hs, B.o )")
(0,"[2 of 2] Compiling Main ( A.hs, A.o )")
- 1 --
(1,"[2 of 2] Compiling Main ( A.hs, A.o )")
- 2 --
(2,"[1 of 1] Compiling Main ( C.hs, C.o )")
(2,"Linking A.exe ...")
Stderr:
T7478.exe: T7478.exe: phase `Linker' failed (exitcode = 1)
make[1]: *** [T7478] Error 1
*** unexpected failure for T7478(normal)
=> dynbrk009(ghci) 67 of 76 [0, 0, 0]
cd ./scripts && HC='C:/code/HEAD/inplace/bin/ghc-stage2.exe'
HC_OPTS='-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsop
Windows validate failing
My Windows build has started failing like this when I try "sh validate" Any ideas? Simon /usr/bin/install -c -m 755 -d "c:/code/HEAD/bindistprep/ghc-7.7.20130516/doc/html/libraries" for i in libraries/dist-haddock/*; do \ /usr/bin/install -c -m 644 $i "c:/code/HEAD/bindistprep/ghc-7.7.20130516/doc/html/libraries/"; \ done /usr/bin/install -c -m 644 libraries/prologue.txt "c:/code/HEAD/bindistprep/ghc-7.7.20130516/doc/html/libraries/" /usr/bin/install -c -m 755 libraries/gen_contents_index "c:/code/HEAD/bindistprep/ghc-7.7.20130516/doc/html/libraries/" cd bindistprep && "/usr/bin/tar" cf - ghc-7.7.20130516 | bzip2 -c > ../bindistprep/ghc-7.7.20130516-i386-unknown-mingw32.tar.bz2 make -r --no-print-directory -f ghc.mk windows-installer make[1]: *** No rule to make target `windows-installer'. Stop. make: *** [binary-dist-prep] Error 2 bash-3.1$ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Windows validate fails
Windows validation is failing (again). Error is below. This is a clean build. Ian? This is the same problem I had before on Linux, but this time my libraries are up to date. Did you validate on windows? Iconv may be different on windows. Urk Simon "inplace/bin/ghc-stage1.exe" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0-package-name base-4.7.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -package integer-gmp-0.5.1.0 -package rts-1.0 -package-name base -XHaskell98 -XCPP -O2 -O -dcore-lint -fno-warn-deprecated-flags -no-user-package-db -rtsopts -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -c libraries/base/./GHC/IO/Encoding/Iconv.hs -o libraries/base/dist-install/build/GHC/IO/Encoding/Iconv.o Top level: Failed to load interface for `GHC.Integer.Type' There are files missing in the `integer-gmp' package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. make[1]: *** [libraries/base/dist-install/build/GHC/IO/Encoding/Iconv.o] Error 1 make[1]: *** Waiting for unfinished jobs make: *** [all] Error 2 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows failures
On Mon, Jun 17, 2013 at 08:48:15PM +, Simon Peyton-Jones wrote: > This is 'sh validate" on 64bit Windows. Rather a lot of failures. Might you > look? Sure. > The perf tests seem to fail because it's comparing with the *32* bit numbers, > even though this is definitely a *64* bit laptop. Whether the entire build > system thinks it's a 32 bit machine, or just the testsuite, I can't tell. If you have a 64bit Windows machine, then you'll be able to run both the 32bit and 64bit GHC builds. If you run "ghc --info | grep Target" then you'll see which is being used - it'll say x86_64-unknown-mingw32 if it's 64bit, and i386-unknown-mingw32 if it's 32bit. I suspect that you have a 32bit GHC, so comparing with the 32bit numbers is right. They probably just need updating for recent wobbles. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Windows failures
Curiously you are right. Target is
,("Target platform","i386-unknown-mingw32")
Weird since it's a 64-bit machine.
Simon
-Original Message-
From: Ian Lynagh [mailto:i...@well-typed.com]
Sent: 18 June 2013 23:06
To: Simon Peyton-Jones
Cc: ghc-devs@haskell.org
Subject: Re: Windows failures
On Mon, Jun 17, 2013 at 08:48:15PM +, Simon Peyton-Jones wrote:
> This is 'sh validate" on 64bit Windows. Rather a lot of failures. Might you
> look?
Sure.
> The perf tests seem to fail because it's comparing with the *32* bit numbers,
> even though this is definitely a *64* bit laptop. Whether the entire build
> system thinks it's a 32 bit machine, or just the testsuite, I can't tell.
If you have a 64bit Windows machine, then you'll be able to run both the 32bit
and 64bit GHC builds. If you run "ghc --info | grep Target" then you'll see
which is being used - it'll say x86_64-unknown-mingw32 if it's 64bit, and
i386-unknown-mingw32 if it's 32bit. I suspect that you have a 32bit GHC, so
comparing with the 32bit numbers is right. They probably just need updating for
recent wobbles.
Thanks
Ian
--
Ian Lynagh, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Building on windows
I've got a new Windows laptop, and have being having a torrid time getting GHC to build on it. 1. Build falls over with checking for gcc... c:/code/HEAD/inplace/mingw/bin/gcc.exe checking whether the C compiler works... no configure: error: in `/c/code/HEAD': configure: error: C compiler cannot create executables Turns out that an earlier error was configure: Making in-tree mingw tree tar (child): ../../ghc-tarballs/mingw/binutils*.tar.lzma: Cannot open: No such file or directory tar (child): Error is not recoverable: exiting now tar: Child returned status 2 tar: Error is not recoverable: exiting now ./configure: line 4050: inplace/mingw/bin/realgcc.exe: No such file or directory configure: In-tree mingw tree created configure: Making in-tree perl tree BUT this error was not fatal, so the build went on (notwithstanding the red message above), leading to a MUCH more obscure error later. 2. Why wasn't ghc-tarballs there? Oh, apparently you have to say sync-all -windows get That's really hard for a naïve user to work out. Can't we either always get it, or work out that we are on windows? 3. I carefully installed mingw/msys as described on http://www.mingw.org/wiki/Getting_Started I used mingw-set-inst, which launches a GUI for a package installer. All seems well. I update my path. But then Can't locate Autom4te/ChannelDefs.pm in @INC (@INC contains: /mingw/share/autoco nf /usr/lib/perl5/5.8/msys /usr/lib/perl5/5.8 /usr/lib/perl5/site_perl/5.8/msys /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/vendor_ perl/5.8/msys /usr/lib/perl5/vendor_perl/5.8 /usr/lib/perl5/vendor_perl/5.8 .) a t /c/Programme/MinGW/bin/autoreconf-2.68 line 40. BEGIN failed--compilation aborted at /c/Programme/MinGW/bin/autoreconf-2.68 line 40. After a long struggle I found that I had missed a crucial thing. With the new autoconf tools, it's essential that c:/mingw be mounted as /mingw, because /mingw is hard-coded into autoconf perl scripts. http://www.mingw.org/wiki/Getting_Started does say (deep in the middle) to edit c:/mingw/msys/1.0/etc/fstab with a text editor, but that appeared to have no effect for me. Saying "mount c:/mingw /mingw" did work. I have no idea why. What is horrible is how uninformative the error message is. I guess we should update the Windows build instructions. I still don't know if I've bottomed out here because I can't find Happy/Alex in the Haskell platform. Sigh. Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
More windows woe
OK, so now my windows build is getting further, but it now falls over here. This one looks more straightforward! Can anyone help? Simon "inplace/bin/ghc-stage1.exe" -optc-Werror -optc-Wall -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-O2 -optc-fomit-frame-pointer -optc-fno-omit-frame-pointer -optc-g -optc-O0 -optc-DRtsWay=\"rts_debug\" -static -optc-DDEBUG -ticky -DTICKY_TICKY -H32m -O -Werror -Wall -H64m -O0 -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -O0-c rts/CheckUnload.c -o rts/dist/build/CheckUnload.debug_o cc1.exe: warnings being treated as errors rts\CheckUnload.c: In function 'checkUnload': rts\CheckUnload.c:257:7: error: format '%s' expects type 'char *', but argument 2 has type 'pathchar *' rts\CheckUnload.c:293:11: error: format '%s' expects type 'char *', but argument 2 has type 'pathchar *' rts\CheckUnload.c:297:11: error: format '%s' expects type 'char *', but argument 2 has type 'pathchar *' bash-3.1$ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Windows validate failure
My latest Windows validate fell over as below, with some kind of Python failure (ie not just a failing test). It worked fine couple of days ago. Does anyone have any ideas of what might be going on? Simon => process007(normal) 3739 of 3756 [2, 24, 0] cd ../../libraries/process/tests && $MAKE -s --no-print-directory process007_fd process007_fd.c: In function 'main': process007_fd.c:33:46: error: 'EWOULDBLOCK' undeclared (first use in this function) process007_fd.c:33:46: note: each undeclared identifier is reported only once for each function it appears in make[3]: *** [process007_fd] Error 1 Traceback (most recent call last): File "../driver/runtests.py", line 279, in oneTest() File "c:\code\HEAD\testsuite\driver\testlib.py", line 549, in thisTest = lambda : runTest(myTestOpts, name, func, args) File "c:\code\HEAD\testsuite\driver\testlib.py", line 528, in runTest test_common_work (name, opts, func, args) File "c:\code\HEAD\testsuite\driver\testlib.py", line 686, in test_common_work framework_fail(name, 'runTest', 'Unhandled exception: ' + str(e)) File "c:\code\HEAD\testsuite\driver\testlib.py", line 824, in framework_fail if_verbose(1, '*** framework failure for %s %s ' %s (full_name, reason)) NameError: global name 's' is not defined make[2]: *** [test] Error 1 make[2]: Leaving directory `/c/code/HEAD/testsuite/tests' make[1]: *** [fast] Error 2 make[1]: Leaving directory `/c/code/HEAD/testsuite/tests' make: *** [test] Error 2 == Start post-testsuite package check Timestamp 2013-09-22 02:30:10 UTC for c:/code/HEAD/inplace\lib\package.conf.d\package.cache Timestamp 2013-09-22 02:30:10 UTC for c:/code/HEAD/inplace\lib\package.conf.d (same as cache) using cache: c:/code/HEAD/inplace\lib\package.conf.d\package.cache == End post-testsuite package check --- Oops! Looks like you have some unexpected test results or framework failures. Please fix them before pushing/sending patches. --- ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
gcc on Windows
Dear ghc devs My Windows build failed as below, because it couldn't find gcc. But this is the ONLY reason we need gcc! GHC and its libraries all built without gcc, perhaps because we use ghc itself to compile C files, and ghc has a C compiler in its belly (no PATH reqd). Question: would it be possible to use the same technique to compile timeout, so that we don't need to install gcc separately? This is on Windows. Thanks Simon Building timeout-1... Preprocessing executable 'timeout' for timeout-1... Setup.exe: The program gcc is required but it could not be found. Makefile:39: recipe for target 'install-inplace/bin/timeout' failed make[3]: *** [install-inplace/bin/timeout] Error 1 make[3]: Leaving directory '/cygdrive/c/code/HEAD/testsuite/timeout' ../mk/test.mk:234: recipe for target '../timeout/install-inplace/bin/timeout.exe' failed make[2]: *** [../timeout/install-inplace/bin/timeout.exe] Error 2 make[2]: Leaving directory '/cygdrive/c/code/HEAD/testsuite/tests' ../mk/test.mk:253: recipe for target 'fast' failed make[1]: *** [fast] Error 2 make[1]: Leaving directory '/cygdrive/c/code/HEAD/testsuite/tests' Makefile:112: recipe for target 'test' failed make: *** [test] Error 2 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
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
import ctypes
File "/usr/lib/python2.7/ctypes/__init__.py", line 451, in
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
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
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@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Windows build
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
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-boun...@haskell.org] On Behalf Of kyra
Sent: 12 November 2013 06:45
To: ghc-devs@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
import ctypes
File "/usr/lib/python2.7/ctypes/__init__.py", line 451, in
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
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
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@haskell.org<mailto:ghc-devs@haskell.org>
http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows build
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
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-boun...@haskell.org] *On Behalf Of *kyra
*Sent:* 12 November 2013 06:45
*To:* ghc-devs@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
import ctypes
File "/usr/lib/python2.7/ctypes/__init__.py", line 451, in
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
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
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@haskell.org <mailto:ghc-devs@haskell.org>
http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Windows build
Great...that works.
I also had to edit mk/boilerplate.mk to comment out these lines
# ifeq "$(shell $(SHELL) -c 'python2 -c 0' 2> /dev/null && echo exists)"
"exists"
# PYTHON = python2
# endif
Because msys2 has python2.exe as well as python.exe. (Or I could have moved
that out of the way too.)
Thanks
Austin please note for the msys2 instructions you are writing
Simon
From: kyra [mailto:ky...@mail.ru]
Sent: 12 November 2013 09:53
To: Simon Peyton-Jones
Subject: Re: Windows build
http://www.python.org/download/
This is what is recommended at
https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows
I think you already has it installed, because this is required for msys build.
Hence all you should do is:
1. make your edit (MINGW32 -> MINGW)
2. disable msys2 python
On 11/12/2013 13:44, Simon Peyton-Jones wrote:
OK... where did you get native python from?
From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of kyra
Sent: 12 November 2013 09:39
To: ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>
Subject: Re: Windows build
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
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-boun...@haskell.org] On Behalf Of kyra
Sent: 12 November 2013 06:45
To: ghc-devs@haskell.org<mailto:ghc-devs@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
import ctypes
File "/usr/lib/python2.7/ctypes/__init__.py", line 451, in
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
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 rece
Windows build broken
Can someone fix this? This is breakage on Windows. It was fine yesterday. Simon cc1.exe: warnings being treated as errors rts\Linker.c: In function 'loadArchive': rts\Linker.c:2631:17: error: passing argument 1 of 'strlen' from incompatible pointer type c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/string.h:49:40: note: expected 'const char *' but argument is of type 'pathchar *' rts\Linker.c:2632:17: error: passing argument 2 of 'strcpy' from incompatible pointer type c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/string.h:45:39: note: expected 'const char *' but argument is of type 'pathchar *' rts\Linker.c:2638:21: error: passing argument 1 of 'strlen' from incompatible pointer type c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/string.h:49:40: note: expected 'const char *' but argument is of type 'pathchar *' rts\Linker.c:2643:17: error: passing argument 1 of '_wfopen' from incompatible pointer type c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/stdio.h:593:39: note: expected 'const wchar_t *' but argument is of type 'char *' rts/ghc.mk:233: recipe for target 'rts/dist/build/Linker.o' failed make[1]: *** [rts/dist/build/Linker.o] Error 1 make[1]: *** Waiting for unfinished jobs Makefile:64: recipe for target 'all' failed make: *** [all] Error 2 HEAD (master)$ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Windows breakage -- again
Aargh! The Windows build has broken - again. I can't build GHC on my laptop any more. A clean 'sh validate' finishes as below. What on earth is `___sync_fetch_and_add_1'? Can anyone help? Thanks! Simon "inplace/bin/ghc-stage2.exe" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0-package-name vector-0.10.9.1 -hide-all-packages -i -ilibraries/vector/. -ilibraries/vector/dist-install/build -ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/dist-install/build -Ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/include -Ilibraries/vector/internal -optP-DVECTOR_BOUNDS_CHECKS -optP-include -optPlibraries/vector/dist-install/build/autogen/cabal_macros.h -package base-4.7.1.0 -package deepseq-1.3.0.2 -package ghc-prim-0.3.1.0 -package primitive-0.5.2.1 -O2 -XHaskell98 -XCPP -XDeriveDataTypeable -O2 -O -dcore-lint -fno-warn-deprecated-flags -no-user-package-db -rtsopts -Wwarn -odir libraries/vector/dist-install/build -hidir libraries/vector/dist-install/build -stubdir libraries/vector/dist-install/build -c libraries/vector/./Data/Vector/Fusion/Stream/Monadic.hs -o libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o Loading package ghc-prim ... linking ... ghc-stage2.exe: unable to load package `ghc-prim' ghc-stage2.exe: C:\code\HEAD\libraries\ghc-prim\dist-install\build\HSghc-prim-0.3.1.0.o: unknown symbol `___sync_fetch_and_add_1' libraries/vector/ghc.mk:5: recipe for target 'libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o' failed make[1]: *** [libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o] Error 1 I ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows failures
Hi Simon, That's still a lot more than I expect. Is this just with a validate run and not re-running the failed tests? My guess is re-running that list of failing tests should significantly reduce the amount. There does seem to be an issue with threading lately, but I am not sure where it lies. I hope to get a few of my outstanding patches upstream in the next two weeks and will take a look at the failures a bit more in depth after that. I am also not quite sure why the plugin-recomp tests seem to consistently fail for you, I can't seem to reproduce it and don't see it on harbormaster either. When it fails does it give any output? Kind regards, Tamar On Wed, Dec 12, 2018 at 2:09 PM Simon Peyton Jones wrote: > Tamar > > Things are getting better. Here’s my list of testsuite failure on > Windows, based on last night’s HEAD. Still 16 failures. > > Simon > > Unexpected failures: > >plugins/plugin-recomp-change.runplugin-recomp-change [bad exit > code] (normal) > >rts/T10672/T10672_x64.run T10672_x64 [bad exit code] (normal) > >simplCore/should_compile/T7702.run T7702 [exit code non-0] (normal) > >th/T10596.run T10596 [exit code non-0] (normal) > >th/TH_spliceE1.run TH_spliceE1 [exit code non-0] > (ext-interp) > >th/TH_PromotedList.run TH_PromotedList [exit code non-0] > (ext-interp) > >libraries/Win32/tests/T4452.run T4452 [bad exit code] (normal) > >plugins/plugins07.run plugins07 [bad exit code] (normal) > >plugins/plugins09.run plugins09 [bad exit code] (normal) > >plugins/plugins10.run plugins10 [bad stdout] (normal) > >plugins/plugins11.run plugins11 [bad stdout] (normal) > >plugins/T10420.run T10420 [bad exit code] (normal) > >plugins/T10294a.run T10294a [bad exit code] (normal) > >plugins/plugin-recomp-pure.run plugin-recomp-pure [bad exit code] > (normal) > >plugins/plugin-recomp-impure.runplugin-recomp-impure [bad exit > code] (normal) > >plugins/plugin-recomp-flags.run plugin-recomp-flags [bad exit code] > (normal) > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Windows release quality
Hello Devs, After running into #16408 today I realized there is as of yet no released bindist of the 8.6 series which I would consider stable for windows. GHC 8.6.1 and 8.6.2 had a series of critical bugs which applied to multiple platforms: https://gitlab.haskell.org/ghc/ghc/issues/16408 GHC 8.6.3 loops forever if compiling certain code using TH on windows. This affects some very popular hackage packages: (#16057) <https://gitlab.haskell.org/ghc/ghc/issues/16057> GHC 8.6.4 (marked stable) currently ships without profiling libraries, making profiling impossible. Being stuck with 8.4 is one thing, and if properly communicated not too bad. But it requires work to even find out about these (major) issues and to discover that 8.6 is NOT production ready for windows. We offered the broken 8.6.3 as stable for weeks without any indication that it was broken. We still serve GHC 8.6.4 as stable without any hint about the missing profiling libraries. I can't offer solutions in this case but I feel like something about the release management has to change if . Having to check the GHC bugtracker to find out if the current stable release is actually stable is just not sustainable. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Windows testsuite failures
Hi all, Currently Windows CI is a bit flaky due to some unfortunately rather elusive testsuite driver bugs. Progress in resolving this has been a bit slow due to travel over the last week but I will be back home tomorrow and should be able to resolve the issue soon thereafter. Cheers, - Ben ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Windows build broken
Hi devs, it seems the windows build is broken. (Can't build stage2 locally). Quickest way to reproduce is a validate of master. It also happens on CI: https://gitlab.haskell.org/ghc/ghc/-/jobs/270248 I remember ben mentioning something along the lines of builds with "old" (8.6) boot compilers being broken. Is that the culprint? How do I get back to a functioning environment? Cheers, Andreas ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Windows CI instability
Hi all, Currently the windows CI issue is experiencing high amounts of instability so if your patch fails for this reason then don't worry. We are attempting to fix it. Cheers, Matt ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Windows link failure
OK Windows is back. But all these fail with this error Stderr: /bin/sh: cc: command not found make[3]: *** [t_11223_simple_unused_duplicate_lib] Error 127 Simon rts/T11223 T11223_link_order_a_b_2_fail [bad exit code] (normal) rts/T11223 T11223_link_order_a_b_succeed [bad exit code] (normal) rts/T11223 T11223_link_order_b_a_2_succeed [bad exit code] (normal) rts/T11223 T11223_link_order_b_a_succeed [bad exit code] (normal) rts/T11223 T11223_simple_duplicate_lib [bad exit code] (normal) rts/T11223 T11223_simple_link [bad exit code] (normal) rts/T11223 T11223_simple_link_lib [bad exit code] (normal) rts/T11223 T11223_simple_unused_duplicate_lib [bad exit code] (normal) ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Windows build
Hi Simon, For these tests it shouldn’t matter much so I guess I can change them. The Windows Build guide does ask to put /mingw64/bin/ on your path. The reason I tend not to want to use GHC to compile my c files for the tests is that GHC doesn’t just pass the commands along to gcc. It adds to them. While for these single object files it doesn’t matter (as it just adds a few defines and include paths) It has bitten me multiple times in the past. Particularly when compiling shared libraries for tests since GHC wants to link in the RTS, which makes the files considerably larger and harder to debug so I tend to avoid using GHC to compile just pure C code. It means (with shared libraries) that I’ll end up with multiple RTSs loaded (at least in memory, which means stepping in gdb I have to keep track of the memory locations so I know which one I’m in). So I really wish there was a way to tell GHC not to do this. Also you’ll likely be linking against libraries compiled against other versions of GCC or MSVC so that shouldn’t be an issue. I’ll change the tests tomorrow, but I would much prefer if the testsuite can tell me where the GCC to use is, so I don’t have to use GHC. Regards, Tamar From: Simon Peyton Jones via ghc-devs Sent: Friday, July 8, 2016 22:27 To: ghc-devs@haskell.org Subject: Windows build I’ve completed a successful build on my Surface Book! Thank you. One last glitch. I’m getting the validate failure bellow. No other test requires gcc in my path. GHC itself carefully navigates to its own private gcc. Do we really want this family of tests (half a dozen variants of T11223) to rely on some random gcc, which might or might not be the same as GHC is using? Shouldn’t we use ‘ghc foo.c’? Simon => T11223_simple_unused_duplicate_lib(normal) 3371 of 5211 [0, 6, 1] cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-hFCtmi/test spaces/./rts/T11223/T11223_simple_unused_duplicate_lib.run" && $MAKE -s --no-print-directory t_11223_simple_unused_duplicate_lib Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: /bin/sh: gcc: command not found make[2]: *** [Makefile:42: t_11223_simple_unused_duplicate_lib] Error 127 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Windows build
Hi Simon, Thomie changed it so the in place gcc can be called from the testsuite. The tests should pass now. Kind regards, Tamar Sent from my Mobile On Jul 8, 2016 23:02, wrote: > Hi Simon, > > > > For these tests it shouldn’t matter much so I guess I can change them. > > > > The Windows Build guide does ask to put /mingw64/bin/ on your path. > > The reason I tend not to want to use GHC to compile my c files for the > tests is that GHC doesn’t just pass the commands along to gcc. > > It adds to them. While for these single object files it doesn’t matter (as > it just adds a few defines and include paths) It has bitten me multiple > times in the past. Particularly when compiling shared libraries for tests > since GHC wants to link in the RTS, which makes the files considerably > larger and harder to debug so > > I tend to avoid using GHC to compile just pure C code. > > > > It means (with shared libraries) that I’ll end up with multiple RTSs > loaded (at least in memory, which means stepping in gdb I have to keep > track of the memory locations so I know which one I’m in). So I really wish > there was a way to tell GHC not to do this. > > > > Also you’ll likely be linking against libraries compiled against other > versions of GCC or MSVC so that shouldn’t be an issue. > > > > I’ll change the tests tomorrow, but I would much prefer if the testsuite > can tell me where the GCC to use is, so I don’t have to use GHC. > > > > Regards, > > Tamar > > > > *From: *Simon Peyton Jones via ghc-devs > *Sent: *Friday, July 8, 2016 22:27 > *To: *ghc-devs@haskell.org > *Subject: *Windows build > > > > I’ve completed a successful build on my Surface Book! Thank you. > > > > One last glitch. I’m getting the validate failure bellow. > > > > No other test requires gcc in my path. GHC itself carefully navigates to > its own private gcc. Do we really want this family of tests (half a dozen > variants of T11223) to rely on some random gcc, which might or might not be > the same as GHC is using? Shouldn’t we use ‘ghc foo.c’? > > > > Simon > > > > => T11223_simple_unused_duplicate_lib(normal) 3371 of 5211 [0, 6, 1] > > cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-hFCtmi/test > spaces/./rts/T11223/T11223_simple_unused_duplicate_lib.run" && $MAKE -s > --no-print-directory t_11223_simple_unused_duplicate_lib > > Wrong exit code (expected 0 , actual 2 ) > > Stdout: > > > > Stderr: > > /bin/sh: gcc: command not found > > make[2]: *** [Makefile:42: t_11223_simple_unused_duplicate_lib] Error 127 > > > > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Windows build
Indeed – it works great now. Thank you! I have a working Windows build on my Surface Book. Hooray. Many thanks to everyone who helped. Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Phyx Sent: 09 July 2016 18:00 To: Simon Peyton Jones via ghc-devs Subject: RE: Windows build Hi Simon, Thomie changed it so the in place gcc can be called from the testsuite. The tests should pass now. Kind regards, Tamar Sent from my Mobile On Jul 8, 2016 23:02, mailto:loneti...@gmail.com>> wrote: Hi Simon, For these tests it shouldn’t matter much so I guess I can change them. The Windows Build guide does ask to put /mingw64/bin/ on your path. The reason I tend not to want to use GHC to compile my c files for the tests is that GHC doesn’t just pass the commands along to gcc. It adds to them. While for these single object files it doesn’t matter (as it just adds a few defines and include paths) It has bitten me multiple times in the past. Particularly when compiling shared libraries for tests since GHC wants to link in the RTS, which makes the files considerably larger and harder to debug so I tend to avoid using GHC to compile just pure C code. It means (with shared libraries) that I’ll end up with multiple RTSs loaded (at least in memory, which means stepping in gdb I have to keep track of the memory locations so I know which one I’m in). So I really wish there was a way to tell GHC not to do this. Also you’ll likely be linking against libraries compiled against other versions of GCC or MSVC so that shouldn’t be an issue. I’ll change the tests tomorrow, but I would much prefer if the testsuite can tell me where the GCC to use is, so I don’t have to use GHC. Regards, Tamar From: Simon Peyton Jones via ghc-devs<mailto:ghc-devs@haskell.org> Sent: Friday, July 8, 2016 22:27 To: ghc-devs@haskell.org<mailto:ghc-devs@haskell.org> Subject: Windows build I’ve completed a successful build on my Surface Book! Thank you. One last glitch. I’m getting the validate failure bellow. No other test requires gcc in my path. GHC itself carefully navigates to its own private gcc. Do we really want this family of tests (half a dozen variants of T11223) to rely on some random gcc, which might or might not be the same as GHC is using? Shouldn’t we use ‘ghc foo.c’? Simon => T11223_simple_unused_duplicate_lib(normal) 3371 of 5211 [0, 6, 1] cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-hFCtmi/test spaces/./rts/T11223/T11223_simple_unused_duplicate_lib.run" && $MAKE -s --no-print-directory t_11223_simple_unused_duplicate_lib Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: /bin/sh: gcc: command not found make[2]: *** [Makefile:42: t_11223_simple_unused_duplicate_lib] Error 127 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Windows build
Hi Simon, What does which python 2 and which python 3 return? Along with uname -a? Tamar On Tue, Oct 18, 2016, 10:58 Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote: > On Windows I now get a lot of framework failures, below. > > I have not tried them all, but some work fine when run individually; e.g. > > make TEST=AssocTyDef09 > > Simon > > > > > > Unexpected passes: > >rts/T7037.run T7037 [unexpected] (normal) > > > > Unexpected failures: > >ghci/prog003/prog003.run prog003 [bad exit code] (ghci) > >plugins/plugins07.run plugins07 [bad exit code] (normal) > > > > Unexpected stat failures: > >perf/haddock/haddock.compiler.run haddock.compiler [stat not good > enough] (normal) > > > > Framework failures: > >./cabal/T5442b.run T5442b > [runTest] (Unhandled exception: global name 'WindowsError' is not defined) > >./codeGen/should_run/cgrun040.runcgrun040 > [runTest] (Unhandled exception: global name 'WindowsError' is not defined) > >./concurrent/should_run/conc027.run conc027 > [runTest] (Unhandled exception: global name 'WindowsError' is not defined) > >./deSugar/should_run/dsrun010.rundsrun010 > [runTest] (Unhandled exception: global name 'WindowsError' is not defined) > >./dph/sumnats/dph-sumnats-vseg.run > dph-sumnats-vseg [runTest] (Unhandled exception: global name 'WindowsError' > is not defined) > >./dph/words/dph-words-copy-fast.run > dph-words-copy-fast [runTest] (Unhandled exception: global name > 'WindowsError' is not defined) > >./driver/T9963.run T9963 > [runTest] (Unhandled exception: global name 'WindowsError' is not defined) > >./ghci/scripts/ghci044a.run ghci044a > [runTest] (Unhandled exception: global name 'WindowsError' is not defined) > >./ghci/scripts/T4127.run T4127 > [runTest] (Unhandled exception: global name 'WindowsError' is not defined) > >./ghci/should_run/ghcirun001.run ghcirun001 > [runTest] (Unhandled exception: global name 'WindowsError' is not defined) > >./overloadedlists/should_fail/overloadedlistsfail02.run > overloadedlistsfail02 [runTest] (Unhandled exception: global name > 'WindowsError' is not defined) > >./package/package07e.run package07e > [runTest] (Unhandled exception: global name 'WindowsError' is not defined) > >./parser/should_fail/ParserNoForallUnicode.run > ParserNoForallUnicode [runTest] (Unhandled exception: global name > 'WindowsError' is not defined) > >./parser/should_fail/T12051.run T12051 > [runTest] (Unhandled exception: global name 'WindowsError' is not defined) > >./perf/should_run/T4830.run T4830 > [runTest] (Unhandled exception: global name 'WindowsError' is not defined) > > ./plugins/plugins07.run plugins07 > [normal] (pre_cmd failed: 2) > >./rts/stack003.run stack003 > [runTest] (Unhandled exception: global name 'WindowsError' is not defined) > >./rts/ffishutdown.runffishutdown > [runTest] (Unhandled exception: global name 'WindowsError' is not defined) > >./simplCore/should_compile/T3234.run T3234 > [runTest] (Unhandled exception: global name 'WindowsError' is not defined) > >./typecheck/should_compile/tc217.run tc217 > [runTest] (Unhandled exception: global name 'WindowsError' is not defined) > >./typecheck/should_fail/tcfail013.runtcfail013 > [runTest] (Unhandled exception: global name 'WindowsError' is not defined) > >./typecheck/should_fail/tcfail110.runtcfail110 > [runTest] (Unhandled exception: global name 'WindowsError' is not defined) > >./typecheck/should_fail/AssocTyDef09.run AssocTyDef09 > [runTest] (Unhandled exception: global name 'WindowsError' is not defined) > >../../libraries/base/tests/stableptr003.run stableptr003 > [runTest] (Unhandled exception: global name 'WindowsError' is not defined) > >../../libraries/base/tests/IO/ioeGetErrorString001.run > ioeGetErrorString001 [runTest] (Unhandled exception: global name > 'WindowsError' is not defined) > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Windows build
.../typecheck/should_fail$ which python /usr/bin/python .../typecheck/should_fail$ which python2 /usr/bin/python2 .../typecheck/should_fail$ which python3 /usr/bin/python3 .../typecheck/should_fail$ python --version Python 3.4.3 .../typecheck/should_fail$ python2 --version Python 2.7.11 .../typecheck/should_fail$ python3 --version Python 3.4.3 .../typecheck/should_fail$ From: Phyx [mailto:loneti...@gmail.com] Sent: 18 October 2016 11:07 To: Simon Peyton Jones ; ghc-devs@haskell.org Subject: Re: Windows build Hi Simon, What does which python 2 and which python 3 return? Along with uname -a? Tamar On Tue, Oct 18, 2016, 10:58 Simon Peyton Jones via ghc-devs mailto:ghc-devs@haskell.org>> wrote: On Windows I now get a lot of framework failures, below. I have not tried them all, but some work fine when run individually; e.g. make TEST=AssocTyDef09 Simon Unexpected passes: rts/T7037.run T7037 [unexpected] (normal) Unexpected failures: ghci/prog003/prog003.run prog003 [bad exit code] (ghci) plugins/plugins07.run plugins07 [bad exit code] (normal) Unexpected stat failures: perf/haddock/haddock.compiler.run haddock.compiler [stat not good enough] (normal) Framework failures: ./cabal/T5442b.run T5442b [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./codeGen/should_run/cgrun040.runcgrun040 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./concurrent/should_run/conc027.run conc027 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./deSugar/should_run/dsrun010.rundsrun010 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./dph/sumnats/dph-sumnats-vseg.run dph-sumnats-vseg [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./dph/words/dph-words-copy-fast.run dph-words-copy-fast [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./driver/T9963.run T9963 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./ghci/scripts/ghci044a.run ghci044a [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./ghci/scripts/T4127.run T4127 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./ghci/should_run/ghcirun001.run ghcirun001 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./overloadedlists/should_fail/overloadedlistsfail02.run overloadedlistsfail02 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./package/package07e.run package07e [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./parser/should_fail/ParserNoForallUnicode.run ParserNoForallUnicode [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./parser/should_fail/T12051.run T12051 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./perf/should_run/T4830.run T4830 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./plugins/plugins07.run plugins07 [normal] (pre_cmd failed: 2) ./rts/stack003.run stack003 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./rts/ffishutdown.runffishutdown [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./simplCore/should_compile/T3234.run T3234 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./typecheck/should_compile/tc217.run tc217 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./typecheck/should_fail/tcfail013.runtcfail013 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./typecheck/should_fail/tcfail110.runtcfail110 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./typecheck/should_fail/AssocTyDef09.run AssocTyDef09 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ../../libraries/base/tests/stableptr003.run stableptr003 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ../../lib
Re: Windows build
And uname -a? If you're on anything higher than 2.5.1 the runtime has a regression per Ben's email. If you're not. Try using python3 for testing. Make test PYTHON=/usr/bin/python3 On Tue, Oct 18, 2016, 11:30 Simon Peyton Jones wrote: > .../typecheck/should_fail$ which python > > /usr/bin/python > > .../typecheck/should_fail$ which python2 > > /usr/bin/python2 > > .../typecheck/should_fail$ which python3 > > /usr/bin/python3 > > .../typecheck/should_fail$ python --version > > Python 3.4.3 > > .../typecheck/should_fail$ python2 --version > > Python 2.7.11 > > .../typecheck/should_fail$ python3 --version > > Python 3.4.3 > > .../typecheck/should_fail$ > > > > *From:* Phyx [mailto:loneti...@gmail.com] > *Sent:* 18 October 2016 11:07 > *To:* Simon Peyton Jones ; ghc-devs@haskell.org > *Subject:* Re: Windows build > > > > Hi Simon, > > > > What does which python 2 and which python 3 return? Along with uname -a? > > > > Tamar > > On Tue, Oct 18, 2016, 10:58 Simon Peyton Jones via ghc-devs < > ghc-devs@haskell.org> wrote: > > On Windows I now get a lot of framework failures, below. > > I have not tried them all, but some work fine when run individually; e.g. > > make TEST=AssocTyDef09 > > Simon > > > > > > Unexpected passes: > >rts/T7037.run T7037 [unexpected] (normal) > > > > Unexpected failures: > >ghci/prog003/prog003.run prog003 [bad exit code] (ghci) > >plugins/plugins07.run plugins07 [bad exit code] (normal) > > > > Unexpected stat failures: > >perf/haddock/haddock.compiler.run haddock.compiler [stat not good > enough] (normal) > > > > Framework failures: > >./cabal/T5442b.run T5442b > [runTest] (Unhandled exception: global name 'WindowsError' is not defined) > >./codeGen/should_run/cgrun040.runcgrun040 > [runTest] (Unhandled exception: global name 'WindowsError' is not defined) > >./concurrent/should_run/conc027.run conc027 > [runTest] (Unhandled exception: global name 'WindowsError' is not defined) > >./deSugar/should_run/dsrun010.rundsrun010 > [runTest] (Unhandled exception: global name 'WindowsError' is not defined) > >./dph/sumnats/dph-sumnats-vseg.run > dph-sumnats-vseg [runTest] (Unhandled exception: global name 'WindowsError' > is not defined) > >./dph/words/dph-words-copy-fast.run > dph-words-copy-fast [runTest] (Unhandled exception: global name > 'WindowsError' is not defined) > >./driver/T9963.run T9963 > [runTest] (Unhandled exception: global name 'WindowsError' is not defined) > >./ghci/scripts/ghci044a.run ghci044a > [runTest] (Unhandled exception: global name 'WindowsError' is not defined) > >./ghci/scripts/T4127.run T4127 > [runTest] (Unhandled exception: global name 'WindowsError' is not defined) > >./ghci/should_run/ghcirun001.run ghcirun001 > [runTest] (Unhandled exception: global name 'WindowsError' is not defined) > >./overloadedlists/should_fail/overloadedlistsfail02.run > overloadedlistsfail02 [runTest] (Unhandled exception: global name > 'WindowsError' is not defined) > >./package/package07e.run package07e > [runTest] (Unhandled exception: global name 'WindowsError' is not defined) > >./parser/should_fail/ParserNoForallUnicode.run > ParserNoForallUnicode [runTest] (Unhandled exception: global name > 'WindowsError' is not defined) > >./parser/should_fail/T12051.run T12051 > [runTest] (Unhandled exception: global name 'WindowsError' is not defined) > >./perf/should_run/T4830.run T4830 > [runTest] (Unhandled exception: global name 'WindowsError' is not defined) > > ./plugins/plugins07.run plugins07 > [normal] (pre_cmd failed: 2) > >./rts/stack003.run stack003 > [runTest] (Unhandled exception: global name 'WindowsError' is not defined) > >./rts/ffishutdown.runffishutdown > [runTest] (Unhandled exception: global name 'WindowsError' is not defined) > >./simplCore/should_compile/T3234.run T3234 > [runTest] (Unhandled exception: global name
RE: Windows build
Sorry I forgot .../typecheck/should_fail$ uname -a MSYS_NT-10.0 MSRC-4079181 2.5.1(0.297/5/3) 2016-05-16 10:51 x86_64 Msys I’ll try Make test PYTHON=/usr/bin/python3 Simon From: Phyx [mailto:loneti...@gmail.com] Sent: 18 October 2016 11:39 To: Simon Peyton Jones ; ghc-devs@haskell.org Subject: Re: Windows build And uname -a? If you're on anything higher than 2.5.1 the runtime has a regression per Ben's email. If you're not. Try using python3 for testing. Make test PYTHON=/usr/bin/python3 On Tue, Oct 18, 2016, 11:30 Simon Peyton Jones mailto:simo...@microsoft.com>> wrote: .../typecheck/should_fail$ which python /usr/bin/python .../typecheck/should_fail$ which python2 /usr/bin/python2 .../typecheck/should_fail$ which python3 /usr/bin/python3 .../typecheck/should_fail$ python --version Python 3.4.3 .../typecheck/should_fail$ python2 --version Python 2.7.11 .../typecheck/should_fail$ python3 --version Python 3.4.3 .../typecheck/should_fail$ From: Phyx [mailto:loneti...@gmail.com<mailto:loneti...@gmail.com>] Sent: 18 October 2016 11:07 To: Simon Peyton Jones mailto:simo...@microsoft.com>>; ghc-devs@haskell.org<mailto:ghc-devs@haskell.org> Subject: Re: Windows build Hi Simon, What does which python 2 and which python 3 return? Along with uname -a? Tamar On Tue, Oct 18, 2016, 10:58 Simon Peyton Jones via ghc-devs mailto:ghc-devs@haskell.org>> wrote: On Windows I now get a lot of framework failures, below. I have not tried them all, but some work fine when run individually; e.g. make TEST=AssocTyDef09 Simon Unexpected passes: rts/T7037.run T7037 [unexpected] (normal) Unexpected failures: ghci/prog003/prog003.run prog003 [bad exit code] (ghci) plugins/plugins07.run plugins07 [bad exit code] (normal) Unexpected stat failures: perf/haddock/haddock.compiler.run haddock.compiler [stat not good enough] (normal) Framework failures: ./cabal/T5442b.run T5442b [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./codeGen/should_run/cgrun040.runcgrun040 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./concurrent/should_run/conc027.run conc027 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./deSugar/should_run/dsrun010.rundsrun010 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./dph/sumnats/dph-sumnats-vseg.run dph-sumnats-vseg [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./dph/words/dph-words-copy-fast.run dph-words-copy-fast [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./driver/T9963.run T9963 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./ghci/scripts/ghci044a.run ghci044a [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./ghci/scripts/T4127.run T4127 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./ghci/should_run/ghcirun001.run ghcirun001 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./overloadedlists/should_fail/overloadedlistsfail02.run overloadedlistsfail02 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./package/package07e.run package07e [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./parser/should_fail/ParserNoForallUnicode.run ParserNoForallUnicode [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./parser/should_fail/T12051.run T12051 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./perf/should_run/T4830.run T4830 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./plugins/plugins07.run plugins07 [normal] (pre_cmd failed: 2) ./rts/stack003.run stack003 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./rts/ffishutdown.runffishutdown [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./simplCore/should_compile/T3234.run T3234 [runTest] (Unhandled exception: global name 'WindowsError' is not defined) ./typecheck/should_compile/tc217.run tc217 [runTest] (U
Windows Builder Disabled
I have disabled the windows builder as it is consistently failing with the same error message. From this log for example: https://phabricator.haskell.org/harbormaster/build/14430/ ghc.exe: getMBlocks: VirtualAlloc MEM_COMMIT failed: The paging file is too small for this operation to complete. 764ghc.exe: failed to create OS thread: The paging file is too small for this operation to complete. Do you have any ideas Ben/Tamar? I can't see any recent commits which would have caused this failure. Matt ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: windows build
Whizzo! Window builds are up again. Thank you! Here are the errors I get, which seem more manageable. Simon Unexpected passes: rts/T7037.run T7037 [unexpected] (normal) Unexpected failures: ghci/prog003/prog003.run prog003 [bad exit code] (ghci) plugins/plugins07.run plugins07 [bad exit code] (normal) Unexpected stat failures: perf/haddock/haddock.compiler.run haddock.compiler [stat not good enough] (normal) perf/should_run/T876.run T876 [stat too good] (normal) Framework failures: plugins/plugins07.run plugins07 [normal] (pre_cmd failed: 2) | -Original Message- | From: Ben Gamari [mailto:b...@well-typed.com] | Sent: 17 November 2016 15:24 | To: Simon Peyton Jones | Subject: RE: windows build | | Simon Peyton Jones writes: | | > OK thank you. | > | > Meanwhile, what about the RTS error? | | A fix has been merged for the RTS issue | (b76958671cda1df9f6f0e1d54d681144d09cb06e). Tamar is still looking at the | testsuite driver issue (#12554) and has a suspicion that the issue is | file handle inheritance. He's going to try to put together a fix tonight. | | Cheers, | | - Ben ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Windows toolchain update
Hi Windows devs, The Windows GCC has been updated to 6.2.0 and binutils to 2.27. At some point please rebuild using these binaries. Do throw away your old toolchain cache before getting the new one: rm -rf ghc-tarballs && ./configure --enable-tarballs-autodownload The plan is to ship these versions with GHC 8.2, though binutils will likely Get another minor bump. Thanks, Tamar ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Windows build
Hi Simon, For the tests what Ben’s email forgot to say was that the build system doesn’t pick up on changes to Timeout. So you’d need to nuke it to get the fixes for timing related things: rm -rf testsuite/timeout/dist && rm -rf testsuite/timeout/install-inplace And rerun the tests should fix a few including prog003. For the plugin ones we reverted the commit that caused the failures. I’m currently working on fixing the hsc2hs ones you might see pop up every now and again. The haddock one is new as well, Don’t know what caused it. If you can nuke timeout and rebase to head you should only have the haddock one left. Also we’ve nuked support for python 2. If you’re up to date with master then we only accept python 3 so that should be alright. If you still have these failures (particularly the framework failures ones) could you possibly send me the errors printed on stderr? The errors are hard to reproduce on all machines so logs help a lot. Thanks, Tamar From: Simon Peyton Jones via ghc-devs Sent: Wednesday, November 30, 2016 22:50 To: ghc-devs@haskell.org Subject: Windows build Thanks for all the work you’ve been doing on the Windows build. As requested by Tamar I removed ghc-tarballs, and reconfigured. Then I built from scratch. I get the following testsuite failures Simon Unexpected failures: ghci/prog003/prog003.run prog003 [bad exit code] (ghci) plugins/plugins05.run plugins05 [exit code non-0] (normal) plugins/plugins01.run plugins01 [bad exit code] (normal) plugins/plugins07.run plugins07 [bad exit code] (normal) plugins/T10420.run T10420 [bad exit code] (normal) plugins/T10294a.run T10294a [bad exit code] (normal) plugins/T11244.run T11244 [bad stderr] (normal) plugins/T12567a.run T12567a [bad exit code] (normal) rts/testmblockalloc.run testmblockalloc [bad exit code] (normal) simplCore/should_compile/T7702.run T7702 [exit code non-0] (normal) Unexpected stat failures: perf/haddock/haddock.compiler.run haddock.compiler [stat not good enough] (normal) Framework failures: ghci/scripts/ghci062.run ghci062 [ghci-ext] ([Errno 17] File exists: '/c/Users/simonpj/AppData/Local/Temp/ghctest-anc5s5mh/test spaces/./ghci/scripts/ghci062.run') plugins/plugins07.run plugins07 [normal] (pre_cmd failed: 2) plugins/T10420.run T10420 [normal] (pre_cmd failed: 2) plugins/T10294a.run T10294a [normal] (pre_cmd failed: 2) plugins/T11244.run T11244 [normal] (pre_cmd failed: 2) th/TH_repPrim.run TH_repPrim [ext-interp] ([Errno 17] File exists: '/c/Users/simonpj/AppData/Local/Temp/ghctest-anc5s5mh/test spaces/./th/TH_repPrim.run') th/TH_repPatSig.run TH_repPatSig [ext-interp] ([Errno 17] File exists: '/c/Users/simonpj/AppData/Local/Temp/ghctest-anc5s5mh/test spaces/./th/TH_repPatSig.run') ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Windows validate failures
I'm getting irreproducible validate failures on Windows. Here's the output: Unexpected failures: ghci/prog003/prog003.run prog003 [bad exit code] (ghci) plugins/plugins07.run plugins07 [bad exit code] (normal) plugins/T10420.runT10420 [bad exit code] (normal) plugins/T10294a.run T10294a [bad exit code] (normal) plugins/T11244.runT11244 [bad stderr] (normal) Framework failures: plugins/plugins07.run plugins07 [normal] (pre_cmd failed: 2) plugins/T10420.run T10420 [normal] (pre_cmd failed: 2) plugins/T10294a.runT10294a [normal] (pre_cmd failed: 2) plugins/T11244.run T11244 [normal] (pre_cmd failed: 2) th/TH_spliceE5.run TH_spliceE5 [ext-interp] ([Errno 17] File exists: '/c/Users/simonpj/AppData/Local/Temp/ghctest-zsi7djxa/test spaces/./th/TH_spliceE5.run') th/TH_reifyMkName.run TH_reifyMkName [ext-interp] ([Errno 17] File exists: '/c/Users/simonpj/AppData/Local/Temp/ghctest-zsi7djxa/test spaces/./th/TH_reifyMkName.run') th/T3395.run T3395 [ext-interp] ([Errno 17] File exists: '/c/Users/simonpj/AppData/Local/Temp/ghctest-zsi7djxa/test spaces/./th/T3395.run') th/T5508.run T5508 [ext-interp] ([Errno 17] File exists: '/c/Users/simonpj/AppData/Local/Temp/ghctest-zsi7djxa/test spaces/./th/T5508.run') th/T10828.run T10828 [ext-interp] ([Errno 17] File exists: '/c/Users/simonpj/AppData/Local/Temp/ghctest-zsi7djxa/test spaces/./th/T10828.run') I have no idea what the framework failures mean. But those plugin tests work ok when run one at a time .../tests/plugins$ make TEST=T10420 PYTHON="python3" "python3" ../../driver/runtests.py -e ghc_compiler_always_flags="'-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -dno-debug-output'" -e config.compiler_debugged=False -e ghc_with_native_codegen=1 -e config.have_vanilla=True -e config.have_dynamic=False -e config.have_profiling=False -e ghc_with_threaded_rts=1 -e ghc_with_dynamic_rts=0 -e config.have_interp=True -e config.unregisterised=False -e config.ghc_dynamic_by_default=False -e config.ghc_dynamic=False -e ghc_with_smp=1 -e ghc_with_llvm=0 -e windows=True -e darwin=False -e config.in_tree_compiler=True -e config.cleanup=True -e config.local=True --rootdir=. --configfile=../../config/ghc -e 'config.confdir="../../config"' -e 'config.platform="x86_64-unknown-mingw32"' -e 'config.os="mingw32"' -e 'config.arch="x86_64"' -e 'config.wordsize="64"' -e 'config.timeout=int() or config.timeout' -e 'config.exeext=".exe"' -e 'config.top="/c/code/HEAD/testsuite"' --config 'compiler="/c/code/HEAD/inplace/bin/ghc-stage2.exe"' --config 'ghc_pkg="/c/code/HEAD/inplace/bin/ghc-pkg.exe"' --config 'haddock="/c/code/HEAD/inplace/bin/haddock.exe"' --config 'hp2ps="/c/code/HEAD/inplace/bin/hp2ps.exe"' --config 'hpc="/c/code/HEAD/inplace/bin/hpc.exe"' --config 'gs="gs"' --config 'timeout_prog="../../timeout/install-inplace/bin/timeout.exe"' -e "config.stage=2" \ --only=T10420 \ \ \ \ \ \ Timeout is 300 Found 1 .T files... Beginning test run at Thu Dec 8 12:02:23 2016 GMTST > Scanning ./all.T => T10420(normal) 1 of 1 [0, 0, 0] cd "./T10420.run" && $MAKE -s --no-print-directory -C rule-defining-plugin package.T10420 TOP=/c/code/HEAD/testsuite cd "./T10420.run" && $MAKE -s --no-print-directory T10420 SUMMARY for test run started at Thu Dec 8 12:02:23 2016 GMTST 0:00:13 spent to go through 1 total tests, which gave rise to 1 test cases, of which 0 were skipped 0 had missing libraries 1 expected passes 0 expected failures 0 caused framework failures 0 unexpected passes 0 unexpected failures 0 unexpected stat failures ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
More windows woe
I see that anything involving ghci fails: /c/code/HEAD/inplace/bin/ghc-stage2 --interactive GHCi, version 8.1.20161209: http://www.haskell.org/ghc/ :? for help ghc-stage2.exe: unable to load package `base-4.9.0.0' ghc-stage2.exe: C:\code\HEAD\inplace\mingw\x86_64-w64-mingw32\lib\libmingwex.a: unknown symbol `_lock_file' ghc-stage2.exe: Could not on-demand load symbol '__mingw_vfprintf' ghc-stage2.exe: C:\code\HEAD\libraries\base\dist-install\build\HSbase-4.9.0.0.o: unknown symbol `__mingw_vfprintf' It's frustrating. It used to work! Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Windows build
Hi Simon, Thanks for the update, I can reproduce a similar failure on the build bot and one of my own machines. I’m looking into what might be causing it, I have something I want to try but not Sure yet it will solve it. I don’t need more information atm as I can reproduce the race condition by doing enough I/O. Thanks, Tamar From: Simon Peyton Jones Sent: Tuesday, January 17, 2017 08:13 To: Phyx Cc: ghc-devs Subject: Windows build Hi Tamar The current state of a clean Windows build has improved – but still has multiple failures. See below Thanks for your work on this. I can send more details if that’d be helpful Simon Unexpected failures: plugins/plugins07.run plugins07 [bad exit code] (normal) plugins/T10420.run T10420 [bad exit code] (normal) plugins/T10294a.run T10294a [bad exit code] (normal) plugins/T11244.run T11244 [bad stderr] (normal) Framework failures: backpack/cabal/bkpcabal03/bkpcabal03.run bkpcabal03 [runTest] (Unhandled exception: [Errno 90] Directory not empty: 'autogen') plugins/plugins07.run plugins07 [normal] (pre_cmd failed: 2) plugins/T10420.run T10420 [normal] (pre_cmd failed: 2) plugins/T10294a.run T10294a [normal] (pre_cmd failed: 2) plugins/plugins07.run plugins07 [runTest] (Unhandled exception: [Errno 90] Directory not empty: 'rule-defining-plugin-0.1') plugins/T11244.run T11244 [normal] (pre_cmd failed: 2) safeHaskell/check/pkg01/ImpSafeOnly03.run ImpSafeOnly03 [runTest] (Unhandled exception: [Errno 90] Directory not empty: 'safePkg01-1.0-COK8JB4prM8EuKYKd3XaX3') ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Windows build broken
Please please please could some one fix this? On windows. It's frustrating being unable to build. Please please Simon libraries\time\lib\Data\Time\Clock\Internal\SystemTime.hs:57:5: error: Not in scope: data constructorFILETIME Perhaps you meantWin32.FILETIME(imported from System.Win32.Time) | 57 | FILETIME ft <- Win32.getSystemTimeAsFileTime | ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Windows build broken
Windows build is broken again. Might someone fix? Simon "inplace/bin/ghc-stage1.exe" -optc-fno-stack-protector -optc-Wall -optc-Werror -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-Irts/dist/build/./autogen -optc-Wno-error=inline -optc-O2 -optc-fomit-frame-pointer -optc-g -optc-DRtsWay=\"rts_p\" -optc-DWINVER=0x06000100 -static -prof -eventlog -O0 -H64m -Wall -fllvm-fill-undef-with-garbage-Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2-Wnoncanonical-monad-instances -c rts/Sparks.c -o rts/dist/build/Sparks.p_o rts\Profiling.c: In function 'reportCCSProfiling': rts\Profiling.c:704:9: error: error: implicit declaration of function 'writeCCSReportJson' [-Werror=implicit-function-declaration] writeCCSReportJson(prof_file, stack, totals); ^~ | 704 | writeCCSReportJson(prof_file, stack, totals); | ^ rts\Profiling.c:704:9: error: error: nested extern declaration of 'writeCCSReportJson' [-Werror=nested-externs] | 704 | writeCCSReportJson(prof_file, stack, totals); | ^ cc1.exe: all warnings being treated as errors `gcc.exe' failed in phase `C Compiler'. (Exit code: 1) make[1]: *** [rts/ghc.mk:255: rts/dist/build/Profiling.p_o] Error 1 make[1]: *** Waiting for unfinished jobs make: *** [Makefile:127: all] Error 2 /c/code/HEAD$ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Windows broken
Hi Simon,
What happens when you try to compile that simple test with the bundled gcc?
Could you also run it through strace, this will force msys2 not to swallow
errors from the OS.
Should you get an exception dialog then rm -rf inplace/mingw and rerun
configure (I assume you’re on a recent revision).
If none of the above give a clue, you could try ./configure
--enable-distro-toolchain, this will have it skip the bundled GCC
And use any installed by msys2. If this work then try rm’ing the GHC-tarballs
folder and the inplace/mingw folder and try again
With –enable-tarballs-autodownloads.
Tamar.
From: Simon Peyton Jones via ghc-devs
Sent: Thursday, June 29, 2017 00:35
To: ghc-devs
Subject: Windows broken
Help please!
Suddenly my Windows build has stopped working. See below. What should I do?
I’m totally stuck.
This has never happened before.
I get this:
GHC path canonicalised to: c:/fp/ghc-8.0.2/bin/ghc
checking build system type... x86_64-pc-msys
checking host system type... x86_64-pc-msys
checking target system type... x86_64-pc-msys
Build platform inferred as: x86_64-unknown-mingw32
Host platform inferred as: x86_64-unknown-mingw32
Target platform inferred as: x86_64-unknown-mingw32
GHC build : x86_64-unknown-mingw32
GHC host : x86_64-unknown-mingw32
GHC target : x86_64-unknown-mingw32
LLVM target: x86_64-unknown-mingw32
checking for path to top of build tree... C:/code/HEAD
configure: Checking for Windows toolchain tarballs...
configure: Extracting Windows toolchain from archives (may take a while)...
configure: In-tree MingW-w64 tree created
configure: Making in-tree perl tree
configure: In-tree perl tree created
checking whether the C compiler works... no
configure: error: in `/c/code/HEAD':
configure: error: C compiler cannot create executables
See `config.log' for more details
Something wrong with the gcc.exe? Config.log has this
gcc version 6.3.0 (Rev2, Built by MSYS2 project)
configure:4950: $? = 0
configure:4939: C:/code/HEAD/inplace/mingw/bin/gcc.exe -V >&5
gcc.exe: error: unrecognized command line option '-V'
gcc.exe: fatal error: no input files
compilation terminated.
configure:4950: $? = 1
configure:4939: C:/code/HEAD/inplace/mingw/bin/gcc.exe -qversion >&5
gcc.exe: error: unrecognized command line option '-qversion'; did you mean
'--version'?
gcc.exe: fatal error: no input files
compilation terminated.
configure:4950: $? = 1
configure:4970: checking whether the C compiler works
configure:4992: C:/code/HEAD/inplace/mingw/bin/gcc.exe conftest.c >&5
configure:4996: $? = 1
configure:5034: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "The Glorious Glasgow Haskell Compilation System"
| #define PACKAGE_TARNAME "ghc-8.3"
| #define PACKAGE_VERSION "8.3"
| #define PACKAGE_STRING "The Glorious Glasgow Haskell Compilation System 8.3"
| #define PACKAGE_BUGREPORT "glasgow-haskell-b...@haskell.org"
| #define PACKAGE_URL ""
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:5039: error: in `/c/code/HEAD':
configure:5041: error: C compiler cannot create executables
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Windows broken
If I compile a test foo.c I get this C:/code/HEAD/inplace/mingw/bin/gcc.exe -v foo.c Using built-in specs. COLLECT_GCC=C:\code\HEAD\inplace\mingw\bin\gcc.exe COLLECT_LTO_WRAPPER=C:/code/HEAD/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../gcc-6.3.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev2, Built by MSYS2 project' --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld Thread model: posix gcc version 6.3.0 (Rev2, Built by MSYS2 project) COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64' C:/code/HEAD/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/cc1.exe -quiet -v -iprefix C:/code/HEAD/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/ -D_REENTRANT foo.c -quiet -dumpbase foo.c -mtune=generic -march=x86-64 -auxbase foo -version -o C:\Users\simonpj\AppData\Local\Temp\ccHvaSrL.s /c/tmp$ So apparently the last line fails. Running that by itself I get C:/code/HEAD/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/cc1.exe -v -iprefix C:/code/HEAD/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/ -D_REENTRANT foo.c -quiet -dumpbase foo.c -mtune=generic -march=x86-64 -auxbase foo -version -o foo.s C:/code/HEAD/inplace/mingw/lib/gcc/x86_64-w64-mingw32/6.3.0/cc1.exe: error while loading shared libraries: libwinpthread-1.dll: cannot open shared object file: No such file or directory /c/tmp$ So it can’t find that DLL. But it exists all right /c/code/HEAD$ find inplace/mingw -name 'libwinpthread-1.dll' inplace/mingw/bin/libwinpthread-1.dll The same thing happens, but with a popup alert window, if I use ‘strace gcc …’. What now? Simon From: loneti...@gmail.com [mailto:loneti...@gmail.com] Sent: 29 June 2017 02:38 To: Simon Peyton Jones ; ghc-devs Subject: RE: Windows broken Hi Simon, What happens when you try to compile that simple test with the bundled gcc? Could you also run it through strace, this will force msys2 not to swallow errors from the OS. Should you get an exception dialog then rm -rf inplace/mingw and rerun configure (I assume you’re on a recent revision). If none of the above give a clue, you could try ./configure --enable-distro-toolchain, this will have it skip the bundled GCC And use any installed by msys2. If this work then try rm’ing the GHC-tarballs folder and the inplace/mingw folder and try again With –enable-tarballs-autodownloads. Tamar. From: Simon Peyton Jones via ghc-devs<mailto:ghc-devs@haskell.org> Sent: Thursday, June 29, 2017 00:35 To: ghc-devs<mailto:ghc-devs@haskell.org> Subject: Windows broken Help please! Suddenly my Windows build has stopped working. See below. What should I do? I’m totally stuck. This has never happened before. I get this: GHC path canonicalised to: c:/fp/ghc-8.0.2/bin/ghc checking build system type... x86_64-pc-msys checking host system type... x86_64-pc-msys checking target system type... x86_64-pc-msys Build platform inferred as: x86_64-unknown-mingw32 Host platform inferred as: x86_64-unknown-mingw32 Target platform inferred as: x86_64-unknown-mingw32 GHC build : x86_64-unknown-mingw32 GHC host : x86_64-unknown-mingw32 GHC target : x86_64-unknown-mingw32 LLVM target: x86_64-unknown-mingw32 checking for path to top of build tree... C:/code/HEAD configure: Checking for Windows toolchain tarballs... configure: Extracting Windows toolchain from archives (may take a while)... configure: In-tree MingW-w64 tree created configure: Making in-tree perl tree configure: In-tree perl tree created checking whether the C compiler works... no configure: error: in `/c/code/HEAD': configure: error: C compiler cannot create executables See `config.log' for more details Something wrong with the gcc.exe? Config.log has this gcc version 6.3.0 (Rev2, Built by MSYS2 project) configure:4950: $? = 0 configure:4939: C:/code/HEAD/inplace/mingw/bin/gcc.exe -V >&5 gcc.exe: error: unrecognized command line option '-V' gcc.exe: fatal error: no input files compil
RE: Windows broken
Tamar Aha! It’s you! Reverting this commit fixes it git revert d6cecde585b0980ed8e0050c5a1d315789fb6356 [master af9f0f4] Revert "Remove the Windows GCC driver." 5 files changed, 88 insertions(+), 30 deletions(-) create mode 100644 driver/gcc/gcc.c If you can see an easy fix I can try that. Else I’ll probably just revert and let you investigate. I appear not to have Cygwin, and no other gcc is not in my path. I just rely on the one that comes with GHC. After reverting, here’s what happens when I compile foo.c (trace below). The invocation of cc1.exe looks rather different C:/code/HEAD/inplace/mingw/bin/gcc.exe -v foo.c Using built-in specs. COLLECT_GCC=C:\\code\\HEAD\\inplace\\mingw\\bin/realgcc.exe COLLECT_LTO_WRAPPER=C://code//HEAD//inplace//mingw//bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../gcc-6.3.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev2, Built by MSYS2 project' --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld Thread model: posix gcc version 6.3.0 (Rev2, Built by MSYS2 project) COLLECT_GCC_OPTIONS='-B' 'C:\\code\\HEAD\\inplace\\mingw\\bin' '-B' 'C:\\code\\HEAD\\inplace\\mingw\\bin/../lib' '-B' 'C:\\code\\HEAD\\inplace\\mingw\\bin/../lib/gcc/x86_64-w64-mingw32/6.3.0' '-B' 'C:\\code\\HEAD\\inplace\\mingw\\bin/../libexec/gcc/x86_64-w64-mingw32/6.3.0' '-v' '-mtune=generic' '-march=x86-64' C://code//HEAD//inplace//mingw//bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/cc1.exe -quiet -v -iprefix C:/code/HEAD/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/ -isystem C://code//HEAD//inplace//mingw//bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/include -isystem C://code//HEAD//inplace//mingw//bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/include-fixed -D_REENTRANT foo.c -quiet -dumpbase foo.c -mtune=generic -march=x86-64 -auxbase foo -version -o C:\Users\simonpj\AppData\Local\Temp\ccGa7vqE.s GNU C11 (Rev2, Built by MSYS2 project) version 6.3.0 (x86_64-w64-mingw32) compiled by GNU C version 6.3.0, GMP version 6.1.2, MPFR version 3.1.5-p2, MPC version 1.0.3, isl version 0.15 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring duplicate directory "C:/code/HEAD/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/include" ignoring duplicate directory "C:/code/HEAD/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/include-fixed" ignoring duplicate directory "C:/code/HEAD/inplace/mingw/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/6.3.0/include" ignoring nonexistent directory "C:/building/msys64/mingw64/include" ignoring nonexistent directory "/mingw64/include" ignoring duplicate directory "C:/code/HEAD/inplace/mingw/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/6.3.0/include-fixed" ignoring duplicate directory "C:/code/HEAD/inplace/mingw/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/6.3.0/../../../../x86_64-w64-mingw32/include" ignoring nonexistent directory "C:/building/msys64/mingw64/x86_64-w64-mingw32/include" #include "..." search starts here: #include <...> search starts here: C://code//HEAD//inplace//mingw//bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/include C://code//HEAD//inplace//mingw//bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/include-fixed C:/code/HEAD/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/../../../../include C:/code/HEAD/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/../../../../x86_64-w64-mingw32/include End of search list. GNU C11 (Rev2, Built by MSYS2 project) version 6.3.0 (x86_64-w64-mingw32) compiled by GNU C version 6.3.0, GMP version 6.1.2, MPFR version 3.1.5-p2, MPC version 1.0.3, isl version 0.15 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: bdbc00c2d895b1ff93d4c2cb4c58b5b1 From: loneti...@gmail.com [mailto:loneti...@gmail.com] Sent: 29 June 2017 02:38 To: Simon Peyton Jon
RE: Windows broken
Oops, sorry, didn’t notice it because both mine and harbormaster’s msys2 have separate GCCs installed as well. You can just leave it reverted, could you also push it? I don’t see an easy fix that would also work for end user Configure based cabal installs. So I think I’ll have to go back to the drawing board for this one. Thanks, Tamar From: Simon Peyton Jones Sent: Thursday, June 29, 2017 09:10 To: loneti...@gmail.com; ghc-devs Subject: RE: Windows broken Tamar Aha! It’s you! Reverting this commit fixes it git revert d6cecde585b0980ed8e0050c5a1d315789fb6356 [master af9f0f4] Revert "Remove the Windows GCC driver." 5 files changed, 88 insertions(+), 30 deletions(-) create mode 100644 driver/gcc/gcc.c If you can see an easy fix I can try that. Else I’ll probably just revert and let you investigate. I appear not to have Cygwin, and no other gcc is not in my path. I just rely on the one that comes with GHC. After reverting, here’s what happens when I compile foo.c (trace below). The invocation of cc1.exe looks rather different C:/code/HEAD/inplace/mingw/bin/gcc.exe -v foo.c Using built-in specs. COLLECT_GCC=C:\\code\\HEAD\\inplace\\mingw\\bin/realgcc.exe COLLECT_LTO_WRAPPER=C://code//HEAD//inplace//mingw//bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../gcc-6.3.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev2, Built by MSYS2 project' --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld Thread model: posix gcc version 6.3.0 (Rev2, Built by MSYS2 project) COLLECT_GCC_OPTIONS='-B' 'C:\\code\\HEAD\\inplace\\mingw\\bin' '-B' 'C:\\code\\HEAD\\inplace\\mingw\\bin/../lib' '-B' 'C:\\code\\HEAD\\inplace\\mingw\\bin/../lib/gcc/x86_64-w64-mingw32/6.3.0' '-B' 'C:\\code\\HEAD\\inplace\\mingw\\bin/../libexec/gcc/x86_64-w64-mingw32/6.3.0' '-v' '-mtune=generic' '-march=x86-64' C://code//HEAD//inplace//mingw//bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/cc1.exe -quiet -v -iprefix C:/code/HEAD/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/ -isystem C://code//HEAD//inplace//mingw//bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/include -isystem C://code//HEAD//inplace//mingw//bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/include-fixed -D_REENTRANT foo.c -quiet -dumpbase foo.c -mtune=generic -march=x86-64 -auxbase foo -version -o C:\Users\simonpj\AppData\Local\Temp\ccGa7vqE.s GNU C11 (Rev2, Built by MSYS2 project) version 6.3.0 (x86_64-w64-mingw32) compiled by GNU C version 6.3.0, GMP version 6.1.2, MPFR version 3.1.5-p2, MPC version 1.0.3, isl version 0.15 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring duplicate directory "C:/code/HEAD/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/include" ignoring duplicate directory "C:/code/HEAD/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/include-fixed" ignoring duplicate directory "C:/code/HEAD/inplace/mingw/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/6.3.0/include" ignoring nonexistent directory "C:/building/msys64/mingw64/include" ignoring nonexistent directory "/mingw64/include" ignoring duplicate directory "C:/code/HEAD/inplace/mingw/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/6.3.0/include-fixed" ignoring duplicate directory "C:/code/HEAD/inplace/mingw/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/6.3.0/../../../../x86_64-w64-mingw32/include" ignoring nonexistent directory "C:/building/msys64/mingw64/x86_64-w64-mingw32/include" #include "..." search starts here: #include <...> search starts here: C://code//HEAD//inplace//mingw//bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/include C://code//HEAD//inplace//mingw//bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/include-fixed C:/code/HEAD/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/../../../../include C:/code/HEAD/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/../../../../x86_64-w64-mingw32/include End of search list. GNU
RE: Windows broken
You can just leave it reverted, could you also push it? Yes ok. I’m sorry to push you back to the drawing board ☹. Simon From: loneti...@gmail.com [mailto:loneti...@gmail.com] Sent: 29 June 2017 09:37 To: Simon Peyton Jones ; ghc-devs Subject: RE: Windows broken Oops, sorry, didn’t notice it because both mine and harbormaster’s msys2 have separate GCCs installed as well. You can just leave it reverted, could you also push it? I don’t see an easy fix that would also work for end user Configure based cabal installs. So I think I’ll have to go back to the drawing board for this one. Thanks, Tamar From: Simon Peyton Jones<mailto:simo...@microsoft.com> Sent: Thursday, June 29, 2017 09:10 To: loneti...@gmail.com<mailto:loneti...@gmail.com>; ghc-devs<mailto:ghc-devs@haskell.org> Subject: RE: Windows broken Tamar Aha! It’s you! Reverting this commit fixes it git revert d6cecde585b0980ed8e0050c5a1d315789fb6356 [master af9f0f4] Revert "Remove the Windows GCC driver." 5 files changed, 88 insertions(+), 30 deletions(-) create mode 100644 driver/gcc/gcc.c If you can see an easy fix I can try that. Else I’ll probably just revert and let you investigate. I appear not to have Cygwin, and no other gcc is not in my path. I just rely on the one that comes with GHC. After reverting, here’s what happens when I compile foo.c (trace below). The invocation of cc1.exe looks rather different C:/code/HEAD/inplace/mingw/bin/gcc.exe -v foo.c Using built-in specs. COLLECT_GCC=C:\\code\\HEAD\\inplace\\mingw\\bin/realgcc.exe COLLECT_LTO_WRAPPER=C://code//HEAD//inplace//mingw//bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../gcc-6.3.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev2, Built by MSYS2 project' --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld Thread model: posix gcc version 6.3.0 (Rev2, Built by MSYS2 project) COLLECT_GCC_OPTIONS='-B' 'C:\\code\\HEAD\\inplace\\mingw\\bin' '-B' 'C:\\code\\HEAD\\inplace\\mingw\\bin/../lib' '-B' 'C:\\code\\HEAD\\inplace\\mingw\\bin/../lib/gcc/x86_64-w64-mingw32/6.3.0' '-B' 'C:\\code\\HEAD\\inplace\\mingw\\bin/../libexec/gcc/x86_64-w64-mingw32/6.3.0' '-v' '-mtune=generic' '-march=x86-64' C://code//HEAD//inplace//mingw//bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/cc1.exe -quiet -v -iprefix C:/code/HEAD/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/ -isystem C://code//HEAD//inplace//mingw//bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/include -isystem C://code//HEAD//inplace//mingw//bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/include-fixed -D_REENTRANT foo.c -quiet -dumpbase foo.c -mtune=generic -march=x86-64 -auxbase foo -version -o C:\Users\simonpj\AppData\Local\Temp\ccGa7vqE.s GNU C11 (Rev2, Built by MSYS2 project) version 6.3.0 (x86_64-w64-mingw32) compiled by GNU C version 6.3.0, GMP version 6.1.2, MPFR version 3.1.5-p2, MPC version 1.0.3, isl version 0.15 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring duplicate directory "C:/code/HEAD/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/include" ignoring duplicate directory "C:/code/HEAD/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/include-fixed" ignoring duplicate directory "C:/code/HEAD/inplace/mingw/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/6.3.0/include" ignoring nonexistent directory "C:/building/msys64/mingw64/include" ignoring nonexistent directory "/mingw64/include" ignoring duplicate directory "C:/code/HEAD/inplace/mingw/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/6.3.0/include-fixed" ignoring duplicate directory "C:/code/HEAD/inplace/mingw/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/6.3.0/../../../../x86_64-w64-mingw32/include" ignoring nonexistent directory "C:/building/msys64/mingw64/x86_64-w64-mingw32/include" #include "..." search starts here: #include <...&g
Windows build broken
My Windows build is broken again. With a clean checkout, I get "" Target platform inferred as: x86_64-unknown-mingw32 Unknown OS msys How can I get past this? Full log below. Simon make[1]: Leaving directory '/c/code/HEAD/testsuite' ['libraries/array/', 'libraries/base/', 'libraries/binary/', 'libraries/bytestring/', 'libraries/Cabal/Cabal', 'libraries/Cabal/', 'libraries/compact/', 'libraries/containers/', 'libraries/deepseq/', 'libraries/directory/', 'libraries/doc/', 'libraries/dph/dph-base', 'libraries/dph/dph-prim-interface', 'libraries/dph/dph-prim-seq', 'libraries/dph/dph-prim-par', 'libraries/dph/dph-lifted-base', 'libraries/dph/dph-lifted-boxed', 'libraries/dph/dph-lifted-copy', 'libraries/dph/dph-lifted-vseg', 'libraries/dph/', 'libraries/dph/', 'libraries/filepath/', 'libraries/ghc-boot/', 'libraries/ghc-boot-th/', 'libraries/ghc-compact/', 'libraries/ghc-prim/', 'libraries/ghci/', 'libraries/haskeline/', 'libraries/hoopl/', 'libraries/hpc/', 'libraries/integer-gmp/', 'libraries/integer-simple/', 'libraries/mtl/', 'libraries/parallel/', 'libraries/parsec/', 'libraries/pretty/', 'libraries/primitive/', 'libraries/process/', 'libraries/random/', 'libraries/stm/', 'libraries/template-haskell/', 'libraries/terminfo/', 'libraries/text/', 'libraries/time/', 'libraries/transformers/', 'libraries/unix/', 'libraries/vector/', 'libraries/Win32/', 'libraries/xhtml/'] Creating libraries/array/ghc.mk Creating libraries/base/ghc.mk Creating libraries/binary/ghc.mk Creating libraries/bytestring/ghc.mk Creating libraries/Cabal/Cabal/ghc.mk Creating libraries/containers/ghc.mk Creating libraries/deepseq/ghc.mk Creating libraries/directory/ghc.mk Creating libraries/dph/dph-base/ghc.mk Creating libraries/dph/dph-prim-interface/ghc.mk Creating libraries/dph/dph-prim-seq/ghc.mk Creating libraries/dph/dph-prim-par/ghc.mk Creating libraries/dph/dph-lifted-base/ghc.mk Creating libraries/dph/dph-lifted-boxed/ghc.mk Creating libraries/dph/dph-lifted-copy/ghc.mk Creating libraries/dph/dph-lifted-vseg/ghc.mk Creating libraries/filepath/ghc.mk Creating libraries/ghc-boot/ghc.mk Creating libraries/ghc-boot-th/ghc.mk Creating libraries/ghc-compact/ghc.mk Creating libraries/ghc-prim/ghc.mk Creating libraries/ghci/ghc.mk Creating libraries/haskeline/ghc.mk Creating libraries/hoopl/ghc.mk Creating libraries/hpc/ghc.mk Creating libraries/integer-gmp/ghc.mk Creating libraries/integer-simple/ghc.mk Creating libraries/mtl/ghc.mk Creating libraries/parallel/ghc.mk Creating libraries/parsec/ghc.mk Creating libraries/pretty/ghc.mk Creating libraries/primitive/ghc.mk Creating libraries/process/ghc.mk Creating libraries/random/ghc.mk Creating libraries/stm/ghc.mk Creating libraries/template-haskell/ghc.mk Creating libraries/terminfo/ghc.mk Creating libraries/text/ghc.mk Creating libraries/time/ghc.mk Creating libraries/transformers/ghc.mk Creating libraries/unix/ghc.mk Creating libraries/vector/ghc.mk Creating libraries/Win32/ghc.mk Creating libraries/xhtml/ghc.mk Booting . Booting libraries/base/ Booting libraries/directory/ Booting libraries/integer-gmp/ Booting libraries/process/ Booting libraries/terminfo/ Booting libraries/time/ Booting libraries/unix/ checking for gfind... no checking for find... /usr/bin/find checking for sort... /usr/bin/sort checking for GHC version date... inferred 8.3.20171004 checking for GHC Git commit id... inferred 3030eee24c9d538f7ae2c854fd86129563b6ddf3 checking for ghc... /c/fp/ghc-8.0.2/bin/ghc checking version of ghc... 8.0.2 GHC path canonicalised to: c:/fp/ghc-8.0.2/bin/ghc checking build system type... x86_64-pc-msys checking host system type... x86_64-pc-msys checking target system type... x86_64-pc-msys Build platform inferred as: x86_64-unknown-mingw32 Host platform inferred as: x86_64-unknown-mingw32 Target platform inferred as: x86_64-unknown-mingw32 Unknown OS msys /c/code/HEAD$ git pull Already up-to-date. /c/code/HEAD$ git submodule update /c/code/HEAD$ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: More windows
This looks like a file lock issue. Just to double check, but do you have the build folder excluded from the antivirus scanner? On Wed, Oct 4, 2017, 13:57 Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote: > Now in my Windows build, staring with “sh validate –fast –no-clean” I get > > [230 of 232] Compiling Distribution.PackageDescription.Parsec ( > libraries\Cabal\Cabal\Distribution\PackageDescription\Parsec.hs, > bootstrapping\Distribution\PackageDescription\Parsec.o ) > > [231 of 232] Compiling Distribution.Simple ( > libraries\Cabal\Cabal\Distribution\Simple.hs, > bootstrapping\Distribution\Simple.o ) > > [232 of 232] Compiling Main ( utils\ghc-cabal\Main.hs, > bootstrapping\Main.o ) > > Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ... > > "inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe > > Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe > > utils/genprimopcode/ghc.mk:19: utils/genprimopcode/dist/package-data.mk: > No such file or directory > > make[1]: *** [utils/ghc-cabal/ghc.mk:57: > utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1 > > make[1]: *** Deleting file 'utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe' > > make: *** [Makefile:123: all] Error 2 > > > > Simply repeating, thus “sh validate –fast”, I then get the same error > > /c/code/HEAD$ ls -l utils/ghc-cabal/dist/build/tmp/ > > total 0 > > /c/code/HEAD$ sh validate --fast --no-clean > > using THREADS=5 > > make: Entering directory '/c/code/HEAD/utils/checkUniques' > > ./check-uniques.py ../.. > > make: Leaving directory '/c/code/HEAD/utils/checkUniques' > > ===--- building phase 0 > > make --no-print-directory -f ghc.mk phase=0 phase_0_builds > > "c:/fp/ghc-8.0.2/bin/ghc.exe" -O0 -H64m -Wall \ > >-optc-Wall -optc-Werror -optc-fno-stack-protector \ > > \ > >-hide-all-packages \ > >-package ghc-prim -package base -package array -package > transformers -package time -package containers -package bytestring -package > deepseq -package process -package pretty -package directory -package Win32 \ > >--make utils/ghc-cabal/Main.hs -o > utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe \ > >-no-user-package-db \ > >-Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \ > >-DCABAL_VERSION=2,0,0,2 \ > >-DCABAL_PARSEC \ > >-DBOOTSTRAPPING \ > >-odir bootstrapping \ > >-hidir bootstrapping \ > >bootstrapping/Cabal/Distribution/Parsec/Lexer.hs \ > >-ilibraries/Cabal/Cabal \ > >-ilibraries/binary/src \ > >-ilibraries/filepath \ > >-ilibraries/hpc \ > >-ilibraries/mtl \ > >-ilibraries/text \ > >libraries/text/cbits/cbits.c \ > >-Ilibraries/text/include \ > >-ilibraries/parsec \ > > \ > > > > Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ... > > "inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe > > Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe > > make[1]: *** [utils/ghc-cabal/ghc.mk:57: > utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1 > > make[1]: *** Deleting file 'utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe' > > make: *** [Makefile:123: all] Error 2 > > > > But trying “sh validate –fast” once more succeeds: > > /c/code/HEAD$ sh validate --fast --no-clean > > using THREADS=5 > > make: Entering directory '/c/code/HEAD/utils/checkUniques' > > ./check-uniques.py ../.. > > make: Leaving directory '/c/code/HEAD/utils/checkUniques' > > ===--- building phase 0 > > make --no-print-directory -f ghc.mk phase=0 phase_0_builds > > "c:/fp/ghc-8.0.2/bin/ghc.exe" -O0 -H64m -Wall \ > >-optc-Wall -optc-Werror -optc-fno-stack-protector \ > > \ > >-hide-all-packages \ > >-package ghc-prim -package base -package array -package > transformers -package time -package containers -package bytestring -package > deepseq -package process -package pretty -package directory -package Win32 \ > >--make utils/ghc-cabal/Main.hs -o > utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe \ > >-no-user-package-db \ > >-Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \ > >-DCABAL_VERSION=2,0,0,2 \ > >-DCABAL_PARSEC \ > >-DBOOTSTRAPPING \ > >-odir bootstrapping \ > >-hidir bootstrapping \ > >
RE: More windows
As you’ll see the directory is empty when the crash happens. And yes the folder is excluded. Also this behaviour is new. Simon From: Phyx [mailto:loneti...@gmail.com] Sent: 04 October 2017 14:17 To: Simon Peyton Jones ; ghc-devs@haskell.org Subject: Re: More windows This looks like a file lock issue. Just to double check, but do you have the build folder excluded from the antivirus scanner? On Wed, Oct 4, 2017, 13:57 Simon Peyton Jones via ghc-devs mailto:ghc-devs@haskell.org>> wrote: Now in my Windows build, staring with “sh validate –fast –no-clean” I get [230 of 232] Compiling Distribution.PackageDescription.Parsec ( libraries\Cabal\Cabal\Distribution\PackageDescription\Parsec.hs, bootstrapping\Distribution\PackageDescription\Parsec.o ) [231 of 232] Compiling Distribution.Simple ( libraries\Cabal\Cabal\Distribution\Simple.hs, bootstrapping\Distribution\Simple.o ) [232 of 232] Compiling Main ( utils\ghc-cabal\Main.hs, bootstrapping\Main.o ) Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ... "inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe utils/genprimopcode/ghc.mk:19<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk%3A19&data=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281&sdata=RBB0ZLl%2FEYwO7EfcTXr%2FKugBfnr1ecN%2Febs0rAKu1VE%3D&reserved=0>: utils/genprimopcode/dist/package-data.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpackage-data.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281&sdata=QeEhyXBxi5n%2FhisTO6hX309ZFk47ek5NtGVDBNKbWLY%3D&reserved=0>: No such file or directory make[1]: *** [utils/ghc-cabal/ghc.mk:57<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk%3A57&data=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281&sdata=8qZlM0TvQvcySuregiRG5Ip%2FOR%2BVDAM6Dad1hUNEB%2FQ%3D&reserved=0>: utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1 make[1]: *** Deleting file 'utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe' make: *** [Makefile:123: all] Error 2 Simply repeating, thus “sh validate –fast”, I then get the same error /c/code/HEAD$ ls -l utils/ghc-cabal/dist/build/tmp/ total 0 /c/code/HEAD$ sh validate --fast --no-clean using THREADS=5 make: Entering directory '/c/code/HEAD/utils/checkUniques' ./check-uniques.py ../.. make: Leaving directory '/c/code/HEAD/utils/checkUniques' ===--- building phase 0 make --no-print-directory -f ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281&sdata=npxwtvhNnwLposvw%2B3k6rdhcQHEW7erd10hWCi5bvjg%3D&reserved=0> phase=0 phase_0_builds "c:/fp/ghc-8.0.2/bin/ghc.exe" -O0 -H64m -Wall \ -optc-Wall -optc-Werror -optc-fno-stack-protector \ \ -hide-all-packages \ -package ghc-prim -package base -package array -package transformers -package time -package containers -package bytestring -package deepseq -package process -package pretty -package directory -package Win32 \ --make utils/ghc-cabal/Main.hs -o utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe \ -no-user-package-db \ -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \ -DCABAL_VERSION=2,0,0,2 \ -DCABAL_PARSEC \ -DBOOTSTRAPPING \ -odir bootstrapping \ -hidir bootstrapping \ bootstrapping/Cabal/Distribution/Parsec/Lexer.hs \ -ilibraries/Cabal/Cabal \ -ilibraries/binary/src \ -ilibraries/filepath \ -ilibraries/hpc \ -ilibraries/mtl \ -ilibraries/text \ libraries/text/cbits/cbits.c \ -Ilibraries/text/include \ -ilibraries/parsec \ \ Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ... "inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe make[1]: *** [utils/ghc-cabal/ghc.mk:57<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk%3A57&data=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281&sdata=8qZlM0TvQvcySuregiRG5Ip%2FOR%2BVDAM6Dad1hUNEB%2FQ%3D&reserved=0>: utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1 make[1]: *** Deleting file 'utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe' make: *** [Makefile:123: all] Error 2 But trying “sh validate –f
Re: More windows
Oh sorry, I missed the ls line, I'll try building master. On Wed, Oct 4, 2017 at 5:24 PM, Simon Peyton Jones wrote: > As you’ll see the directory is empty when the crash happens. And yes the > folder is excluded. > > > > Also this behaviour is new. > > > > Simon > > > > *From:* Phyx [mailto:loneti...@gmail.com] > *Sent:* 04 October 2017 14:17 > *To:* Simon Peyton Jones ; ghc-devs@haskell.org > *Subject:* Re: More windows > > > > This looks like a file lock issue. Just to double check, but do you have > the build folder excluded from the antivirus scanner? > > > > On Wed, Oct 4, 2017, 13:57 Simon Peyton Jones via ghc-devs < > ghc-devs@haskell.org> wrote: > > Now in my Windows build, staring with “sh validate –fast –no-clean” I get > > [230 of 232] Compiling Distribution.PackageDescription.Parsec ( > libraries\Cabal\Cabal\Distribution\PackageDescription\Parsec.hs, > bootstrapping\Distribution\PackageDescription\Parsec.o ) > > [231 of 232] Compiling Distribution.Simple ( > libraries\Cabal\Cabal\Distribution\Simple.hs, > bootstrapping\Distribution\Simple.o ) > > [232 of 232] Compiling Main ( utils\ghc-cabal\Main.hs, > bootstrapping\Main.o ) > > Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ... > > "inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe > > Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe > > utils/genprimopcode/ghc.mk:19 > <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk%3A19&data=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281&sdata=RBB0ZLl%2FEYwO7EfcTXr%2FKugBfnr1ecN%2Febs0rAKu1VE%3D&reserved=0>: > utils/genprimopcode/dist/package-data.mk > <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpackage-data.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281&sdata=QeEhyXBxi5n%2FhisTO6hX309ZFk47ek5NtGVDBNKbWLY%3D&reserved=0>: > No such file or directory > > make[1]: *** [utils/ghc-cabal/ghc.mk:57 > <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk%3A57&data=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281&sdata=8qZlM0TvQvcySuregiRG5Ip%2FOR%2BVDAM6Dad1hUNEB%2FQ%3D&reserved=0>: > utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1 > > make[1]: *** Deleting file 'utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe' > > make: *** [Makefile:123: all] Error 2 > > > > Simply repeating, thus “sh validate –fast”, I then get the same error > > /c/code/HEAD$ ls -l utils/ghc-cabal/dist/build/tmp/ > > total 0 > > /c/code/HEAD$ sh validate --fast --no-clean > > using THREADS=5 > > make: Entering directory '/c/code/HEAD/utils/checkUniques' > > ./check-uniques.py ../.. > > make: Leaving directory '/c/code/HEAD/utils/checkUniques' > > ===--- building phase 0 > > make --no-print-directory -f ghc.mk > <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281&sdata=npxwtvhNnwLposvw%2B3k6rdhcQHEW7erd10hWCi5bvjg%3D&reserved=0> > phase=0 phase_0_builds > > "c:/fp/ghc-8.0.2/bin/ghc.exe" -O0 -H64m -Wall \ > >-optc-Wall -optc-Werror -optc-fno-stack-protector \ > > \ > >-hide-all-packages \ > >-package ghc-prim -package base -package array -package > transformers -package time -package containers -package bytestring -package > deepseq -package process -package pretty -package directory -package Win32 \ > >--make utils/ghc-cabal/Main.hs -o > utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe > \ > >-no-user-package-db \ > >-Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \ > >-DCABAL_VERSION=2,0,0,2 \ > >-DCABAL_PARSEC \ > >-DBOOTSTRAPPING \ > >-odir bootstrapping \ > >-hidir bootstrapping \ > >bootstrapping/Cabal/Distribution/Parsec/Lexer.hs \ > >-ilibraries/Cabal/Cabal \ > >-ilibraries/binary/src \ > >-ilibraries/filepath \ > >-ilibraries/hpc \ > >-ilibraries/mtl \ > >-ilibraries/text \ > >libraries/text/cbits/cbits.c \ > >-Ilibraries/text/include \ > >-ilibraries/parsec \ > > \ > >
RE: More windows
Any ideas anyone? When I restart the build, it gets past the blockage (which seems highly specific). But it’s jolly annoying. Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Simon Peyton Jones via ghc-devs Sent: 04 October 2017 17:25 To: Phyx ; ghc-devs@haskell.org Subject: RE: More windows As you’ll see the directory is empty when the crash happens. And yes the folder is excluded (from virus checking). Also this behaviour is new. Simon From: Phyx [mailto:loneti...@gmail.com] Sent: 04 October 2017 14:17 To: Simon Peyton Jones mailto:simo...@microsoft.com>>; ghc-devs@haskell.org<mailto:ghc-devs@haskell.org> Subject: Re: More windows This looks like a file lock issue. Just to double check, but do you have the build folder excluded from the antivirus scanner? On Wed, Oct 4, 2017, 13:57 Simon Peyton Jones via ghc-devs mailto:ghc-devs@haskell.org>> wrote: Now in my Windows build, staring with “sh validate –fast –no-clean” I get [230 of 232] Compiling Distribution.PackageDescription.Parsec ( libraries\Cabal\Cabal\Distribution\PackageDescription\Parsec.hs, bootstrapping\Distribution\PackageDescription\Parsec.o ) [231 of 232] Compiling Distribution.Simple ( libraries\Cabal\Cabal\Distribution\Simple.hs, bootstrapping\Distribution\Simple.o ) [232 of 232] Compiling Main ( utils\ghc-cabal\Main.hs, bootstrapping\Main.o ) Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ... "inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe utils/genprimopcode/ghc.mk:19<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk%3A19&data=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281&sdata=RBB0ZLl%2FEYwO7EfcTXr%2FKugBfnr1ecN%2Febs0rAKu1VE%3D&reserved=0>: utils/genprimopcode/dist/package-data.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpackage-data.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281&sdata=QeEhyXBxi5n%2FhisTO6hX309ZFk47ek5NtGVDBNKbWLY%3D&reserved=0>: No such file or directory make[1]: *** [utils/ghc-cabal/ghc.mk:57<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk%3A57&data=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281&sdata=8qZlM0TvQvcySuregiRG5Ip%2FOR%2BVDAM6Dad1hUNEB%2FQ%3D&reserved=0>: utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1 make[1]: *** Deleting file 'utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe' make: *** [Makefile:123: all] Error 2 Simply repeating, thus “sh validate –fast”, I then get the same error /c/code/HEAD$ ls -l utils/ghc-cabal/dist/build/tmp/ total 0 /c/code/HEAD$ sh validate --fast --no-clean using THREADS=5 make: Entering directory '/c/code/HEAD/utils/checkUniques' ./check-uniques.py ../.. make: Leaving directory '/c/code/HEAD/utils/checkUniques' ===--- building phase 0 make --no-print-directory -f ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281&sdata=npxwtvhNnwLposvw%2B3k6rdhcQHEW7erd10hWCi5bvjg%3D&reserved=0> phase=0 phase_0_builds "c:/fp/ghc-8.0.2/bin/ghc.exe" -O0 -H64m -Wall \ -optc-Wall -optc-Werror -optc-fno-stack-protector \ \ -hide-all-packages \ -package ghc-prim -package base -package array -package transformers -package time -package containers -package bytestring -package deepseq -package process -package pretty -package directory -package Win32 \ --make utils/ghc-cabal/Main.hs -o utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe \ -no-user-package-db \ -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \ -DCABAL_VERSION=2,0,0,2 \ -DCABAL_PARSEC \ -DBOOTSTRAPPING \ -odir bootstrapping \ -hidir bootstrapping \ bootstrapping/Cabal/Distribution/Parsec/Lexer.hs \ -ilibraries/Cabal/Cabal \ -ilibraries/binary/src \ -ilibraries/filepath \ -ilibraries/hpc \ -ilibraries/mtl \ -ilibraries/text \ libraries/text/cbits/cbits.c \ -Ilibraries/text/include \ -ilibraries/parsec \ \ Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ... "inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe make[1]: *** [utils/ghc-cabal/ghc.mk:57<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgh
RE: More windows
Simon Peyton Jones via ghc-devs writes: > Any ideas anyone? When I restart the build, it gets past the blockage > (which seems highly specific). But it’s jolly annoying. > Hi Simon, Perhaps let's try this, 1. download and run the procmon tool from [1] 2. from the "Filter" menu select the "Filter..." option 3. select "Path" in the first drop-down 4. select "contains" in the second drop-down 5. enter "ghc-cabal.exe" in the third text box 6. select "Include in the fourth drop-down 8. click the "Add" button 7. click the "Ok" button Now you should be logging events pertaining to the file in question. Now simply run `./validate` to try to reproduce the issue. With luck this will produce a handful of events, some of which ought to point to the process that it responsible for meddling with the GHC build. Now export this log, 1. select "Save" from the "File" menu 2. select the "Events displayed using current filter" option 3. select the "CSV" format, select a path that will be easy to file 4. return this file to me (perhaps via GitHub Gist [2]?) Hopefully this will give us some insight into what is happening. Cheers, - Ben [1] https://docs.microsoft.com/en-us/sysinternals/downloads/procmon [2] https://gist.github.com/ signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: More windows
Oddly it's started working. I have no idea why. I'll yell if it breaks again. Simon | -Original Message- | From: Ben Gamari [mailto:b...@well-typed.com] | Sent: 11 October 2017 14:11 | To: Simon Peyton Jones via ghc-devs ; Simon Peyton | Jones ; GHC developers | Subject: RE: More windows | | Simon Peyton Jones via ghc-devs writes: | | > Any ideas anyone? When I restart the build, it gets past the blockage | > (which seems highly specific). But it’s jolly annoying. | > | Hi Simon, | | Perhaps let's try this, | | 1. download and run the procmon tool from [1] | 2. from the "Filter" menu select the "Filter..." option | 3. select "Path" in the first drop-down | 4. select "contains" in the second drop-down | 5. enter "ghc-cabal.exe" in the third text box | 6. select "Include in the fourth drop-down | 8. click the "Add" button | 7. click the "Ok" button | | Now you should be logging events pertaining to the file in question. Now | simply run `./validate` to try to reproduce the issue. | | With luck this will produce a handful of events, some of which ought to | point to the process that it responsible for meddling with the GHC | build. | | Now export this log, | | 1. select "Save" from the "File" menu | 2. select the "Events displayed using current filter" option | 3. select the "CSV" format, select a path that will be easy to file | 4. return this file to me (perhaps via GitHub Gist [2]?) | | Hopefully this will give us some insight into what is happening. | | Cheers, | | - Ben | | | [1] https://docs.microsoft.com/en-us/sysinternals/downloads/procmon | [2] https://gist.github.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: More windows
Hi Simon, Hmm I'm not sure about replacing sh with bash. I think bash has some Non-POSIX extensions that may affect the behavior of valid posix scripts. Is bash --login slow as well? How about once sh or bash starts, are commands still slow then? I assume your computer is domain joined and you may be hitting a very long standing issue with certain domain joined machines https://github.com/Alexpux/MSYS2-packages/issues/138#issuecomment-70813762 The solution seems to be to cache the user info locally instead of it having to query the domain controller everytime. See solution 2 here https://gist.github.com/k-takata/9b8d143f0f3fef5abdab for instructions Does that help the problem? I believe you had a similar problem last time setting up a new machine. At that time magit was also slow. Kind regards, Tamar On Mon, Apr 2, 2018, 23:23 Simon Peyton Jones wrote: > Tamar > > I’ve noticed that “sh” (which is invoked at lot by make etc) takes AGES to > start up. At least I think it’s ‘sh’ that is causing the delay. > > I think it’s c:/msys64/usr/bin/sh.exe > > From searching the web (eg > https://www2.cs.duke.edu/csl/docs/unix_course/intro-60.html) it seems > likely that it executes c:/msys64/etc/profile first. > > And If I put an ‘echo’ at the start and end of that file, they do seem to > take place with a significant gap between them. > > I have not started sprinkling more echos, but does that ring any bells? > > Can I replace ‘sh’ with c:/msys64/usr/bin/bash.exe, which seems to be > faster? (My evnt variable SHELL already points to bash.exe. ) And if so, > how would I do that? An environment variable. Physically copy bash.exe to > sh.exe? Or what? > > Thanks > > Simon > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: More windows
The solution seems to be to cache the user info locally instead of it having to query the domain controller everytime. Ah yes: here’s a better expressed post: http://bjg.io/guide/cygwin-ad/ I did the following * commented out the “db” part for passwd and group in c:/msys64/etc/nsswitch.conf, to give this: # Begin /etc/nsswitch.conf passwd: files #db group: files #db db_enum: cache builtin db_home: windows db_shell: cygwin desc db_gecos: cygwin desc # End /etc/nsswitch.conf * Note that I also set db_home to ‘windows’, so that it gets my windows home directory. I think an explicit path would also be OK * However I discovered that having just “files” for “passwd” in nsswitch.conf means that ssh looks in c:/msys64/etc/passwd to find the home directory for .ssh, totally ignoring the $HOME environment variable, and ignoring the db_home setting. * But there IS no /etc/passwd file! So I created one mkpasswd -c > /etc/passwd mkgroup -c > /etc/group And then I manually edited /etc/passwd to put in the correct home directory. What a saga! Is it faster now? Hard to tell. Simon From: Phyx Sent: 03 April 2018 07:00 To: Simon Peyton Jones Cc: ghc-devs@haskell.org Subject: Re: More windows Hi Simon, Hmm I'm not sure about replacing sh with bash. I think bash has some Non-POSIX extensions that may affect the behavior of valid posix scripts. Is bash --login slow as well? How about once sh or bash starts, are commands still slow then? I assume your computer is domain joined and you may be hitting a very long standing issue with certain domain joined machines https://github.com/Alexpux/MSYS2-packages/issues/138#issuecomment-70813762<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAlexpux%2FMSYS2-packages%2Fissues%2F138%23issuecomment-70813762&data=02%7C01%7Csimonpj%40microsoft.com%7C185492e20be9494ebdf008d599282bcd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636583320164876915&sdata=MYHQSKqds%2FJXXEkX1jXF2psZmZntrrgtBqEUXtfGQBs%3D&reserved=0> The solution seems to be to cache the user info locally instead of it having to query the domain controller everytime. See solution 2 here https://gist.github.com/k-takata/9b8d143f0f3fef5abdab<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgist.github.com%2Fk-takata%2F9b8d143f0f3fef5abdab&data=02%7C01%7Csimonpj%40microsoft.com%7C185492e20be9494ebdf008d599282bcd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636583320164876915&sdata=Qb1BMV9NoSijP%2F%2F5e4ZNNJ%2FGHhMrGksFTM6eVRL4dQQ%3D&reserved=0> for instructions Does that help the problem? I believe you had a similar problem last time setting up a new machine. At that time magit was also slow. Kind regards, Tamar On Mon, Apr 2, 2018, 23:23 Simon Peyton Jones mailto:simo...@microsoft.com>> wrote: Tamar I’ve noticed that “sh” (which is invoked at lot by make etc) takes AGES to start up. At least I think it’s ‘sh’ that is causing the delay. I think it’s c:/msys64/usr/bin/sh.exe From searching the web (eg https://www2.cs.duke.edu/csl/docs/unix_course/intro-60.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww2.cs.duke.edu%2Fcsl%2Fdocs%2Funix_course%2Fintro-60.html&data=02%7C01%7Csimonpj%40microsoft.com%7C185492e20be9494ebdf008d599282bcd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636583320164876915&sdata=74ecRU4VAdzlHW1Tjul6VEqdxsEsnd7xBSYnMoYsqfg%3D&reserved=0>) it seems likely that it executes c:/msys64/etc/profile first. And If I put an ‘echo’ at the start and end of that file, they do seem to take place with a significant gap between them. I have not started sprinkling more echos, but does that ring any bells? Can I replace ‘sh’ with c:/msys64/usr/bin/bash.exe, which seems to be faster? (My evnt variable SHELL already points to bash.exe. ) And if so, how would I do that? An environment variable. Physically copy bash.exe to sh.exe? Or what? Thanks Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Windows testsuite failures
Hi Tamar The list of testsuite failure on Windows has grown quite long - see below. Most seem to concern plugins or linking. Do you know what is going on here? If they can't be fixed, can we mark them as expect_broken on Windows, so that it's easier (when developing) to know when I've introduced a regression. Currently I have to do a manual diff against a rather long list. Thanks! Simon SUMMARY for test run started at Thu Sep 20 00:13:20 2018 GMTST 1:03:11 spent to go through 6530 total tests, which gave rise to 18728 test cases, of which 12206 were skipped 33 had missing libraries 6278 expected passes 173 expected failures 9 caused framework failures 1 caused framework warnings 0 unexpected passes 31 unexpected failures 7 unexpected stat failures Unexpected failures: ghci/linking/dyn/T10955dyn.run T10955dyn [bad exit code] (normal) ghci/linking/dyn/T10955.run T10955 [bad stderr] (ghci) ghci/linking/dyn/T11072gcc.run T11072gcc [bad exit code] (normal) numeric/should_run/FloatFnInverses.run FloatFnInverses [bad stdout] (normal) plugins/T11244.run T11244 [bad stderr] (normal) plugins/plugin-recomp-change.runplugin-recomp-change [bad exit code] (normal) rts/T7040_ghci.run T7040_ghci [bad stdout] (ghci) rts/linker_unload.run linker_unload [bad exit code] (normal) rts/linker_error1.run linker_error1 [bad exit code] (normal) rts/linker_error2.run linker_error2 [bad exit code] (normal) rts/T12771/T12771.run T12771 [bad exit code] (normal) rts/T13082/T13082_good.run T13082_good [bad exit code] (normal) rts/T14611/T14611.run T14611 [bad exit code] (normal) simplCore/should_compile/T7702.run T7702 [exit code non-0] (normal) rts/T10672/T10672_x64.run T10672_x64 [bad exit code] (normal) libraries/Win32/tests/T4452.run T4452 [bad exit code] (normal) plugins/plugins01.run plugins01 [bad exit code] (normal) plugins/plugins07.run plugins07 [bad exit code] (normal) plugins/plugins09.run plugins09 [bad exit code] (normal) plugins/plugins11.run plugins11 [bad exit code] (normal) plugins/plugins12.run plugins12 [bad exit code] (normal) plugins/plugins13.run plugins13 [bad exit code] (normal) plugins/plugins14.run plugins14 [bad exit code] (normal) plugins/plugins15.run plugins15 [bad exit code] (normal) plugins/T10420.run T10420 [bad exit code] (normal) plugins/T10294.run T10294 [bad exit code] (normal) plugins/T10294a.run T10294a [bad exit code] (normal) plugins/T12567a.run T12567a [bad exit code] (normal) plugins/plugin-recomp-pure.run plugin-recomp-pure [bad exit code] (normal) plugins/plugin-recomp-impure.runplugin-recomp-impure [bad exit code] (normal) plugins/plugin-recomp-flags.run plugin-recomp-flags [bad exit code] (normal) Unexpected stat failures: perf/compiler/T9872d.run T9872d [stat not good enough] (normal) perf/compiler/T12425.run T12425 [stat not good enough] (optasm) perf/compiler/T12234.run T12234 [stat not good enough] (optasm) perf/compiler/T12150.run T12150 [stat not good enough] (optasm) perf/should_run/T15226.run T15226 [stat too good] (normal) perf/should_run/T15226a.run T15226a [stat too good] (normal) perf/compiler/MultiLayerModules.run MultiLayerModules [stat not good enough] (normal) Framework failures: ghci/linking/dyn/T10955.run T10955 [ghci] (pre_cmd failed: 2) plugins/T11244.runT11244 [normal] (pre_cmd failed: 2) plugins/plugin-recomp-change.run plugin-recomp-change [normal] (pre_cmd failed: 2) plugins/plugins07.run plugins07 [normal] (pre_cmd failed: 2) plugins/T10420.runT10420 [normal] (pre_cmd failed: 2) plugins/T10294a.run T10294a [normal] (pre_cmd failed: 2) plugins/plugin-recomp-pure.runplugin-recomp-pure [normal] (pre_cmd failed: 2) plugins/plugin-recomp-impure.run plugin-recomp-impure [normal] (pre_cmd failed: 2) plugins/plugin-recomp-flags.run plugin-recomp-flags [normal] (pre_cmd failed: 2) Framework warnings: . T13701 [numfield-no-expected] (No expected value found for bytes allocated in num_field check) ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Building on windows
Hi, I've tried to build ghc on windows 10 with msys. I've installed it with stack as said on the guide. In the msys shell, after updating and installing everything I've tried to run `./configure --enable-tarballs-autodownload` and got the following error: configure: loading site script /mingw64/etc/config.site checking for gfind... no checking for find... /usr/bin/find checking for sort... /usr/bin/sort checking for GHC version date... inferred 8.7.20181017 checking for GHC Git commit id... inferred 46f2906d1c6e1fb732a90882487479a2ebf19ca1 checking for ghc... no configure: error: GHC is required. I have the haskell platform installed (8.4.3), yet it can't find GHC and I'm not sure if I missed something from the guide Yotam ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Windows test failures
Ben, Phyx, and other CI folk 'sh validate -fast' still gives a lot of failures on Window. The output is below. I would be so good to get this to zero! (another minor thing is that it would be great to eliminate the long path at the beginning - this is platform independent - I have to delete manually many times each day. Thanks Simon Unexpected passes: /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/rts/T9405.run T9405 [unexpected] (normal) Unexpected failures: /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/driver/T14452.run T14452 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci/linking/ghcilink001.runghcilink001 [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci/prog010/ghci.prog010.run ghci.prog010 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci/scripts/ghci050.runghci050 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci/should_run/T14963a.run T14963a [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/print012.run print012 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/print016.run print016 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/break019.run break019 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/break028.run break028 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/dynbrk002.run dynbrk002 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/T2740.run T2740 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/indexed-types/should_fail/T7102a.runT7102a [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugin-recomp-change.runplugin-recomp-change [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/rts/T10672/T10672_x64.run T10672_x64 [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/th/TH_spliceGuard.run TH_spliceGuard [exit code non-0] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/th/TH_overlaps.run TH_overlaps [exit code non-0] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/th/T5886.runT5886 [exit code non-0] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/th/T10697_decided_3.run T10697_decided_3 [exit code non-0] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/th/T11629.run T11629 [exit code non-0] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/libraries/base/tests/T4006.run T4006 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/libraries/base/tests/IO/environment001.run environment001 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci/should_run/T15633b.run T15633b [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugins07.run plugins07 [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugins09.run plugins09 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugins10.run plugins10 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugins11.run plugins11 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/T10420.run T10420 [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugin-recomp-pure.run plugin-recomp-pure [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugin-recomp-impure.runplugin-recomp-impure [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugin-recomp-flags.run
Windows build broken -- again!
Aaargh! My windows build is, once again, broken. The error is below. Could whoever broke it please fix it? Something to do with "blocking_queue_hd" perhaps? Please. Thanks Simon rts\win32\AsyncIO.c: In function 'awaitRequests': rts\win32\AsyncIO.c:289:23: error: 'blocking_queue_hd' undeclared (first use in this function) rts\win32\AsyncIO.c:289:23: note: each undeclared identifier is reported only once for each function it appears in ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
