Linker.c broken

older
Interruptible exception wormholes...

Simon Peyton Jones

1 Jul 2016 1 Jul '16

6:51 p.m.

Aargh! Windows is broken /again/. Some mess-up in Linker.c. I have not yet tried reverting recent patches. Might someone fix please? It’s really helpful to validate on Windows when making RTS changes. Simon rts\Linker.c: In function 'ghci_find': rts\Linker.c:1482:52: error: error: pointer type mismatch in conditional expression [-Werror] oc->archiveMemberName : oc->fileName); ^ rts\Linker.c:1480:28: error: error: format '%ls' expects argument of type 'wchar_t *', but argument 3 has type 'void *' [-Werror=format=] debugBelch("%p is in %" PATH_FMT, addr, ^ "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-fno-omit-frame-pointer -optc-g -optc-O0 -optc-DRtsWay=\"rts_debug\" -optc-DWINVER=0x06000100 -static -optc-DDEBUG -ticky -DTICKY_TICKY -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 -O0 -Wnoncanonical-monad-instances -c rts/RaiseAsync.c -o rts/dist/build/RaiseAsync.debug_o rts\Linker.c:1483:28: error: error: format '%lx' expects argument of type 'long unsigned int', but argument 3 has type 'long long unsigned int' [-Werror=format=] debugBelch(", section %d, offset %lx\n", i, ^ In file included from rts\Linker.c:13:0: error: rts\Linker.c: In function 'ocTryLoad': rts\Linker.c:2563:55: error: error: pointer type mismatch in conditional expression [-Werror] oc->archiveMemberName : oc->fileName)); ^ includes\Rts.h:300:53: error: note: in definition of macro 'IF_DEBUG' #define IF_DEBUG(c,s) if (RtsFlags.DebugFlags.c) { s; } ^ rts\Linker.c:2561:33: error: error: format '%ls' expects argument of type 'wchar_t *', but argument 2 has type 'void *' [-Werror=format=] IF_DEBUG(linker, debugBelch("Resolving %" PATH_FMT "\n", ^ includes\Rts.h:300:53: error: note: in definition of macro 'IF_DEBUG' #define IF_DEBUG(c,s) if (RtsFlags.DebugFlags.c) { s; } ^ cc1.exe: all warnings being treated as errors `gcc.exe' failed in phase `C Compiler'. (Exit code: 1) rts/ghc.mk:255: recipe for target 'rts/dist/build/Linker.debug_o' failed make[1]: *** [rts/dist/build/Linker.debug_o] Error 1 make[1]: *** Waiting for unfinished jobs.... Makefile:129: recipe for target 'all' failed make: *** [all] Error 2 /cygdrive/c/code/HEAD$

Attachments:

attachment.html (text/html — 14.9 KB)

Show replies by date

Edward Z. Yang

1 Jul 1 Jul

8:02 p.m.

I'm guessing it's: commit 6377757918c1e7f63638d6f258cad8d5f02bb6a7 Author: Simon Marlow Date: Wed Jun 29 21:50:18 2016 +0100 Linker: some extra debugging / logging which added ghci_find. Edward Excerpts from Simon Peyton Jones via ghc-devs's message of 2016-07-01 18:51:20 -0400:

...

Aargh! Windows is broken /again/. Some mess-up in Linker.c. I have not yet tried reverting recent patches. Might someone fix please? It’s really helpful to validate on Windows when making RTS changes. Simon

rts\Linker.c: In function 'ghci_find':

rts\Linker.c:1482:52: error:

error: pointer type mismatch in conditional expression [-Werror]

oc->archiveMemberName : oc->fileName);

^

rts\Linker.c:1480:28: error:

error: format '%ls' expects argument of type 'wchar_t *', but argument 3 has type 'void *' [-Werror=format=]

