Re: Windows build broken again

[Ben Gamari]

Simon Peyton Jones via ghc-devs  writes:

> The Windows build is broken again.  Here's the tail of the log
>
Yes, I opened a ticket (#13375) about this earlier. Running,

"C:/msys64/home/ben/ghc/inplace/bin/ghc-pkg.exe" recache

is sufficient to work around the issue it seems.

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 build broken again

[lonetiger]

This last email was the first one I’ve received from you.

From: Ben Gamari
Sent: Tuesday, March 7, 2017 18:50
To: Phyx; David Macek; simo...@microsoft.com; ghc-devs@haskell.org
Subject: Re: Windows build broken again

Phyx <loneti...@gmail.com> writes:

> https://ghc.haskell.org/trac/ghc/ticket/13375
>
Are people not receiving my messages pointing out this ticket? I've
mentioned it twice now but I get the impression that these messages
aren't being seen.

Cheers,

- Ben


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Windows build broken again

[Ben Gamari]

Phyx  writes:

> https://ghc.haskell.org/trac/ghc/ticket/13375
>
Are people not receiving my messages pointing out this ticket? I've
mentioned it twice now but I get the impression that these messages
aren't being seen.

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 build broken again

[Ben Gamari]

Simon Peyton Jones via ghc-devs  writes:

> Windows build still broken.  Please please could someone fix?
> It's something to do with the testsuite Python script

This is #13375. I have a fix in D3289. It's currently validating.

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 build broken again

[Phyx]

https://ghc.haskell.org/trac/ghc/ticket/13375

On Tue, 7 Mar 2017, 08:05 David Macek,  wrote:

> On 4. 3. 2017 22:01, Simon Peyton Jones via ghc-devs wrote:
> > Exception: stderr from command:
> ['"/c/code/HEAD/inplace/bin/ghc-pkg.exe"', 'dump']
>
> Pinpointing the failure. I guess `ghc-pkg dump` is not supposed to write
> to stderr, but it does. Unfortunately, the test driver doesn't seem to tell
> us what's the error from ghc-pkg.
>
> --
> David Macek
>
> ___
> 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 broken again

[David Macek]

On 4. 3. 2017 22:01, Simon Peyton Jones via ghc-devs wrote:
> Exception: stderr from command: ['"/c/code/HEAD/inplace/bin/ghc-pkg.exe"', 
> 'dump']

Pinpointing the failure. I guess `ghc-pkg dump` is not supposed to write to 
stderr, but it does. Unfortunately, the test driver doesn't seem to tell us 
what's the error from ghc-pkg.

-- 
David Macek



smime.p7s
Description: S/MIME Cryptographic Signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Windows build broken again

[Simon Peyton Jones via ghc-devs]

Windows build still broken.  Please please could someone fix?
It's something to do with the testsuite Python script
Thanks
Simo[n

From: Simon Peyton Jones
Sent: 04 March 2017 21:01
To: ghc-devs@haskell.org
Subject: Windows build broken again

The Windows build is broken again.  Here's the tail of the log

It would be good if we could stop this happening

Simon

== End post-build package check

make: Entering directory '/c/code/HEAD/testsuite/tests'

WARNING: cache is out of date: 
C:\code\HEAD\inplace\lib\package.conf.d\package.cache

ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.

WARNING: cache is out of date: 
C:\code\HEAD\inplace\lib\package.conf.d\package.cache

ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.

"/c/code/HEAD/inplace/bin/ghc-stage2.exe" --make -o ../mk/ghc-config 
../mk/ghc-config.hs

[1 of 1] Compiling Main ( ..\mk\ghc-config.hs, ..\mk\ghc-config.o )

Linking ../mk/ghc-config.exe ...

../mk/ghc-config "/c/code/HEAD/inplace/bin/ghc-stage2.exe" 
>"../mk/ghcconfig_c_code_HEAD_inplace_bin_ghc-stage2.exe.mk"; if [ $? != 0 ]; 
then rm -f "../mk/ghcconfig_c_code_HEAD_inplace_bin_ghc-stage2.exe.mk"; exit 1; 
fi

WARNING: cache is out of date: 
C:\code\HEAD\inplace\lib\package.conf.d\package.cache

ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.

WARNING: cache is out of date: 
C:\code\HEAD\inplace\lib\package.conf.d\package.cache

ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.

# See Note [validate and testsuite speed] in toplevel Makefile.

make SPEED=2

make[1]: Entering directory '/c/code/HEAD/testsuite/tests'

WARNING: cache is out of date: 
C:\code\HEAD\inplace\lib\package.conf.d\package.cache

ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.

WARNING: cache is out of date: 
C:\code\HEAD\inplace\lib\package.conf.d\package.cache

ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.

Looks like you don't have timeout, building it first...

make -C ../timeout all

make[2]: Entering directory '/c/code/HEAD/testsuite/timeout'

rm -f -f TimeMe.o TimeMe.hi TimeMe TimeMe.exe

python3 calibrate '' > calibrate.out

rm -rf install-inplace

'/c/code/HEAD/inplace/bin/ghc-stage2.exe' --make Setup

[1 of 1] Compiling Main ( Setup.hs, Setup.o )

Linking Setup.exe ...

./Setup configure --with-compiler='/c/code/HEAD/inplace/bin/ghc-stage2.exe' \

  --with-hc-pkg='/c/code/HEAD/inplace/bin/ghc-pkg.exe' \

  --with-hsc2hs='/c/code/HEAD/inplace/bin/hsc2hs.exe' \

   \

  --ghc-option=-threaded 
--prefix='/c/code/HEAD/testsuite/timeout/install-inplace'

Configuring timeout-1...

./Setup build

Preprocessing executable 'timeout' for timeout-1..

Building executable 'timeout' for timeout-1..

[1 of 2] Compiling WinCBindings ( 
dist\build\timeout\timeout-tmp\WinCBindings.hs, 
dist\build\timeout\timeout-tmp\WinCBindings.o )

[2 of 2] Compiling Main ( timeout.hs, 
dist\build\timeout\timeout-tmp\Main.o )

Linking dist\build\timeout\timeout.exe ...

./Setup install

Installing executable timeout in 
C:/code/HEAD/testsuite/timeout/install-inplace\bin

Warning: The directory C:/code/HEAD/testsuite/timeout/install-inplace\bin is

not in the system search path.

make[2]: Leaving directory '/c/code/HEAD/testsuite/timeout'

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 
-fdiagnostics-color=never -fno-diagnostics-show-caret -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 --threads=5 -e 
config.cleanup=True -e config.local=False --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" 
--summary-file "../../testsuite_summary.txt" --no-print-summary 1   

Re: Windows build broken -- again

[Ben Gamari]

Simon Peyton Jones via ghc-devs  writes:

> Sigh.  The Simon PJ Windows Buildbot reports
>
Yes, my apologies for this one. I'm currently in the process of getting
this one fixed in D2700. Unfortunately my own Windows machine is having
hardware issues so I progress has been a bit slow. I hope to have a
functional fix by the end of the day.

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 build broken -- again

[Erik de Castro Lopo]

Simon Peyton Jones via ghc-devs wrote:

> In file included from rts\CheckUnload.c:16:0: error:
> 
> 
> 
> rts\LinkerInternals.h:284:15: error:
> 
>  error: unknown type name 'UChar'
> 
>  STATIC_INLINE UChar *

There's a patch up on Phab that should fix that:

https://phabricator.haskell.org/D2700

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Windows build broken again: urgent

[Simon Peyton Jones]

|  Just a hunch... could it have been broken by one of the recent linker-
|  related patches since Nov 24th?

That seems very plausible, yes.  But still there's the question of what to do 
about it.

Simon

|  -Original Message-
|  From: Herbert Valerio Riedel [mailto:hvrie...@gmail.com]
|  Sent: 01 December 2014 08:37
|  To: Simon Peyton Jones
|  Subject: Re: Windows build broken again: urgent
|  
|  On 2014-12-01 at 09:31:51 +0100, Simon Peyton Jones wrote:
|   Alas.  Alack.  The Windows build is broken again.
|   This time it's pretty fundamental: the stage2 compiler seg-faults
|  every time it invokes the linker:
|  
|   *On GHCi startup
|  
|   *On every Template Haskell splice
|  
|   I don't know when this started, but I did a successful build at
|  23.10 on 24 November, so it's during the last week.
|   I would gladly do any experiments if someone tells me what to do.
|   It would be really good to fix this.  At the moment I'm pretty much
|  stalled on laptop work.
|  
|  Just a hunch... could it have been broken by one of the recent linker-
|  related patches since Nov 24th?

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Windows build broken again: urgent

[Herbert Valerio Riedel]

Hello Simon,

On 2014-12-01 at 09:38:37 +0100, Simon Peyton Jones wrote:
 |  Just a hunch... could it have been broken by one of the recent linker-
 |  related patches since Nov 24th?

 That seems very plausible, yes.  But still there's the question of
 what to do about it.

 a) Empirically: Try locally 'git revert'ing

 383733b9191a36e2d3f757700842dbc3855911d9 

 and/or

 b5e8b3b162b3ff15ae6caf1afc659565365f54a8

 and see if your problem goes away, or

 b) Ask Simon Marlow (he either wrote or reviewed those two patches) if
