Re: Windows build broken

Andreas Klebinger writes: > 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

RE: Windows build broken -- help!

I’ve pushed the commit. Thanks Doug! From: Douglas Wilson Sent: Wednesday, February 7, 2018 23:33 To: Simon Peyton Jones Cc: ghc-devs Subject: Re: Windows build broken -- help! Hi Simon, The first patch you quoted half-fixed this. the patch here: https://phabricator.haskell.org/D4392 should

Re: Windows build broken -- help!

Hi Simon, The first patch you quoted half-fixed this. the patch here: https://phabricator.haskell.org/D4392 should fix whole-fix it. (It at least validates green on windows) On Thu, Feb 8, 2018 at 12:18 PM, Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote: > PS Presumably it’s

RE: Windows build broken

From: Phyx [mailto:loneti...@gmail.com] Sent: 04 October 2017 13:30 To: Simon Peyton Jones <simo...@microsoft.com>; ghc-devs@haskell.org Subject: Re: Windows build broken Hi Simon, You seem to be in an msys shell instead of a mingw-64 shell (they have different startup shortcuts). We

Re: Windows build broken

Phyx writes: > Hi Simon, > > You seem to be in an msys shell instead of a mingw-64 shell (they have > different startup shortcuts). We don't support the msys shell as we only > want to compile for native windows. > > You should use the shortcut marked mingw-64. > >

Re: Windows build broken

Hi Simon, You seem to be in an msys shell instead of a mingw-64 shell (they have different startup shortcuts). We don't support the msys shell as we only want to compile for native windows. You should use the shortcut marked mingw-64. Alternatively to get you going in aclocal.m4 remove line

RE: Windows build failing in a new way

… .section .eh_frame,"a",@progbits Simon From: Phyx [mailto:loneti...@gmail.com] Sent: 09 March 2017 16:38 To: Simon Peyton Jones <simo...@microsoft.com>; ghc-devs@haskell.org Subject: Re: Windows build failing in a new way Hi Simon, As of this morning the Windows build was wor

RE: Windows build failing in a new way

Ben Gamari writes: > loneti...@gmail.com writes: > >> Ah great, >> >> Triples again.. I still wonder why it is suddenly an issue. We haven’t >> touched the .m4 file in a while and no one changed libffi either >> right? This is just like last time the normalization bit us.

RE: Windows build failing in a new way

loneti...@gmail.com writes: > Ah great, > > Triples again.. I still wonder why it is suddenly an issue. We haven’t > touched the .m4 file in a while and no one changed libffi either > right? This is just like last time the normalization bit us. Causing > days of broken builds on different targets

RE: Windows build failing in a new way

they were interested in. Why do we do the normalization? It doesn’t seem to give us any benefits at all.. Maybe we should stop doing it after the branch for 8.4? From: Ben Gamari Sent: Thursday, March 9, 2017 18:51 To: Phyx; Simon Peyton Jones; ghc-devs@haskell.org Subject: Re: Windows build failing

Re: Windows build failing in a new way

Phyx writes: > My CI server is also reproducing it while I also haven't been able to > locally. Weird indeed. > Ahhh, I just noticed that Reid stumbled upon the culprit yesterday. See [1]. Cheers, - Ben [1] https://phabricator.haskell.org/rGHCe901ed1c5d66 signature.asc

Re: Windows build failing in a new way

My CI server is also reproducing it while I also haven't been able to locally. Weird indeed. On Thu, 9 Mar 2017, 17:36 Ben Gamari, wrote: > Simon Peyton Jones via ghc-devs writes: > > > My windows build is more broken than usual. I can't even build

Re: Windows build failing in a new way

Simon Peyton Jones via ghc-devs writes: > My windows build is more broken than usual. I can't even build a GHC. > Please, could someone fix this? I'm getting desperate. This is very odd; Harbormaster is also seeing it but I've been unable to reproduce locally. It seems

Re: Windows build failing in a new way

Checking again, I think something else is wrong I'll have to check later. Sorry, but that commit above is still good. If you are really stuck use that one. Tamar On Thu, 9 Mar 2017, 17:11 Phyx, wrote: > That said, running the build on HEAD it seems that the template

Re: Windows build failing in a new way

That said, running the build on HEAD it seems that the template haskell stuff committed today has broken the build again. I'd suggest checking out the commit in my previous email which is just a few hours old. And cleaning ghc-tarballs. As the error you seem to be getting is local. On Thu, 9 Mar

Re: Windows build failing in a new way

