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

RE: Windows build

ow? 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

Re: Windows build

ode) 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: Window

RE: Windows build

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

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 th

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

RE: Windows build

: 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

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 r

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 ; ghc-devs@haskell.org Subject: Re: Windows build Hi Simon, What does which python 2 and which python 3 return? Along

Re: Windows build

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@hask

RE: Windows build

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

RE: windows build

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

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

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 b

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 gotchas

On Thu, Jan 1, 2015 at 6:42 PM, Herbert Valerio Riedel 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 to tha

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

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 wrote: > AAARGH! Windows build is broken again. > > Please can someone fix? > > > > In file included f

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 broken

Hi Simon, Austin https://phabricator.haskell.org/D698 should fix the build. validate runs cleanly through. My apologies again, my last few builds were using ./validate --no-clean by my are-validating.mk was missing so it wasn’t compiling with -Werror. Regards, Tamar From: Austin Sei

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

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 chan

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 e

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 o

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 conception > of what they a

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, < ghc-devs@haskell.o

RE: Windows build broken

: Ashley Yakeley 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 hadn't branched yet for 8.2 On Wed, 22 Feb 2

Re: Windows build broken

> > > > *From:* Phyx [mailto:loneti...@gmail.com] > *Sent:* 22 February 2017 14:14 > *To:* Simon Peyton Jones ; ghc-devs@haskell.org > *Cc:* Ashley Yakeley > *Subject:* Re: Windows build broken > > > > The package has been fixed already but the submodule hasn

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 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 head is 4eb06c0. So checking out

RE: Windows build broken

eryone is busy. 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 | Subject: Re: Windows build broken | | Simon, | | It pains

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

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 Subject: Windows build

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

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. > > Alternatively to get you going

RE: Windows build broken

e? Thanks From: Phyx [mailto:loneti...@gmail.com] Sent: 04 October 2017 13:30 To: Simon Peyton Jones ; 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 don't support the m

Re: Windows build broken -- again!

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 : > Aaargh!

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 wrote: > Hi! > > Seems like it is the detabbing in commit 3021fb that has

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 wrote: > Aaargh! My windows build is broken, again. > > It

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 : > f9f89b7884ccc8ee5047cf4fffdf2b36df6832df is probably to blame. > > Found by

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!

; 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. | | Also there are two IOManager.h file | includes/rts/IOMana

RE: Windows build fails -- again!

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

Re: Windows build fails -- again!

I'd > | really appreciate a fix. (From anyone!) > | > | thank you > | > | Simon > | > | | -Original Message- > | | From: Simon Peyton Jones > | | Sent: 20 August 2014 09:26 > | | To: Gabor Greif; ghc-devs@haskell.org > | | Subject: RE: Windows buil

Re: Windows build fails -- again!

ing. I suppose 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'

Re: Windows build fails -- again!

> >> I suppose 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 >&g

Re: Windows build fails -- again!

f89b7884ccc8ee5047cf4fffdf2b36df6832df >>> on Tues 19th. >>> >>> Please can someone help? I'm begging. >>> >>> I suppose that if I hear nothing I can simply revert his patch but that >>> seems like the Wrong Solution >>> >

Re: Windows build fails -- again!

x27;m begging. > >>> > >>> I suppose that if I hear nothing I can simply revert his patch but that > >>> seems like the Wrong Solution > >>> > >>> Thanks > >>> > >>> Simon > >>> > >>> | -Ori

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" wrote: > Sigh. The testsuite fails utterly on Windows, with thousands of > identical errors > > => tc012(normal) 3039 of 4088 [1, 2677, 88]

Re: Windows build broken (again)

On Thu, Oct 2, 2014 at 4:39 PM, Simon Peyton Jones 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 preve

Re: Windows build broken (again)

Maybe it's the Python 3 patches. Excerpts from Brandon Allbery's message of 2014-10-02 14:00:26 -0700: > On Thu, Oct 2, 2014 at 4:39 PM, Simon Peyton Jones > wrote: > > > Presumably this is some kind of Windows escape-character problem. But it > > has worked fine for years, so what is going on?

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 test

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

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 co

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: https://phabricator.haskel

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 bit slow. I hope to hav

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

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` i

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: PGP signature ___

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 signature ___

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 writes: > https://ghc.haskell.org/trac/ghc/ticket/13375 > Are

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 seems. Cheers, - Ben

RE: Windows build broken again

| Subject: 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 validatin

RE: Windows build broken -- help!

PS Presumably it's these commits commit 00f1a4ab80b201ce15c509126f89c5a108786f32 Author: Douglas Wilson Date: Tue Feb 6 17:27:32 2018 -0500 rts: fix some barf format specifiers. Reviewers: bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie,

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 the

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!

Yes thanks Doug… testing now From: loneti...@gmail.com [mailto:loneti...@gmail.com] Sent: 08 February 2018 00:17 To: Douglas Wilson ; Simon Peyton Jones Cc: ghc-devs Subject: RE: Windows build broken -- help! I’ve pushed the commit. Thanks Doug! From: Douglas Wilson<mailto:douglas.

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 wrote: > Simon > > Aargh! I think the Windows build is broken again. > > I think this is your

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" > wrote: I see wha

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 wrote: > I was working on a fix yesterday but ran out of

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 broken

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 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 >> upgrade and tes

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

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 wrote: > https://phabricator.haskell.org/D400 > > On M

RE: Windows build broken again: urgent

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

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: T

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

t; 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 > *Sub

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

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 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 > http://www.ha

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 maybe

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 2

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 haskell > stuff committed to

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 that the libffi build is

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 a GHC. > > Please, could someone fix this? I

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 Description: PGP sign

RE: Windows build failing in a new way

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 in

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

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. Causing >> days of broke

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 ; ghc-devs@haskell.org Subject: Re: Windows build failing in a new way Hi Simon, As of this morning the Windows build was working fine https://github.c