he sees something odd in those patches that could have broken
Windows' GHCi...

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Windows build broken again: urgent

[Johan Tibell]

In general I think a good course of action when this happens is:

* Use git bisect to find the offending commit. This works now because we
moved to submodules.
* Revert the commit.
* Push the patch to master and notify the author.

This style of early rollback will become more important as we grow as it
puts the onus on fixing on the right person and minimizes negative impact
on other developers.
On Dec 1, 2014 9:43 AM, Herbert Valerio Riedel hvrie...@gmail.com wrote:

 Hello Simon,

 On 2014-12-01 at 09:38:37 +0100, Simon Peyton Jones wrote:
  |  Just a hunch... could it have been broken by one of the recent linker-
  |  related patches since Nov 24th?
 
  That seems very plausible, yes.  But still there's the question of
  what to do about it.

  a) Empirically: Try locally 'git revert'ing

  383733b9191a36e2d3f757700842dbc3855911d9

  and/or

  b5e8b3b162b3ff15ae6caf1afc659565365f54a8

  and see if your problem goes away, or

  b) Ask Simon Marlow (he either wrote or reviewed those two patches) if
 he sees something odd in those patches that could have broken
 Windows' GHCi...

 Cheers,
   hvr
 ___
 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 broken again: urgent

[Simon Peyton Jones]