Hi Simon, As of this morning the Windows build was working fine https://github.com/Mistuke/GhcWindowsBuild/commit/aa6906b2535224721d8b049cee3edcd938c3e951 those are my nightly logs for last night at commit a02b80f That error seems to be coming from gcc and not ghc. We did update the crt and

Re: Windows build broken again

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

RE: Windows build broken again

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/g

Re: Windows build broken again

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

RE: Windows build broken again

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:

Re: Windows build broken again

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

Re: Windows build broken again

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

RE: Windows build broken again

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

RE: Windows build broken

I can't fix that (no windows) but I just broke all the builds with a -Werror mistake and I can fix that one... David FeuerWell-Typed, LLP Original message From: Simon Peyton Jones via ghc-devs Date: 2/28/17 7:07 PM (GMT-05:00) To: ghc-devs@haskell.org

Re: Windows build broken

Please set your "time" submodule to the "ghc" branch. It should always represent a stable release. -- Ashley On Wed, 2017-02-22 at 14:13 +, Phyx wrote: > The package has been fixed already but the submodule hasn't been > updated. For a quick fix just cd into libraries/time and checkout >

RE: Windows build broken

. If someone felt able to step up to doing it, it'd be great. Simon | -Original Message- | From: Kosyrev Serge [mailto:skosy...@ptsecurity.com] | Sent: 22 February 2017 14:18 | To: Simon Peyton Jones <simo...@microsoft.com> | Subject: Re: Windows build broken | | Simon, | | It pa

RE: Windows build broken

Tonight is fine – thank you! From: Phyx [mailto:loneti...@gmail.com] Sent: 22 February 2017 14:47 To: Simon Peyton Jones <simo...@microsoft.com> Cc: ghc-devs@haskell.org Subject: Re: Windows build broken Head of ghc is broken not head of time. Ghc is currently set to 6e202ed while

Re: Windows build broken

; > > > Simon > > > > *From:* Phyx [mailto:loneti...@gmail.com] > *Sent:* 22 February 2017 14:14 > *To:* Simon Peyton Jones <simo...@microsoft.com>; ghc-devs@haskell.org > *Cc:* Ashley Yakeley <ash...@semantic.org> > *Subject:* Re: Windows build broken

RE: Windows build broken

;; ghc-devs@haskell.org Cc: Ashley Yakeley <ash...@semantic.org> Subject: Re: Windows build broken The package has been fixed already but the submodule hasn't been updated. For a quick fix just cd into libraries/time and checkout master. I was hesitant to push the new submodule since we had

Re: Windows build broken

The package has been fixed already but the submodule hasn't been updated. For a quick fix just cd into libraries/time and checkout master. I was hesitant to push the new submodule since we hadn't branched yet for 8.2 On Wed, 22 Feb 2017, 14:09 Simon Peyton Jones via 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

Re: Windows build again

Simon Peyton Jones via ghc-devs writes: > Windows build is broken in a new way. > When I run validate I end up with sh.exe processes that consume a full CPU > forever. See the process log below. > > Note that these are not GHC processes: they are shells! I have no

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

RE: windows build

) | -Original Message- | From: Ben Gamari [mailto:b...@well-typed.com] | Sent: 17 November 2016 15:24 | To: Simon Peyton Jones <simo...@microsoft.com> | Subject: RE: windows build | | Simon Peyton Jones <simo...@microsoft.com> writes: | | > OK thank you. | > | > Meanwhil

Re: Windows build broken -- again

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

Re: Windows build broken -- again

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:

RE: Windows build

;; 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 <simo...@micr

Re: Windows build

ypecheck/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

RE: Windows build

.../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 <simo...@microsoft.com>; ghc-devs@haskell.org Subject: Re: Windows build Hi Simon, What does which python 2 and

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

RE: Windows build

evs@haskell.org> 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, <loneti...@gmail.com<mailto:loneti...@gmail.com>> wrote: Hi Simon

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. > >

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

RE: Windows build broken

Thanks for a prompt fix! From: Tamar Christina [mailto:loneti...@gmail.com] Sent: 04 March 2015 00:47 To: Austin Seipp; Simon Peyton Jones Cc: ghc-devs@haskell.org Subject: Re: Windows build broken Hi Simon, Austin https://phabricator.haskell.org/D698 should fix the build. validate runs

Re: Windows build broken

This must be fallout from the VEH handler change I pushed earlier - 5200bdeb26c5ec98739b14b10fc8907296bceeb9. I'll try to fix/revert shortly. On Tue, Mar 3, 2015 at 4:30 PM, Simon Peyton Jones simo...@microsoft.com wrote: AAARGH! Windows build is broken again. Please can someone fix? In