debugBelch("%p is in %" PATH_FMT, addr,

^

"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-fno-omit-frame-pointer -optc-g -optc-O0 -optc-DRtsWay=\"rts_debug\" -optc-DWINVER=0x06000100 -static -optc-DDEBUG -ticky -DTICKY_TICKY -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 -O0 -Wnoncanonical-monad-instances -c rts/RaiseAsync.c -o rts/dist/build/RaiseAsync.debug_o

rts\Linker.c:1483:28: error:

error: format '%lx' expects argument of type 'long unsigned int', but argument 3 has type 'long long unsigned int' [-Werror=format=]

debugBelch(", section %d, offset %lx\n", i,

^

In file included from rts\Linker.c:13:0: error:

rts\Linker.c: In function 'ocTryLoad':

rts\Linker.c:2563:55: error:

error: pointer type mismatch in conditional expression [-Werror]

oc->archiveMemberName : oc->fileName));

^

includes\Rts.h:300:53: error:

note: in definition of macro 'IF_DEBUG'

#define IF_DEBUG(c,s) if (RtsFlags.DebugFlags.c) { s; }

^

rts\Linker.c:2561:33: error:

error: format '%ls' expects argument of type 'wchar_t *', but argument 2 has type 'void *' [-Werror=format=]

IF_DEBUG(linker, debugBelch("Resolving %" PATH_FMT "\n",

^

includes\Rts.h:300:53: error:

note: in definition of macro 'IF_DEBUG'

#define IF_DEBUG(c,s) if (RtsFlags.DebugFlags.c) { s; }

^

cc1.exe: all warnings being treated as errors

`gcc.exe' failed in phase `C Compiler'. (Exit code: 1)

rts/ghc.mk:255: recipe for target 'rts/dist/build/Linker.debug_o' failed

make[1]: *** [rts/dist/build/Linker.debug_o] Error 1

make[1]: *** Waiting for unfinished jobs....

Makefile:129: recipe for target 'all' failed

make: *** [all] Error 2

/cygdrive/c/code/HEAD$

Simon Peyton Jones

4 Jul 4 Jul

4:28 a.m.

That was it. Simon M: would you care to fix? Or should I push a revert? Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of | Edward Z. Yang | Sent: 02 July 2016 01:02 | To: ghc-devs | Subject: Re: Linker.c broken | | I'm guessing it's: | | commit 6377757918c1e7f63638d6f258cad8d5f02bb6a7 | Author: Simon Marlow | Date: Wed Jun 29 21:50:18 2016 +0100 | | Linker: some extra debugging / logging | | which added ghci_find. | | Edward | | Excerpts from Simon Peyton Jones via ghc-devs's message of 2016-07-01 | 18:51:20 -0400: | > Aargh! Windows is broken /again/. Some mess-up in Linker.c. | > I have not yet tried reverting recent patches. Might someone fix | please? | > It’s really helpful to validate on Windows when making RTS changes. | > Simon | > | > | > | > rts\Linker.c: In function 'ghci_find': | > | > | > | > rts\Linker.c:1482:52: error: | > | > error: pointer type mismatch in conditional expression [- | Werror] | > | > oc->archiveMemberName : oc- | >fileName); | > | > ^ | > | > | > | > rts\Linker.c:1480:28: error: | > | > error: format '%ls' expects argument of type 'wchar_t *', but | argument 3 has type 'void *' [-Werror=format=] | > | > debugBelch("%p is in %" PATH_FMT, addr, | > | > ^ | > | > "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-fno-omit-frame-pointer -optc-g -optc-O0 - | optc-DRtsWay=\"rts_debug\" -optc-DWINVER=0x06000100 -static -optc- | DDEBUG -ticky -DTICKY_TICKY -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 -O0 -Wnoncanonical-monad- | instances -c rts/RaiseAsync.c -o rts/dist/build/RaiseAsync.debug_o | > | > | > | > rts\Linker.c:1483:28: error: | > | > error: format '%lx' expects argument of type 'long unsigned | int', but argument 3 has type 'long long unsigned int' [- | Werror=format=] | > | > debugBelch(", section %d, offset %lx\n", i, | > | > ^ | > | > | > | > In file included from rts\Linker.c:13:0: error: | > | > rts\Linker.c: In function 'ocTryLoad': | > | > | > | > rts\Linker.c:2563:55: error: | > | > error: pointer type mismatch in conditional expression [- | Werror] | > | > oc->archiveMemberName : oc- | >fileName)); | > | > ^ | > | > | > | > includes\Rts.h:300:53: error: | > | > note: in definition of macro 'IF_DEBUG' | > | > #define IF_DEBUG(c,s) if (RtsFlags.DebugFlags.c) { s; } | > | > ^ | > | > | > | > rts\Linker.c:2561:33: error: | > | > error: format '%ls' expects argument of type 'wchar_t *', but | argument 2 has type 'void *' [-Werror=format=] | > | > IF_DEBUG(linker, debugBelch("Resolving %" PATH_FMT "\n", | > | > ^ | > | > | > | > includes\Rts.h:300:53: error: | > | > note: in definition of macro 'IF_DEBUG' | > | > #define IF_DEBUG(c,s) if (RtsFlags.DebugFlags.c) { s; } | > | > ^ | > | > cc1.exe: all warnings being treated as errors | > | > `gcc.exe' failed in phase `C Compiler'. (Exit code: 1) | > | > rts/ghc.mk:255: recipe for target 'rts/dist/build/Linker.debug_o' | failed | > | > make[1]: *** [rts/dist/build/Linker.debug_o] Error 1 | > | > make[1]: *** Waiting for unfinished jobs.... | > | > Makefile:129: recipe for target 'all' failed | > | > make: *** [all] Error 2 | > | > /cygdrive/c/code/HEAD$ | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h | askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5be115baccfd40d | 0352a08d3a20c257d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ZJFHPuP | zkPfac4Upu3w6r4bSawNwxbV4p%2fr%2f69vqh2o%3d

Simon Marlow

4:37 a.m.

I will fix it, sorry about this. Unfortunately I can't really add a Windows validate into my workflow because it would mean rebooting my laptop into Windows and not doing anything else for several hours. We need some CI support for Windows - Ben/Austin any thoughts on this? On 4 July 2016 at 09:28, Simon Peyton Jones wrote:

...

That was it.

Simon M: would you care to fix? Or should I push a revert?

Simon

| -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of | Edward Z. Yang | Sent: 02 July 2016 01:02 | To: ghc-devs | Subject: Re: Linker.c broken | | I'm guessing it's: | | commit 6377757918c1e7f63638d6f258cad8d5f02bb6a7 | Author: Simon Marlow | Date: Wed Jun 29 21:50:18 2016 +0100 | | Linker: some extra debugging / logging | | which added ghci_find. | | Edward | | Excerpts from Simon Peyton Jones via ghc-devs's message of 2016-07-01 | 18:51:20 -0400: | > Aargh! Windows is broken /again/. Some mess-up in Linker.c. | > I have not yet tried reverting recent patches. Might someone fix | please? | > It’s really helpful to validate on Windows when making RTS changes. | > Simon | > | > | > | > rts\Linker.c: In function 'ghci_find': | > | > | > | > rts\Linker.c:1482:52: error: | > | > error: pointer type mismatch in conditional expression [- | Werror] | > | > oc->archiveMemberName : oc- | >fileName); | > | > ^ | > | > | > | > rts\Linker.c:1480:28: error: | > | > error: format '%ls' expects argument of type 'wchar_t *', but | argument 3 has type 'void *' [-Werror=format=] | > | > debugBelch("%p is in %" PATH_FMT, addr, | > | > ^ | > | > "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-fno-omit-frame-pointer -optc-g -optc-O0 - | optc-DRtsWay=\"rts_debug\" -optc-DWINVER=0x06000100 -static -optc- | DDEBUG -ticky -DTICKY_TICKY -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 -O0 -Wnoncanonical-monad- | instances -c rts/RaiseAsync.c -o rts/dist/build/RaiseAsync.debug_o | > | > | > | > rts\Linker.c:1483:28: error: | > | > error: format '%lx' expects argument of type 'long unsigned | int', but argument 3 has type 'long long unsigned int' [- | Werror=format=] | > | > debugBelch(", section %d, offset %lx\n", i, | > | > ^ | > | > | > | > In file included from rts\Linker.c:13:0: error: | > | > rts\Linker.c: In function 'ocTryLoad': | > | > | > | > rts\Linker.c:2563:55: error: | > | > error: pointer type mismatch in conditional expression [- | Werror] | > | > oc->archiveMemberName : oc- | >fileName)); | > | > ^ | > | > | > | > includes\Rts.h:300:53: error: | > | > note: in definition of macro 'IF_DEBUG' | > | > #define IF_DEBUG(c,s) if (RtsFlags.DebugFlags.c) { s; } | > | > ^ | > | > | > | > rts\Linker.c:2561:33: error: | > | > error: format '%ls' expects argument of type 'wchar_t *', but | argument 2 has type 'void *' [-Werror=format=] | > | > IF_DEBUG(linker, debugBelch("Resolving %" PATH_FMT "\n", | > | > ^ | > | > | > | > includes\Rts.h:300:53: error: | > | > note: in definition of macro 'IF_DEBUG' | > | > #define IF_DEBUG(c,s) if (RtsFlags.DebugFlags.c) { s; } | > | > ^ | > | > cc1.exe: all warnings being treated as errors | > | > `gcc.exe' failed in phase `C Compiler'. (Exit code: 1) | > | > rts/ghc.mk:255: recipe for target 'rts/dist/build/Linker.debug_o' | failed | > | > make[1]: *** [rts/dist/build/Linker.debug_o] Error 1 | > | > make[1]: *** Waiting for unfinished jobs.... | > | > Makefile:129: recipe for target 'all' failed | > | > make: *** [all] Error 2 | > | > /cygdrive/c/code/HEAD$ | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h | askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5be115baccfd40d | 0352a08d3a20c257d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ZJFHPuP | zkPfac4Upu3w6r4bSawNwxbV4p%2fr%2f69vqh2o%3d

Erik de Castro Lopo

4:45 a.m.

Simon Marlow wrote:

...

I will fix it, sorry about this. Unfortunately I can't really add a Windows validate into my workflow because it would mean rebooting my laptop into Windows and not doing anything else for several hours.

Even building as 32 bit would have shaken out a bug in the format specifiers to the debugBelch statement. Are you on Linux? I use a 32 bit debian chroot on my otherwise 64 bit Debian system.

...

We need some CI support for Windows - Ben/Austin any thoughts on this?

That would be an improvement, but it doesn't help for other OSes like Aix and Solaris or other CPUs. I also noticed that patch bypassed Phabricator. I assume that was a mistake. I've done it myself. We need to be particularly careful with the RTS code because its so fragile. It needs to be build and tested on a wide variety of systems. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

Simon Marlow

5:20 a.m.

On 4 July 2016 at 09:45, Erik de Castro Lopo wrote:

...

Simon Marlow wrote:

...
I will fix it, sorry about this. Unfortunately I can't really add a Windows validate into my workflow because it would mean rebooting my laptop into Windows and not doing anything else for several hours.

Even building as 32 bit would have shaken out a bug in the format specifiers to the debugBelch statement.

Are you on Linux? I use a 32 bit debian chroot on my otherwise 64 bit Debian system.

Building on 32-bit would flush out some bugs, but not others. Yes I could use a chroot, or a VM, and I could have Windows in a VM. But what about OS X? In fact validate on a single platform already ties up my machine for an hour, so the more platforms we have to validate the less practical it is to make small changes. I think more automation is the only good solution to this. So, I rely on CI for most of my commits, whether it's Phabricator (now fixed!) or Travis.

...

...
We need some CI support for Windows - Ben/Austin any thoughts on this?

That would be an improvement, but it doesn't help for other OSes like Aix and Solaris or other CPUs.

I also noticed that patch bypassed Phabricator. I assume that was a mistake. I've done it myself. We need to be particularly careful with the RTS code because its so fragile. It needs to be build and tested on a wide variety of systems.

It was actually intentional. The patch validated on Travis: https://travis-ci.org/simonmar/ghc/builds/141572355 and I didn't think it was worth having it reviewed (but if you want to review all linker patches I'd be happy to put them on Phabricator in the future). Cheers Simon

...

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

Erik de Castro Lopo

5:43 a.m.

Simon Marlow wrote:

...

It was actually intentional. The patch validated on Travis: https://travis-ci.org/simonmar/ghc/builds/141572355 and I didn't think it was worth having it reviewed (but if you want to review all linker patches I'd be happy to put them on Phabricator in the future).

I *try* (time permitting) to review all linker patches. I've just started a new job (coding Haskell) but it means I've got a bit less time to hack on GHC. I have a Phab rule to notify me on all patches that touch Linker.c. I try to look at all of them, but sometimes they have been accepted by others and committed before I even look at them. For the ones that are nor accepted and committed before I get to them, I often test them on PowerPC or Arm and I'm also willing to keep on doing this (time permitting). Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

Ben Gamari

6:38 a.m.

Erik de Castro Lopo writes:

...

Simon Marlow wrote:

...
I will fix it, sorry about this. Unfortunately I can't really add a Windows validate into my workflow because it would mean rebooting my laptop into Windows and not doing anything else for several hours.

Even building as 32 bit would have shaken out a bug in the format specifiers to the debugBelch statement.

Are you on Linux? I use a 32 bit debian chroot on my otherwise 64 bit Debian system.

Indeed; and I think it would also be worthwhile also setting up at least a nightly build validating 32-bit Linux. Cheers, - Ben

Erik de Castro Lopo

7:04 a.m.

Ben Gamari wrote:

...

Indeed; and I think it would also be worthwhile also setting up at least a nightly build validating 32-bit Linux.

If its not integrated with the CI, I'm not sure how useful that is. As you may remember I have a Jenkins instance. Once a day it polls git and if there are new commits sicen the last time it was polled, it builds the following: Arch OS BuildFlavour x86_64 linux perf x86_64 darwin perf x86_64 linux perf-llvm x86_64 linux devel2/unregisterised x86_64 linux devel2 with Clang x86_64 Linux perf powerpc linux devel2 powerpc linux devel2/unregisterised armhf linux devel2 armhf linux devel2/unregisterised as well as cross-compiling from x86_64/linux to armhf/linux and arm64/linux. This does catche the ocassional problem but when something shows up but fixing them is a bigger problem. FOr example, I simply have not had time to look at : https://ghc.haskell.org/trac/ghc/ticket/12238 Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

Ben Gamari

6:36 a.m.

Simon Marlow writes:

...

I will fix it, sorry about this. Unfortunately I can't really add a Windows validate into my workflow because it would mean rebooting my laptop into Windows and not doing anything else for several hours. We need some CI support for Windows - Ben/Austin any thoughts on this?

I agree; this would be great. I have a Windows machine which I'd be happy setup as a builder although I'm afraid it's behind NAT, so integration with Harbormaster may require some tunneling. On that note, how is the Harbormaster effort going, Austin? It appears that Differentials are still not being built. Is there anything I can do to help here? Cheers, - Ben

Boespflug, Mathieu

7:15 a.m.

On 4 July 2016 at 12:36, Ben Gamari wrote:

...

Simon Marlow writes:

...
I will fix it, sorry about this. Unfortunately I can't really add a Windows validate into my workflow because it would mean rebooting my laptop into Windows and not doing anything else for several hours. We need some CI support for Windows - Ben/Austin any thoughts on this?

I agree; this would be great. I have a Windows machine which I'd be happy setup as a builder although I'm afraid it's behind NAT, so integration with Harbormaster may require some tunneling.

Just a suggestion - the easiest and most reliable would probably be to simply use Appveyor for this. They offer a hosted and fully managed CI service very similar to Travis CI - only difference being it runs tests on Windows boxes. And just like Travis CI, it's free! The advantage of a hosted CI service is that no one except Appveyor need to worry about keeping the build bot highly available. Only downside is their machines in the free tier can be a bit slow. But that's a problem that can be iterated on as the need arises. Best, -- Mathieu Boespflug Founder at http://tweag.io.

Ben Gamari

7:26 a.m.

"Boespflug, Mathieu" writes:

...

On 4 July 2016 at 12:36, Ben Gamari wrote:

...
Simon Marlow writes:

...
I will fix it, sorry about this. Unfortunately I can't really add a Windows validate into my workflow because it would mean rebooting my laptop into Windows and not doing anything else for several hours. We need some CI support for Windows - Ben/Austin any thoughts on this?

I agree; this would be great. I have a Windows machine which I'd be happy setup as a builder although I'm afraid it's behind NAT, so integration with Harbormaster may require some tunneling.

Just a suggestion - the easiest and most reliable would probably be to simply use Appveyor for this. They offer a hosted and fully managed CI service very similar to Travis CI - only difference being it runs tests on Windows boxes. And just like Travis CI, it's free!

The advantage of a hosted CI service is that no one except Appveyor need to worry about keeping the build bot highly available.

Only downside is their machines in the free tier can be a bit slow. But that's a problem that can be iterated on as the need arises.

I've noticed that several of the core libraries rely on Appveyor with good results. However, I had assumed that GHC would exceed the maximum build time of their free tier since the build takes a few hours on my Windows box. It seems that Appveyor has a one-hour build duration limit, similar to Travis. Cheers, - Ben

Boespflug, Mathieu

7:45 a.m.

True. Worth a try asking them what limits they're willing to lift for a high profile open source project like GHC, I think. -- Mathieu Boespflug Founder at http://tweag.io. On 4 July 2016 at 13:26, Ben Gamari wrote:

...

"Boespflug, Mathieu" writes:

...
On 4 July 2016 at 12:36, Ben Gamari wrote:

...
Simon Marlow writes:

...
I will fix it, sorry about this. Unfortunately I can't really add a Windows validate into my workflow because it would mean rebooting my laptop into Windows and not doing anything else for several hours. We need some CI support for Windows - Ben/Austin any thoughts on this?

I agree; this would be great. I have a Windows machine which I'd be happy setup as a builder although I'm afraid it's behind NAT, so integration with Harbormaster may require some tunneling.

Just a suggestion - the easiest and most reliable would probably be to simply use Appveyor for this. They offer a hosted and fully managed CI service very similar to Travis CI - only difference being it runs tests on Windows boxes. And just like Travis CI, it's free!

The advantage of a hosted CI service is that no one except Appveyor need to worry about keeping the build bot highly available.

Only downside is their machines in the free tier can be a bit slow. But that's a problem that can be iterated on as the need arises.

I've noticed that several of the core libraries rely on Appveyor with good results. However, I had assumed that GHC would exceed the maximum build time of their free tier since the build takes a few hours on my Windows box. It seems that Appveyor has a one-hour build duration limit, similar to Travis.

Cheers,

- Ben

Phyx

7:48 a.m.

I can build and validate in about an hour myself using 9 jobs on a core i7. If I revert the change in the testsuite preventing parallel runs for Windows. Tamar On Mon, Jul 4, 2016, 12:26 Ben Gamari wrote:

...

"Boespflug, Mathieu" writes:

...
On 4 July 2016 at 12:36, Ben Gamari wrote:

...
Simon Marlow writes:

...
I will fix it, sorry about this. Unfortunately I can't really add a Windows validate into my workflow because it would mean rebooting my laptop into Windows and not doing anything else for several hours. We need some CI support for Windows - Ben/Austin any thoughts on this?

I agree; this would be great. I have a Windows machine which I'd be happy setup as a builder although I'm afraid it's behind NAT, so integration with Harbormaster may require some tunneling.

Just a suggestion - the easiest and most reliable would probably be to simply use Appveyor for this. They offer a hosted and fully managed CI service very similar to Travis CI - only difference being it runs tests on Windows boxes. And just like Travis CI, it's free!

The advantage of a hosted CI service is that no one except Appveyor need to worry about keeping the build bot highly available.

Only downside is their machines in the free tier can be a bit slow. But that's a problem that can be iterated on as the need arises.

I've noticed that several of the core libraries rely on Appveyor with good results. However, I had assumed that GHC would exceed the maximum build time of their free tier since the build takes a few hours on my Windows box. It seems that Appveyor has a one-hour build duration limit, similar to Travis.

Cheers,

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

Erik de Castro Lopo

7:57 a.m.

Phyx wrote:

...

I can build and validate in about an hour myself using 9 jobs on a core i7. If I revert the change in the testsuite preventing parallel runs for Windows

Oh dear, why is that? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

Phyx

8:05 a.m.

There used to be a bug in the msys2 runtime which made certain processes hang on exit in a non deterministic way. So the parallel runs was disabled. I was looking into it but haven't been able to reproduce it at all in months now since either upgrading msys2 or Windows (to Windows 10). We have a ticket with more information on it and what I found back then, but haven't been able to progress. It might be that they've just fixed it in the mean time. On Mon, Jul 4, 2016, 12:58 Erik de Castro Lopo wrote:

...

Phyx wrote:

...
I can build and validate in about an hour myself using 9 jobs on a core i7. If I revert the change in the testsuite preventing parallel runs for Windows

Oh dear, why is that?

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

Simon Peyton Jones

8:56 a.m.

Let’s re-enable it. Or: how can I selectively re-enable it for in my validate.mk? From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Phyx Sent: 04 July 2016 13:05 To: Erik de Castro Lopo ; ghc-devs Subject: Re: Linker.c broken There used to be a bug in the msys2 runtime which made certain processes hang on exit in a non deterministic way. So the parallel runs was disabled. I was looking into it but haven't been able to reproduce it at all in months now since either upgrading msys2 or Windows (to Windows 10). We have a ticket with more information on it and what I found back then, but haven't been able to progress. It might be that they've just fixed it in the mean time. On Mon, Jul 4, 2016, 12:58 Erik de Castro Lopo mailto:mle%2Bhs@mega-nerd.com> wrote: Phyx wrote:

...

I can build and validate in about an hour myself using 9 jobs on a core i7. If I revert the change in the testsuite preventing parallel runs for Windows

Oh dear, why is that? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.mega-nerd.com%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c0e67fa6b060f43bdd98b08d3a40374cb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=XixXqIypnkhwOuwWej5nEvFgW5fDwkXs5YJ6iBy8KlM%3d _______________________________________________ ghc-devs mailing list ghc-devs@haskell.orgmailto: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=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c0e67fa6b060f43bdd98b08d3a40374cb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6c%2fUMWAKuOV0t6bLOzGjFj9F6Md39UCkDAe%2b2uIES2w%3d

Phyx

10:34 a.m.

I don't think you can do it in validate.mk, Only https://github.com/ghc/ghc/blob/master/testsuite/driver/runtests.py#L144 here as far as I know. I also constantly have to watch out I don't commit it though On Mon, Jul 4, 2016, 13:56 Simon Peyton Jones wrote:

...

Let’s re-enable it. Or: how can I selectively re-enable it for in my validate.mk?

*From:* ghc-devs [mailto:ghc-devs-bounces@haskell.org] *On Behalf Of *Phyx *Sent:* 04 July 2016 13:05 *To:* Erik de Castro Lopo ; ghc-devs < ghc-devs@haskell.org> *Subject:* Re: Linker.c broken

There used to be a bug in the msys2 runtime which made certain processes hang on exit in a non deterministic way.

So the parallel runs was disabled. I was looking into it but haven't been able to reproduce it at all in months now since either upgrading msys2 or Windows (to Windows 10).

We have a ticket with more information on it and what I found back then, but haven't been able to progress.

It might be that they've just fixed it in the mean time.

On Mon, Jul 4, 2016, 12:58 Erik de Castro Lopo wrote:

Phyx wrote:

...
I can build and validate in about an hour myself using 9 jobs on a core i7. If I revert the change in the testsuite preventing parallel runs for Windows

Oh dear, why is that?

Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.mega-nerd.com%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c0e67fa6b060f43bdd98b08d3a40374cb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=XixXqIypnkhwOuwWej5nEvFgW5fDwkXs5YJ6iBy8KlM%3d _______________________________________________ ghc-devs mailing list 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=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c0e67fa6b060f43bdd98b08d3a40374cb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6c%2fUMWAKuOV0t6bLOzGjFj9F6Md39UCkDAe%2b2uIES2w%3d

Simon Marlow

7:58 a.m.

If parallel tests now work on Windows, could it be enabled by default? On 4 July 2016 at 12:48, Phyx wrote:

...

I can build and validate in about an hour myself using 9 jobs on a core i7. If I revert the change in the testsuite preventing parallel runs for Windows.

Tamar

On Mon, Jul 4, 2016, 12:26 Ben Gamari wrote:

...
"Boespflug, Mathieu" writes:

...
On 4 July 2016 at 12:36, Ben Gamari wrote:

...
Simon Marlow writes:

...
I will fix it, sorry about this. Unfortunately I can't really add a Windows validate into my workflow because it would mean rebooting my laptop into Windows and not doing anything else for several hours. We need some CI support for Windows - Ben/Austin any thoughts on this?

I agree; this would be great. I have a Windows machine which I'd be happy setup as a builder although I'm afraid it's behind NAT, so integration with Harbormaster may require some tunneling.

Just a suggestion - the easiest and most reliable would probably be to simply use Appveyor for this. They offer a hosted and fully managed CI service very similar to Travis CI - only difference being it runs tests on Windows boxes. And just like Travis CI, it's free!

The advantage of a hosted CI service is that no one except Appveyor need to worry about keeping the build bot highly available.

Only downside is their machines in the free tier can be a bit slow. But that's a problem that can be iterated on as the need arises.

I've noticed that several of the core libraries rely on Appveyor with good results. However, I had assumed that GHC would exceed the maximum build time of their free tier since the build takes a few hours on my Windows box. It seems that Appveyor has a one-hour build duration limit, similar to Travis.

Cheers,

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

Ben Gamari

8:12 a.m.

Simon Marlow writes:

...

If parallel tests now work on Windows, could it be enabled by default?

I seem to remember trying this last summer and ran into trouble. That being said, it would be worth trying again. I've fired up another build; we'll see how it goes. Cheers, - Ben

Erik de Castro Lopo

4:34 a.m.

Simon Peyton Jones via ghc-devs wrote:

...

rts\Linker.c:1480:28: error:

error: format '%ls' expects argument of type 'wchar_t *', but argument 3 has type 'void *' [-Werror=format=]

debugBelch("%p is in %" PATH_FMT, addr,

I get an error on code from this commit on arm/linux. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

3243

Age (days ago)

3246

Last active (days ago)

List overview

Download

20 comments

8 participants

participants (8)

Ben Gamari
Ben Gamari
Boespflug, Mathieu
Edward Z. Yang
Erik de Castro Lopo
Phyx
Simon Marlow
Simon Peyton Jones

Linker.c broken

tags

participants (8)