Indeed.  But each bisect takes quite a while.  So my attention switches and it 
takes a while to get back.  I was hoping some machine might do it for me.

Herbert suggested some commits to revert. I’ll try that first

From: Johan Tibell [mailto:johan.tib...@gmail.com]
Sent: 01 December 2014 09:45
To: Herbert Valerio Riedel
Cc: ghc-devs@haskell.org; Simon Marlow; Simon Peyton Jones
Subject: Re: Windows build broken again: urgent


In general I think a good course of action when this happens is:

* Use git bisect to find the offending commit. This works now because we moved 
to submodules.
* Revert the commit.
* Push the patch to master and notify the author.

This style of early rollback will become more important as we grow as it puts 
the onus on fixing on the right person and minimizes negative impact on other 
developers.
On Dec 1, 2014 9:43 AM, Herbert Valerio Riedel 
hvrie...@gmail.commailto:hvrie...@gmail.com wrote:
Hello Simon,

On 2014-12-01 at 09:38:37 +0100, Simon Peyton Jones wrote:
 |  Just a hunch... could it have been broken by one of the recent linker-
 |  related patches since Nov 24th?

 That seems very plausible, yes.  But still there's the question of
 what to do about it.

 a) Empirically: Try locally 'git revert'ing

 383733b9191a36e2d3f757700842dbc3855911d9

 and/or

 b5e8b3b162b3ff15ae6caf1afc659565365f54a8

 and see if your problem goes away, or

 b) Ask Simon Marlow (he either wrote or reviewed those two patches) if