Re: Windows build broken

Hi, Yes, sorry about that, I’m trying to reproduce it locally but no luck so far.. (waiting for a clean checkout to finish now) But the fix is probably to swap the definition of Excn.h and PosixSource.h in RtsMain.c or moving Excn.h to the bottom of the include list. Something in Excn.h

Re: Windows build gotchas

On 1. 1. 2015 19:01, Martin Foster wrote: 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

Re: Windows build gotchas

On Thu, Jan 1, 2015 at 6:42 PM, Herbert Valerio Riedel hvrie...@gmail.com wrote: 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

Re: Windows build gotchas

Hello Martin, Here's just some minor additional context information... On 2015-01-01 at 19:01:53 +0100, Martin Foster wrote: [...] - I note ./sync-all --help says, under Flags, that --windows also clones the ghc-tarballs repository (enabled by default on Windows), and I've

RE: Windows build broken again: urgent

] | 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

Re: Windows build broken again: urgent

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

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

RE: Windows build broken again: urgent

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

Re: Windows build broken again: urgent

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

Re: Windows build broken in Linker.c

https://phabricator.haskell.org/D400 On Mon, Oct 27, 2014 at 1:34 PM, Gintautas Miliauskas gintau...@miliauskas.lt wrote: FYI, after the fix ghc builds again on Windows 32-bit, but validate.sh fails: rts\Linker.c: In function 'allocateImageAndTrampolines': rts\Linker.c:3657:31:

Re: Windows build broken in Linker.c

Sorry about this; merged - 208a0c207c1001da0fe63e9640e2a7e0e11c4aff (I actually only built the RTS to fix that build failure... I didn't ./validate with -Wall enabled. I'm to blame here!) On Wed, Oct 29, 2014 at 5:36 PM, Gintautas Miliauskas gintau...@miliauskas.lt wrote:

Re: Windows build broken in Linker.c

FYI, after the fix ghc builds again on Windows 32-bit, but validate.sh fails: rts\Linker.c: In function 'allocateImageAndTrampolines': rts\Linker.c:3657:31: error: unused parameter 'member_name' [-Werror=unused-parameter] pathchar* arch_name, char* member_name,

Re: Windows build broken in Linker.c

This is still not fixed, right? I've been working on the mingw gcc upgrade and testing on 32 bit, and this failure got me running in circles until I discovered that baseline was broken too... On Fri, Oct 17, 2014 at 2:00 AM, Simon Marlow marlo...@gmail.com wrote: I was working on a fix

Re: Windows build broken in Linker.c

I sent a patch to Austin to validate+commit earlier this week. On 24/10/2014 15:08, Gintautas Miliauskas wrote: This is still not fixed, right? I've been working on the mingw gcc upgrade and testing on 32 bit, and this failure got me running in circles until I discovered that baseline was

Re: Windows build broken in Linker.c

Gah, this slipped my mind. On it. On Fri, Oct 24, 2014 at 10:33 AM, Simon Marlow marlo...@gmail.com wrote: I sent a patch to Austin to validate+commit earlier this week. On 24/10/2014 15:08, Gintautas Miliauskas wrote: This is still not fixed, right? I've been working on the mingw gcc

Re: Windows build broken in Linker.c

I see what's going on and am fixing it... The code broke 32-bit due to #ifdefery, but I think it can be removed, perhaps (which would be preferable). On Thu, Oct 16, 2014 at 3:43 PM, Simon Peyton Jones simo...@microsoft.com wrote: Simon Aargh! I think the Windows build is broken again. I

Re: Windows build broken in Linker.c

I was working on a fix yesterday but ran out of time. Frankly this code is a nightmare, every time I touch it it breaks on some platform - this time I validated on 64 bit Windows but not 32. Aargh indeed. On 16 Oct 2014 14:32, Austin Seipp aus...@well-typed.com mailto:aus...@well-typed.com

RE: Windows build broken (again)

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

RE: Windows build broken (again)

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

Re: Windows build broken (again)

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),

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.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

Re: Windows build broken (again)

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

Re: Windows build broken (again)

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

RE: Windows build fails -- again!

Thanks Simon | -Original Message- | From: Simon Peyton Jones | Sent: 20 August 2014 23:48 | To: 'Gabor Greif'; 'ghc-devs@haskell.org'; 'Andreas Voellmy' | Subject: RE: Windows build fails -- again! | | Help! My Windows build is still falling over as below. | | Andreas, you seem

Re: Windows build fails -- again!