he sees something odd in those patches that could have broken
Windows' GHCi...

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.orgmailto: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 broken again: urgent

[Johan Tibell]

Yes, ideally this would have been caught by a Windows build bot.

On Mon, Dec 1, 2014 at 4:34 PM, Simon Peyton Jones simo...@microsoft.com
wrote:

  Indeed.  But each bisect takes quite a while.  So my attention switches
 and it takes a while to get back.  I was hoping some machine might do it
 for me.



 Herbert suggested some commits to revert. I’ll try that first



 *From:* Johan Tibell [mailto:johan.tib...@gmail.com]
 *Sent:* 01 December 2014 09:45
 *To:* Herbert Valerio Riedel
 *Cc:* ghc-devs@haskell.org; Simon Marlow; Simon Peyton Jones
 *Subject:* Re: Windows build broken again: urgent



 In general I think a good course of action when this happens is:

 * Use git bisect to find the offending commit. This works now because we
 moved to submodules.
 * Revert the commit.
 * Push the patch to master and notify the author.

 This style of early rollback will become more important as we grow as it
 puts the onus on fixing on the right person and minimizes negative impact
 on other developers.

 On Dec 1, 2014 9:43 AM, Herbert Valerio Riedel hvrie...@gmail.com
 wrote:

 Hello Simon,

 On 2014-12-01 at 09:38:37 +0100, Simon Peyton Jones wrote:
  |  Just a hunch... could it have been broken by one of the recent linker-
  |  related patches since Nov 24th?
 
  That seems very plausible, yes.  But still there's the question of
  what to do about it.

  a) Empirically: Try locally 'git revert'ing

  383733b9191a36e2d3f757700842dbc3855911d9

  and/or

  b5e8b3b162b3ff15ae6caf1afc659565365f54a8

  and see if your problem goes away, or

  b) Ask Simon Marlow (he either wrote or reviewed those two patches) if
 he sees something odd in those patches that could have broken
 Windows' GHCi...

 Cheers,
   hvr
 ___
 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 broken (again)

[Simon Peyton Jones]

yes it seems fine now, thanks.

Simon

From: Krzysztof Gogolewski [mailto:krz.gogolew...@gmail.com]
Sent: 03 October 2014 19:05
To: Herbert Valerio Riedel
Cc: Simon Peyton Jones; ghc-devs@haskell.org
Subject: Re: Windows build broken (again)

Python 3 is a likely culprit (though I couldn't confirm it), so I reverted it. 
Does it work now?

On Fri, Oct 3, 2014 at 5:51 PM, Herbert Valerio Riedel 
hvrie...@gmail.commailto:hvrie...@gmail.com wrote:
On 2014-10-03 at 17:29:31 +0200, Simon Peyton Jones wrote:
 Perhaps, yes, it is Python 3. I don't know.  Could someone revert to
 make it work again, please?

Fyi, I can't reproduce this specific problem on Cygwin at least (I don't
have any working pure Msys2 environment yet (still working on it), as
this may exactly be the kind of failure I'd expect Msys2 to be prone to
while Cygwin to be unaffected by).

What I tried in order to reproduce:

  $ git rev-parse HEAD
  084d241b316bfa12e41fc34cae993ca276bf0730  # -- this is the Py3/testsuite 
commit

  $ make TEST=tc012 WAY=normal
  ...
  = tc012(normal) 3039 of 4088 [0, 0, 0]
  cd ./typecheck/should_compile  
'C:/cygwin64/home/ghc/ghc-hvr/inplace/bin/ghc-stage2.exe' -fforce-recomp 
-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts 
-fno-ghci-history -c tc012.hs   -fno-warn-incomplete-patterns 
tc012.comp.stderr 21

  OVERALL SUMMARY for test run started at Fri Oct  3 15:42:04 2014 GMT
   0:00:03 spent to go through
  4088 total tests, which gave rise to
 12360 test cases, of which
 12359 were skipped

 0 had missing libraries
 1 expected passes
 0 expected failures
  ...


And btw, with the latest GHC HEAD commit (and I suspect the recent
HEAP_ALLOCED-related commits to be responsible for that), I get a ton of
testsuite failures due to such errors:

  T8639_api.exe: Unknown PEi386 section name `staticclosures' (while 
processing: 
C:\cygwin64\home\ghc\ghc-hvr\libraries\ghc-prim\dist-install\build\HSghcpr_BE58KUgBe9ELCsPXiJ1Q2r.o)

___
ghc-devs mailing list
ghc-devs@haskell.orgmailto: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 broken (again)

[Simon Peyton Jones]

Perhaps, yes, it is Python 3. I don't know.  Could someone revert to make it 
work again, please?

Simon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Simon Peyton 
Jones
Sent: 02 October 2014 21:40
To: ghc-devs@haskell.org
Subject: Windows build broken (again)

Sigh.  The testsuite fails utterly on Windows, with thousands of identical 
errors

= tc012(normal) 3039 of 4088 [1, 2677, 88]

cd .\typecheck\should_compile  '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 -c tc012.hs   -fno-warn-incomplete-patterns 
tc012.comp.stderr 21

sh: line 0: cd: .typecheckshould_compile: No such file or directory

Compile failed (status 256) errors were:

*** unexpected failure for tc012(normal)
Presumably this is some kind of Windows escape-character problem.  But it has 
worked fine for years, so what is going on?
It's very tiresome dealing with Windows breakage so frequently.   A few 
regression test failures, maybe, but outright breakage is very bad.
Simon


___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Windows build broken (again)

[Herbert Valerio Riedel]

On 2014-10-03 at 17:29:31 +0200, Simon Peyton Jones wrote:
 Perhaps, yes, it is Python 3. I don't know.  Could someone revert to
 make it work again, please?

Fyi, I can't reproduce this specific problem on Cygwin at least (I don't
have any working pure Msys2 environment yet (still working on it), as
this may exactly be the kind of failure I'd expect Msys2 to be prone to
while Cygwin to be unaffected by). 

What I tried in order to reproduce:

  $ git rev-parse HEAD
  084d241b316bfa12e41fc34cae993ca276bf0730  # -- this is the Py3/testsuite 
commit 

  $ make TEST=tc012 WAY=normal
  ...
  = tc012(normal) 3039 of 4088 [0, 0, 0] 
  cd ./typecheck/should_compile  
'C:/cygwin64/home/ghc/ghc-hvr/inplace/bin/ghc-stage2.exe' -fforce-recomp 
-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts 
-fno-ghci-history -c tc012.hs   -fno-warn-incomplete-patterns 
tc012.comp.stderr 21
   
  OVERALL SUMMARY for test run started at Fri Oct  3 15:42:04 2014 GMT
   0:00:03 spent to go through
  4088 total tests, which gave rise to
 12360 test cases, of which
 12359 were skipped
   
 0 had missing libraries
 1 expected passes
 0 expected failures
  ...


And btw, with the latest GHC HEAD commit (and I suspect the recent
HEAP_ALLOCED-related commits to be responsible for that), I get a ton of
testsuite failures due to such errors:

  T8639_api.exe: Unknown PEi386 section name `staticclosures' (while 
processing: 
C:\cygwin64\home\ghc\ghc-hvr\libraries\ghc-prim\dist-install\build\HSghcpr_BE58KUgBe9ELCsPXiJ1Q2r.o)

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Windows build broken (again)

[Krzysztof Gogolewski]