| | Sent: 20 August 2014 09:26 | | To: Gabor Greif; ghc-devs@haskell.org | | Subject: RE: Windows build fails -- again! | | | | Thanks Gabor. But it makes no difference. Your change is inside an | | #ifdef that checks for windows, and your change is in the no-windows | | branch only

Re: Windows build fails -- again!

that if I hear nothing I can simply revert his patch but that seems like the Wrong Solution Thanks Simon | -Original Message- | From: Simon Peyton Jones | Sent: 20 August 2014 23:48 | To: 'Gabor Greif'; 'ghc-devs@haskell.org'; 'Andreas Voellmy' | Subject: RE: Windows build fails -- again

Re: Windows build fails -- again!

| -Original Message- | From: Simon Peyton Jones | Sent: 20 August 2014 23:48 | To: 'Gabor Greif'; 'ghc-devs@haskell.org'; 'Andreas Voellmy' | Subject: RE: Windows build fails -- again! | | Help! My Windows build is still falling over as below. | | Andreas, you seem to be the author

Re: Windows build fails -- again!

like the Wrong Solution Thanks Simon | -Original Message- | From: Simon Peyton Jones | Sent: 20 August 2014 23:48 | To: 'Gabor Greif'; 'ghc-devs@haskell.org'; 'Andreas Voellmy' | Subject: RE: Windows build fails -- again! | | Help! My Windows build is still falling over as below

Re: Windows build fails -- again!

Hi! I think this isn't broken on just Windows. The error comes from the warning about no prototype (and -Werror), and it doesn't have a prototype on other OSes either. Niklas 2014-08-20 7:42 GMT+02:00 Johan Tibell johan.tib...@gmail.com: f9f89b7884ccc8ee5047cf4fffdf2b36df6832df is probably

RE: Windows build fails -- again!

, and I have no idea which will win when it is #included. Thanks Simon | -Original Message- | From: Gabor Greif [mailto:ggr...@gmail.com] | Sent: 19 August 2014 23:38 | To: Simon Peyton Jones | Subject: Re: Windows build fails -- again! | | Simon, | | try this (attached) patch

RE: Windows build fails -- again!

-devs@haskell.org | Subject: RE: Windows build fails -- again! | | Thanks Gabor. But it makes no difference. Your change is inside an | #ifdef that checks for windows, and your change is in the no-windows | branch only. | | Also there are two IOManager.h file | includes/rts/IOManager.h

Re: Windows build fails -- again!

f9f89b7884ccc8ee5047cf4fffdf2b36df6832df is probably to blame. Found by running `git log -SsetIOManagerControlFd`. The -S flag is a good way to find when a symbol is added/removed. On Wed, Aug 20, 2014 at 12:16 AM, Simon Peyton Jones simo...@microsoft.com wrote: Aaargh! My windows build is

Re: Windows build broken -- again!

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

Re: Windows build broken

Looks like 5d7f59018703b94ebfe96cbef5574ec396a1c051 is the culprit. Simon M, perhaps you can look at this? I'm tied up in the 7.8 branch at the moment, but I can revert it temporarily at least (I imagine the fix is easy enough - if you can't get to it soon, I'll revert and fix it when I get a

Re: Windows build broken

Sorry, probably my fault. I've attached a patch that should fix it, which should get you going while I validate. Cheers, Simon On 04/04/2014 16:14, Simon Peyton Jones wrote: Can someone fix this? This is breakage on Windows. It was fine yesterday. Simon cc1.exe: warnings being treated as

RE: Windows build

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

Re: Windows build

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

RE: Windows build

.) 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

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

RE: Windows build failures in FD.hs

I have not seen that and I build on Windows all the time. The relevant big in FD.hs is #ifndef mingw32_HOST_OS getUniqueFileInfo _ dev ino = return (fromIntegral dev, fromIntegral ino) #else getUniqueFileInfo fd _ _ = do with 0 $ \devptr - do with 0 $ \inoptr - do c_getUniqueFileInfo fd

Re: Windows build failures in FD.hs

Looks like this is caused by the addition of default-language: Haskell2010 (which is not the default default, apparently!) in base.cabal in commit dfb52c3d58 from Saturday. See http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs-and-infelicities.html#haskell-standards-divergence, section

Re: Windows build failures in FD.hs

Thanks for pointing this out Reid. Fixed. On Tue, Oct 1, 2013 at 5:35 PM, Reid Barton rwbar...@gmail.com wrote: Looks like this is caused by the addition of default-language: Haskell2010 (which is not the default default, apparently!) in base.cabal in commit dfb52c3d58 from Saturday. See