Python 3 is a likely culprit (though I couldn't confirm it), so I reverted
it. Does it work now?

On Fri, Oct 3, 2014 at 5:51 PM, Herbert Valerio Riedel hvrie...@gmail.com
wrote:

 On 2014-10-03 at 17:29:31 +0200, Simon Peyton Jones wrote:
  Perhaps, yes, it is Python 3. I don't know.  Could someone revert to
  make it work again, please?

 Fyi, I can't reproduce this specific problem on Cygwin at least (I don't
 have any working pure Msys2 environment yet (still working on it), as
 this may exactly be the kind of failure I'd expect Msys2 to be prone to
 while Cygwin to be unaffected by).

 What I tried in order to reproduce:

   $ git rev-parse HEAD
   084d241b316bfa12e41fc34cae993ca276bf0730  # -- this is the
 Py3/testsuite commit

   $ make TEST=tc012 WAY=normal
   ...
   = tc012(normal) 3039 of 4088 [0, 0, 0]
   cd ./typecheck/should_compile 
 'C:/cygwin64/home/ghc/ghc-hvr/inplace/bin/ghc-stage2.exe' -fforce-recomp
 -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts
 -fno-ghci-history -c tc012.hs   -fno-warn-incomplete-patterns
 tc012.comp.stderr 21

   OVERALL SUMMARY for test run started at Fri Oct  3 15:42:04 2014 GMT
0:00:03 spent to go through
   4088 total tests, which gave rise to
  12360 test cases, of which
  12359 were skipped

  0 had missing libraries
  1 expected passes
  0 expected failures
   ...


 And btw, with the latest GHC HEAD commit (and I suspect the recent
 HEAP_ALLOCED-related commits to be responsible for that), I get a ton of
 testsuite failures due to such errors:

   T8639_api.exe: Unknown PEi386 section name `staticclosures' (while
 processing:
 C:\cygwin64\home\ghc\ghc-hvr\libraries\ghc-prim\dist-install\build\HSghcpr_BE58KUgBe9ELCsPXiJ1Q2r.o)

 ___
 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 broken (again)

[Johan Tibell]

We need to get a windows build not up for phabricator that stops breaking
changes from getting submitted.
On Oct 2, 2014 10:40 PM, Simon Peyton Jones simo...@microsoft.com wrote:

  Sigh.  The testsuite fails utterly on Windows, with thousands of
 identical errors

 = tc012(normal) 3039 of 4088 [1, 2677, 88]

 cd .\typecheck\should_compile  '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 -c tc012.hs   -fno-warn-incomplete-patterns
 tc012.comp.stderr 21

 sh: line 0: cd: .typecheckshould_compile: No such file or directory

 Compile failed (status 256) errors were:

 *** unexpected failure for tc012(normal)

 Presumably this is some kind of Windows escape-character problem.  But it
 has worked fine for years, so what is going on?

 It’s very tiresome dealing with Windows breakage so frequently.   A few
 regression test failures, maybe, but outright breakage is very bad.

 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 broken (again)

[Brandon Allbery]

On Thu, Oct 2, 2014 at 4:39 PM, Simon Peyton Jones simo...@microsoft.com
wrote:

 Presumably this is some kind of Windows escape-character problem.  But it
 has worked fine for years, so what is going on?


At a guess, something that was using / is now using \ and getting eaten by
the shell. Or quoting that was preventing the \s from being eaten has been
lost somewhere.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Windows build broken -- again!

[Austin Seipp]

Thanks Niklas - this was an utter failure on my part. I'm not even
sure how this slipped in, but it was definitely my fault. Fixed in
6640635e6e2654f0acd8f10e0d02a8bd1c8296ff

On Tue, Jul 29, 2014 at 8:53 PM, Niklas Larsson metanik...@gmail.com wrote:
 Hi!

 Seems like it is the detabbing in commit 3021fb that has gone awry,
 blocked_queue_hd was renamed blocking_queue_hd in one place. I have attached
 a patch.

 I really need to set up a buildbot. Maybe if the weather gets worse.

 Niklas



 2014-07-30 0:37 GMT+02:00 Simon Peyton Jones simo...@microsoft.com:

 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



 ___
 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