Re: Building ghc on Windows with msys2

[lonetiger]

Hi Gintautas,


>  Indeed, the next thing I was going to ask was about expediting the decision 
> process. I would be happy to try and coordinate a push in Windows matters. 
> There is a caveat though: I don't have any skin in the GHC-on-Windows game, 
> so I will want to move on to other things afterwards.


I think I’m fairly behind on the current build process of GHC, but as I do use 
GHC mainly on Windows, at such a time as you would like to move on to other 
things, I would certainly throw my hat In the ring.


Cheers,

Tamar










From: Gintautas Miliauskas
Sent: ‎Thursday‎, ‎October‎ ‎2‎, ‎2014 ‎22‎:‎32
To: Simon Peyton Jones
Cc: Randy Polen, kyra, Marek Wawrzos, Tamar Christina, Roman Kuznetsov, Neil 
Mitchell, ghc-devs@haskell.org





Hi,




> All we need is someone to act as convenor/coordinator and we are good to go.  
> Would any of you be willing to play that role?




Indeed, the next thing I was going to ask was about expediting the decision 
process. I would be happy to try and coordinate a push in Windows matters. 
There is a caveat though: I don't have any skin in the GHC-on-Windows game, so 
I will want to move on to other things afterwards.









An advantage of having a working group is that you can decide things.  At the 
moment people often wait for GHC HQ to make a decision, and end up waiting a 
long time.  It would be better if a working group was responsible for the 
GHC-on-Windows build and then if (say) you want to mandate msys2, you can go 
ahead and mandate it.  Well, obviously consult ghc-devs for advice, but you are 
in the lead.  Does that make sense?




Sounds great. The question still remains about making changes to code: is there 
a particular person with commit rights that we could lean on for code reviews 
and committing changes to the main repository?

 




I think an early task is to replace what Neil Mitchell encountered: FIVE 
different wiki pages describing how to build GHC on Windows.  We want just one! 
 (Others can perhaps be marked “out of date/archive” rather than deleted, but 
it should be clear which is the main choice.)




Indeed, it's a bit of a mess. I intended to shape up the msys2 page to serve as 
the default, but wanted to see more testing done before before dropping the 
other pages.

 




I agree with using msys2 as the main choice.  (I’m using it myself.)  It may be 
that Gintautas’s page 
https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2 is 
already sufficient.  Although I’d like to see it tested by others.  For 
example, I found that it was CRUCIAL to set MSYSYSTEM=MINGW whereas Gintautas’s 
page says nothing about that. 




Are you sure that is a problem? The page specifically instructs to use the 
msys64_shell.bat script (through a shortcut) that is included in msys2, and 
that script takes care of setting MSYSTEM=MINGW64, among other important things.







Other small thoughts:

·We started including the ghc-tarball stuff because when we relied 
directly on the gcc that came with msys, we kept getting build failures because 
the gcc that some random person happened to be using did not work (e..g. they 
had a too-old or too-new version of msys).  By using a single, fixed gcc, we 
avoided all this pain.




Makes sense. Just curious: why is this less of a problem on GNU/Linux distros 
compared to msys2? Does msys2 see comparatively less testing, or is it 
generally more bleeding edge?







·I don’t know what a “rubenvb” build is, but I think you can go ahead 
and say “use X and Y in this way”.  The important thing is that it should be 
reproducible, and not dependent on the particular Cygwin or gcc or whatever the 
that user happens to have installed.

A "rubenvb" build is one of the available types of prebuilt binary packages of 
mingw for Windows. Let's figure out if there is something more mainstream and 
if we can migrate to that.



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

Re: GHC on Windows (extended/broad discussion)

[lonetiger]

Hi Gintautas,


Is it possible for you to add the rest of next week to the schedule times? I’m 
unavailable on the given dates.


Kind Regards,

Tamar





From: Gintautas Miliauskas
Sent: ‎Thursday‎, ‎October‎ ‎30‎, ‎2014 ‎16‎:‎34
To: Simon Peyton Jones
Cc: kyra, ghc-devs@haskell.org









On Tue, Oct 28, 2014 at 11:02 PM, Simon Peyton Jones  
wrote:




The people problem is tricky. At work, this would be the right time to do a 
video chat and at least see the faces of the other people involved. Would folks 
be interested in a Skype/Hangout sometime? It would be interesting to hear what 
interests / skills / resources / constraints we have between us.

 

I think that’s a great idea, thanks.  It’s easier to work with people with whom 
you have formed a personal relationship, and a video conf is a good way to do 
that.



Let's try that. Shall we try to find a good timeslot? Sign up at 
http://doodle.com/34e598zc7m8sbaqm

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

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1

[lonetiger]

Hi,


I’ve had some issues building this (and the git HEAD), it seems that the 
config.guess and config.sub in the libffi tarball is old, it doesn’t detect the 
platform when building with msys2. I had to unpack the tarfile and update the 
files, after this it correctly built.


Then I proceeded to try to make a shared library and got the following warning:


ManualCheck.hs:18:1: Warning:
the 'stdcall' calling convention is unsupported on this platform,
treating as ccall
When checking declaration:
  foreign export stdcall "testFoo" testFooA :: CInt -> IO (FooPtr)



Does this mean that GHC no longer supports stdcall on windows? or could this be 
related to issue I had building?


Regards,

Tamar





From: Austin Seipp
Sent: ‎Tuesday‎, ‎December‎ ‎23‎, ‎2014 ‎15‎:‎36
To: ghc-devs@haskell.org, glasgow-haskell-us...@haskell.org





We are pleased to announce the first release candidate for GHC 7.10.1:

https://downloads.haskell.org/~ghc/7.10.1-rc1/

This includes the source tarball and bindists for 64bit/32bit Linux
and Windows. Binary builds for other platforms will be available
shortly. (CentOS 6.5 binaries are not available at this time like they
were for 7.8.x). These binaries and tarballs have an accompanying
SHA256SUMS file signed by my GPG key id (0x3B58D86F).

We plan to make the 7.10.1 release sometime in February of 2015. We
expect another RC to occur during January of 2015.

Please test as much as possible; bugs are much cheaper if we find them
before the release!

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Linker questions

[lonetiger]

Hi *,

I had a few questions about the linker I was hoping someone can help me with,
I'm pretty new to it so any insights would be appreciated.

1) Has to do with checkProddableBlock and #10672 and #10563

static void checkProddableBlock (ObjectCode *oc, void *addr, size_t size ) 
{ 
   ProddableBlock* pb; 

   for (pb = oc->proddables; pb != NULL; pb = pb->next) { 
  char* s = (char*)(pb->start); 
  char* e = s + pb->size; 
  char* a = (char*)addr; 
  if (a >= s && (a+size) <= e) return; 
   } 
   barf("checkProddableBlock: invalid fixup in runtime linker: %p", addr); 
} 

>From what I have found, these errors seem to happen because oc->proddables is 
>initially NULL, 
the for loop is skipped. From what I can tell, this function is checking if 
there's a "proddable"
that fits within the supplied address and size. So if there is no proddables to 
begin with, should this
check just not be skipped and the callee of this call not use this ObjectCode 
instead of erroring out?

2) The second question is about static int ocGetNames_PEi386 ( ObjectCode* oc ) 
I am getting a test failure because it is claiming that .eh_frame section is 
misaligned.
This comes from this code:

  if (kind != SECTIONKIND_OTHER && end >= start) { 
   if size_t)(start)) % 4) != 0) { 
   errorBelch("Misaligned section %s: %p", (char*)secname, start); 
   stgFree(secname); 
   return 0; 
   } 

Where start is defined as:

start = ((UChar*)(oc->image)) + sectab_i->PointerToRawData;
and  oc->image is a memory location received by allocateImageAndTrampolines.

In the case of my test failure it is because the .eh_frame section seems to 
begin at 0x30F
since oc->image will always be 4 aligned (so it doesn't really matter in the 
check) it gives that error because PointerToRawData isn't aligned by 4.

So my question is would it not be better just to check the alignment flag in 
the PE section header instead of checking the load address (which is always 
going to aligned to 4?) and The file pointer to 
the first page of the section within the COFF file to determine the alignment? 
Like objdump and dumpbin do?

e.g.

9 .eh_frame 0038      030f  2**2
  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
  
Is the output from objdump which correctly determines the alignment from the 
section. From what I understand from the PE specification
the on disk address doesn't have to be aligned by 4:

"For object files, the value *should* be aligned on a 4-byte boundary for best 
performance."

I'm wondering if we are incorrectly erroring out here, instead of using the 
section and making sure we pad it to the alignment boundary.

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

RE: Linker questions

[lonetiger]

Hi Richard,

Thanks for the reply, I completely forgot that most people were probably on 
holidays ☺

I’ll try the irc channel as well.

Cheers,
Tamar



From: Richard Eisenberg
Sent: Friday, August 14, 2015 04:46
To: loneti...@gmail.com
Cc: GHC
Subject: Re: Linker questions


Hi Tamar,

I haven't a clue about any of this. But I didn't want your detailed email to go 
without any response. Perhaps agitate a bit on #ghc at freenode to get some 
attention? Also, be aware that many people are on holiday right now, and so 
responses may be slower than at other times.

Sorry I can't be more helpful, but I definitely appreciate your looking into 
this!
Richard

On Aug 11, 2015, at 3:43 PM, loneti...@gmail.com wrote:


Hi *,
 
I had a few questions about the linker I was hoping someone can help me with,
I'm pretty new to it so any insights would be appreciated.
 
1) Has to do with checkProddableBlock and #10672 and #10563
 
static void checkProddableBlock (ObjectCode *oc, void *addr, size_t size )
{
   ProddableBlock* pb;
 
   for (pb = oc->proddables; pb != NULL; pb = pb->next) {
  char* s = (char*)(pb->start);
  char* e = s + pb->size;
  char* a = (char*)addr;
  if (a >= s && (a+size) <= e) return;
   }
   barf("checkProddableBlock: invalid fixup in runtime linker: %p", addr);
}
 
>From what I have found, these errors seem to happen because oc->proddables is 
>initially NULL,
the for loop is skipped. From what I can tell, this function is checking if 
there's a "proddable"
that fits within the supplied address and size. So if there is no proddables to 
begin with, should this
check just not be skipped and the callee of this call not use this ObjectCode 
instead of erroring out?
 
2) The second question is about static int ocGetNames_PEi386 ( ObjectCode* oc )
I am getting a test failure because it is claiming that .eh_frame section is 
misaligned.
This comes from this code:
 
  if (kind != SECTIONKIND_OTHER && end >= start) {
   if size_t)(start)) % 4) != 0) {
   errorBelch("Misaligned section %s: %p", (char*)secname, start);
   stgFree(secname);
   return 0;
   }
 
Where start is defined as:
 
start = ((UChar*)(oc->image)) + sectab_i->PointerToRawData;
and  oc->image is a memory location received by allocateImageAndTrampolines.
 
In the case of my test failure it is because the .eh_frame section seems to 
begin at 0x30F
since oc->image will always be 4 aligned (so it doesn't really matter in the 
check) it gives that error because PointerToRawData isn't aligned by 4.
 
So my question is would it not be better just to check the alignment flag in 
the PE section header instead of checking the load address (which is always 
going to aligned to 4?) and The file pointer to
the first page of the section within the COFF file to determine the alignment? 
Like objdump and dumpbin do?
 
e.g.
 
9 .eh_frame 0038      030f  2**2
  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
 
Is the output from objdump which correctly determines the alignment from the 
section. From what I understand from the PE specification
the on disk address doesn't have to be aligned by 4:
 
"For object files, the value *should* be aligned on a 4-byte boundary for best 
performance."
 
I'm wondering if we are incorrectly erroring out here, instead of using the 
section and making sure we pad it to the alignment boundary.
 
Regards,
Tamar
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



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

RE: Window build broken

[lonetiger]

Hi Simon,

I’m wondering what environment you’re coming in, is it msys2? The prompt you 
showed earlier
/cygdrive/c/code/HEAD-1$
Looks like cygwin.

Tamar

From: Simon Peyton Jones
Sent: Wednesday, November 18, 2015 00:25
To: David Macek;ghc-devs@haskell.org
Subject: RE: Window build broken


It says this:

bash$ file libraries/ghc-prim/dist-install/build/HSghc-prim-0.5.0.0.o 
libraries/ghc-prim/dist-install/build/HSghc-prim-0.5.0.0.o: PE Unknown PE 
signature 0x742e x86-64 (stripped to external PDB), for MS Windows

| -Original Message-
| From: David Macek [mailto:david.mace...@gmail.com]
| Sent: 17 November 2015 22:45
| To: Simon Peyton Jones ; ghc-devs@haskell.org
| Subject: Re: Window build broken
| 
| On 17. 11. 2015 23:31, Simon Peyton Jones wrote:
| > Sigh.  My Windows build is broken.  See below.  Any ideas?  The stage2
| complier in non-interactive mode works ok. It’s just ghci fails.  What does
| “Not x86_64 PEi386” mean?  What can I do to fix?
| 
| Maybe it's obvious and you already checked, but could it be that the object
| file is for a different architecture? What does `file` say about it?
| 
| --
| David Macek

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


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

RE: Window build broken

[lonetiger]

Well the error is correct, it’s just checking against the machine type in the 
PE spec:

IMAGE_FILE_MACHINE_AMD64
0x8664
x64
So somewhere along the line an invalid PE file was generated (or for the wrong 
architecture).

From: Ryan Scott
Sent: Wednesday, November 18, 2015 00:44
To: ghc-devs@haskell.org
Subject: Re: Window build broken


Wow, I happened to try building GHC on Windows for the first time ever
today, and I also experienced this error :)

Interestingly, someone reported a very similar error to this on Trac,
but for GHC 7.8.3 [1]. Here's where the error message comes from [2]
in Linker.c:

static int verifyCOFFHeader
(COFF_header *hdr, pathchar *fileName)
{
  if (hdr->Machine != 0x8664) {
errorBelch("%" PATH_FMT ": Not x86_64 PEi386", fileName);
return 0;
  }
  ...
}

Ryan S.
-
[1] https://ghc.haskell.org/trac/ghc/ticket/10437
[2] 
https://github.com/ghc/ghc/blob/233d1312bf15940fca5feca6884f965e7944b555/rts/Linker.c#L3355
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


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

RE: Window build broken

[lonetiger]

➢  Perhaps it is.  Should I blow it away and re-install?

I’d hold on that this. I have just tried building myself and also hit it.

Taking a closer look, it seems that the .o file being produces isn’t an object 
file but an image file. It contains the standard image headers and a PE 
signature.

GHC is doing the right thing in error out here. I think this is coming from 
D1242, there’s a linker script in there driver/utils/merge_sections.ld that’s 
causing ld on windows to output an image file instead of an object file.

I’m afraid I am not familiar enough with ld to offer a proper fix, but to get 
you working again:

In rules/build-package-way.mk on line 154, remove the “$(if $(filter 
YES,$(LdIsGNULd)),-T $$($1_$2_LD_SCRIPT))” bit.

That should get It working again.

Regards,
Tamar


From: Simon Peyton Jones
Sent: Wednesday, November 18, 2015 14:39
To: Tamar Christina;David Macek;ghc-devs@haskell.org
Subject: RE: Window build broken


|  Presumably Simon didn't change this. Maybe the msys2 install is broken?

Perhaps it is.  Should I blow it away and re-install?

One other difficulty is that (before my machine change) I tried to follow the 
instructions on 
https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows to install 
64-bit msys2; but I had a series of problems that Ben G was unable to get to 
the bottom of.  Particularly I could not run bash from emacs; the emacs shell 
window never got as far as a prompt.  So I backed off.  As far as I know that 
is still broken.

I think I have not tried the "32-bit msys2 installer" on that page.  Maybe that 
should be my next step?

Regardless, it's hard to see how any of this concerns the error message I was 
getting.  As lonetiger said, it looks very similar to 
https://ghc.haskell.org/trac/ghc/ticket/10437

What next?

Simon

|  -Original Message-
|  From: Tamar Christina [mailto:loneti...@gmail.com]
|  Sent: 18 November 2015 09:14
|  To: David Macek; Simon Peyton Jones; ghc-devs@haskell.org
|  Subject: RE: Window build broken
|  
|  Hmm,
|  
|  Presumably Simon didn't change this. Maybe the msys2 install is broken?
|  
|  TamarFrom: David Macek
|  Sent: ‎18/‎11/‎2015 09:35
|  To: Simon Peyton Jones; loneti...@gmail.com; ghc-devs@haskell.org
|  Subject: Re: Window build broken
|  On 18. 11. 2015 9:29, Simon Peyton Jones wrote:
|  > It’s msys2.  I don’t have Cygwin on this machine.  I have no idea where
|  that prompt comes from, but I agree it’s suspicious.
|  
|  Looks like your /etc/fstab is wrong. There should be a line like this one,
|  that removes the `cygdrive` prefix from Windows drive/letter
|  mounts:
|  
|  none / cygdrive binary,posix=0,noacl,user 0 0
|  
|  --
|  David Macek


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

Marge bot review link

[lonetiger]

Hi Ben,

I’m wondering if it’s possible to get marge to amend the commit message before 
it merges it to include links to the review requests.

I really miss that phab feature..

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

RE: CoreToStg Asserts

[lonetiger]

Hi Ömer,

Thanks for the pointers, should help me find out more.

It’s not a stock GHC as I’m working on getting Dynamic linking back on Windows.

This assert is triggered on the dyn version of the libs. So something’s bit 
rotted here.

Cheers,
Tamar

From: Ömer Sinan Ağacan
Sent: Tuesday, June 14, 2016 18:46
To: Phyx
Cc: ghc-devs@haskell.org
Subject: Re: CoreToStg Asserts

Hi Tamar,

Have a look at Note [Disgusting computation of CafRefs] in TidyPgm.hs. The
assertion triggered here is the one that checks `hasCafRefs` mentioned in that
note matches with actual CAF-ness.

Are you using stock GHC? Which version? Do you have a minimal program that
reproduces this?

2016-06-13 7:01 GMT-04:00 Phyx :
> Hi *,
>
> I'm hoping someone could help me understand what the asserts in CoreToStg on
> line 240 and 216 are trying to tell me.
>
> I hit both of them while trying to compile libraries as dyn.
>
> WARNING: file compiler\stgSyn\CoreToStg.hs, line 250
>   $trModule2 False True
> ghc-stage1.exe: panic! (the 'impossible' happened)
>   (GHC version 8.1.20160612 for x86_64-unknown-mingw32):
> ASSERT failed!
>   file compiler\stgSyn\CoreToStg.hs line 216 $trModule2
>
> Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
>
> WARNING: file compiler\simplCore\SimplCore.hs, line 633
>   Simplifier bailing out after 4 iterations [6737, 736, 51, 9]
> Size = {terms: 12,990, types: 9,998, coercions: 443}
> WARNING: file compiler\stgSyn\CoreToStg.hs, line 250
>   $fEqBigNat_$c/= False True
> ghc-stage1.exe: panic! (the 'impossible' happened)
>   (GHC version 8.1.20160612 for x86_64-unknown-mingw32):
> ASSERT failed!
>   file compiler\stgSyn\CoreToStg.hs line 240
>   [$fEqBigNat_$c/=, $fEqBigNat]
>
> Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
>
> Kind Regards,
> Tamar
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

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

RE: CoreToStg Asserts

[lonetiger]

Ah, thanks Simon!

This helps a lot.

Cheers,
Tamar

From: Simon Peyton Jones
Sent: Wednesday, June 15, 2016 13:07
To: loneti...@gmail.com; Ömer Sinan Ağacan
Cc: ghc-devs@haskell.org
Subject: RE: CoreToStg Asserts

Ah yes.  This is a long-standing wart:
1. The CoreTidy pass predicts what will be CAFFY (see 
https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/GC/CAFs). It 
predicts that info because the output of CoreTidy is what goes into interface 
files.
2. The CorePrep pass messes the code a bit
3. The CoreToStg pass coverts to STG, and at that point we know for sure what 
will be CAFFY and what will not

The assert trips when the predication in (1) doesn’t agree with reality in (3).

It would be Much Much better if we took the info from (3) and used that to 
drive the Core-to-IfaceSyn conversion that creates the interface file content.

The only reason not to do this is that it’d mean delaying Core-to-IfaceSyn 
until pass (3) had happened.. possibly bad for space.  But maybe it’s a 
non-issue in practice.

See https://ghc.haskell.org/trac/ghc/ticket/9718

Windows interacts with this because with DLLs some pointers that would be 
static closures turn into thunks (I think).  See StgSyn.isDllConApp, and 
TidyPgm.hasCafRefs 
Simon


From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of 
loneti...@gmail.com
Sent: 15 June 2016 00:26
To: Ömer Sinan Ağacan 
Cc: ghc-devs@haskell.org
Subject: RE: CoreToStg Asserts


Hi Ömer,

Thanks for the pointers, should help me find out more.

It’s not a stock GHC as I’m working on getting Dynamic linking back on Windows.

This assert is triggered on the dyn version of the libs. So something’s bit 
rotted here.

Cheers,
Tamar

From: Ömer Sinan Ağacan
Sent: Tuesday, June 14, 2016 18:46
To: Phyx
Cc: ghc-devs@haskell.org
Subject: Re: CoreToStg Asserts

Hi Tamar,

Have a look at Note [Disgusting computation of CafRefs] in TidyPgm.hs. The
assertion triggered here is the one that checks `hasCafRefs` mentioned in that
note matches with actual CAF-ness.

Are you using stock GHC? Which version? Do you have a minimal program that
reproduces this?

2016-06-13 7:01 GMT-04:00 Phyx :
> Hi *,
>
> I'm hoping someone could help me understand what the asserts in CoreToStg on
> line 240 and 216 are trying to tell me.
>
> I hit both of them while trying to compile libraries as dyn.
>
> WARNING: file compiler\stgSyn\CoreToStg.hs, line 250
>   $trModule2 False True
> ghc-stage1.exe: panic! (the 'impossible' happened)
>   (GHC version 8.1.20160612 for x86_64-unknown-mingw32):
> ASSERT failed!
>   file compiler\stgSyn\CoreToStg.hs line 216 $trModule2
>
> Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
>
> WARNING: file compiler\simplCore\SimplCore.hs, line 633
>   Simplifier bailing out after 4 iterations [6737, 736, 51, 9]
> Size = {terms: 12,990, types: 9,998, coercions: 443}
> WARNING: file compiler\stgSyn\CoreToStg.hs, line 250
>   $fEqBigNat_$c/= False True
> ghc-stage1.exe: panic! (the 'impossible' happened)
>   (GHC version 8.1.20160612 for x86_64-unknown-mingw32):
> ASSERT failed!
>   file compiler\stgSyn\CoreToStg.hs line 240
>   [$fEqBigNat_$c/=, $fEqBigNat]
>
> Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
>
> Kind Regards,
> Tamar
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


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

RE: msys2 64 bit: help help!

[lonetiger]

Hi Simon,

To test if it’s AD try (in case my other email didn’t get through):

➢ you may be hitting a long standing issue some computers have in which the 
domain controller is being hit for every invocation of commands, causing a 
slowdown https://github.com/Alexpux/MSYS2-packages/issues/138 , Solution 2 from 
https://gist.github.com/k-takata/9b8d143f0f3fef5abdab seems to fix it for most 
people.

Cheers,
Tamar

From: Simon Peyton Jones via ghc-devs___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: msys2 64 bit: help help!

[lonetiger]

Hi Simon,

I think the two issues might be related. From what I can tell magit invokes 
some msys utilies at startup such as cygdrive to normalize paths 
https://github.com/magit/magit/issues/2284 . The msys AD issue would affect all 
of these tools and so each of them would be quite slow to run.

I would indeed try the AD fix first and see how the rest behave.

This issue is well documented at the Cygwin FAQ as well 
https://cygwin.com/faq/faq.html#faq.using.startup-slow if you’re interested in 
what’s 
Going on. Basically what it’s saying is that you can cache your user 
information (username etc) locally instead of having it query the server 
everytime.

If this doesn’t solve the magit problem as well, then try issuing a normal git 
command, if that’s slow as well then run strace on it and it should give
You an idea of what’s taking so long.

Kind Regards,
Tamar

From: Simon Peyton Jones via ghc-devs___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Msys2 64: progress

[lonetiger]

Hi Simon,

You’re missing an underscore in the command (there’s one between x86 and 64), 

It’s pacman -R mingw-w64-x86_64-curl

This is only needed if curl --version reports anything other than 
x86_64-pc-msys.
After that you need to install the normal msys curl with pacman -S curl

You don’t have to run configure everytime to test either, you can just run

mk/get-win32-tarballs.sh download x86_64

from the root and it should just download the packages only if everything is 
setup correctly.

Also don’t forget to do a pacman -Sy to update the repositories. Couldn’t 
gather from your email if you did this already.

Kind Regards,
Tamar

From: Simon Peyton Jones via ghc-devs___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Msys2 64: progress

[lonetiger]

Hi Simon,

I’m not sure what’s going on there.

I updated my curl to 7.49.1 and I am experiencing the same silent death 
(--version doesn’t even work for me then which is weird).

In any case, downgrading back to 7.48.0 worked for me.

I don’t know how to do that with pacman, so instead maybe try:

pacman -S wget
wget -qO - http://repo.msys2.org/msys/x86_64/libcurl-7.48.0-1-x86_64.pkg.tar.xz 
| tar xJ -C /usr --strip-components=1
wget -qO - http://repo.msys2.org/msys/x86_64/curl-7.48.0-1-x86_64.pkg.tar.xz | 
tar xJ -C /usr --strip-components=1

If it doesn’t work, to upgrade again to 7.49.1 you can just do pacman -S curl 
libcurl

Kind Regards,
Tamar

From: Simon Peyton Jones___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Msys2 64: progress

[lonetiger]

Hi Simon,

I think you’re right, 
That pattern in the error is the one we pass to find

find "${base_dir}" -name "*.tar.xz" -exec tar xfJ {} \;

on line 334 of configure.ac which is supposed to unpack the files. 
That the download script doesn’t output nothing makes sense now since the 
hashes of the files match.

I *think* what’s going on here is that for some reason you don’t have findutils 
installed and it’s instead using
The windows “find” utility, which generates that error. 

C:\Users\Tamar>find *.tar.xz
File not found - *.tar.xz

Try re-installing findutils, pacman -S findutils, and if find –version doesn’t 
return the findutils one check your PATH settings.

Cheers,
Tamar

From: Simon Peyton Jones___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Msys2 64: progress

[lonetiger]

Hi Simon,

Could you try with python2 instead? (If it’s installed I think the testsuite 
would pick it up automatically).

Python3 is marked as experimental in the testsuite

PYTHON3 = sys.version_info >= (3, 0)
if PYTHON3:
print("*** WARNING: running testsuite using Python 3.\n"
  "*** Python 3 support is experimental. See Trac #9184.")

And based on that trac, it routinely breaks..

Regards,
Tamar

From: Simon Peyton Jones___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Windows build

[lonetiger]

Hi Simon,

For these tests it shouldn’t matter much so I guess I can change them.

The Windows Build guide does ask to put /mingw64/bin/ on your path.
The reason I tend not to want to use GHC to compile my c files for the tests is 
that GHC doesn’t just pass the commands along to gcc.
It adds to them. While for these single object files it doesn’t matter (as it 
just adds a few defines and include paths) It has bitten me multiple times in 
the past. Particularly when compiling shared libraries for tests since GHC 
wants to link in the RTS, which makes the files considerably larger and harder 
to debug so
I tend to avoid using GHC to compile just pure C code.

It means (with shared libraries) that I’ll end up with multiple RTSs loaded (at 
least in memory, which means stepping in gdb I have to keep track of the memory 
locations so I know which one I’m in). So I really wish there was a way  to 
tell GHC not to do this.

Also you’ll likely be linking against libraries compiled against other versions 
of GCC or MSVC so that shouldn’t be an issue.

I’ll change the tests tomorrow, but I would much prefer if the testsuite can 
tell me where the GCC to use is, so I don’t have to use GHC.

Regards,
Tamar

From: Simon Peyton Jones via ghc-devs
Sent: Friday, July 8, 2016 22:27
To: ghc-devs@haskell.org
Subject: Windows build

I’ve completed a successful build on my Surface Book!  Thank you.

One last glitch. I’m getting the validate failure bellow.

No other test requires gcc in my path.  GHC itself carefully navigates to its 
own private gcc.   Do we really want this family of tests (half a dozen 
variants of T11223) to rely on some random gcc, which might or might not be the 
same as GHC is using?  Shouldn’t we use ‘ghc foo.c’?

Simon

=> T11223_simple_unused_duplicate_lib(normal) 3371 of 5211 [0, 6, 1]
cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-hFCtmi/test   
spaces/./rts/T11223/T11223_simple_unused_duplicate_lib.run" && $MAKE -s 
--no-print-directory t_11223_simple_unused_duplicate_lib  
Wrong exit code (expected 0 , actual 2 )
Stdout:

Stderr:
/bin/sh: gcc: command not found
make[2]: *** [Makefile:42: t_11223_simple_unused_duplicate_lib] Error 127


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

RE: Proposal process status

[lonetiger]

+1 from me for keeping the two separate as well. While GHC may be the obviously 
prevalent Haskell compiler it is a far from the only one,
And I’d hate to have to look at a proposal for adding an extension to GHC 
(which would be riddled with GHC specific implementation specifics) 
Rather than a clean specification.

Maybe I’m naïve but I also see the Haskell committees as doing more than just 
copy pasting what’s worked. But also evaluate how it can be done
Better. I can perfectly well see situations where the implementation in GHC 
ended up being less useful than It should be just because of 
Implementation quirks/difficulties in GHC. 

Cheers,
Tamar 

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

RE: Test T12504 on Windows

[lonetiger]

I believe you forgot to press Reply-All Richard.

In any case a fix is up at https://phabricator.haskell.org/D2537

Sorry, should have caught this during review.

Tamar

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

A few technical suggestions

[lonetiger]

Hi All,

I wanted to give my own thoughts/suggestions for things we could do on the 
short/medium term
To make things a bit better. As a whole I may be one of the few who likes the 
current setup so I 
Propose enhancing the current toolset.

I find the mail patch to mailing list approach of GCC et al quite cumbersome to 
be honest.
And the discussion quickly becomes hard to follow as it branches  lot.

My proposals (sorry for the brevity, I can expand if needed):

* Link phab to github
 Phabricator seems to have build in OAuth support.
 As you'll likely need a github account anyway, why not
 also support github logins? This would reduce the barrier of
 needing multiple accounts that is often a complaint.
 
 Would it be possible to maybe also extract the user's public
 key from github automatically? That would reduce one of the barriers as well.
 
https://secure.phabricator.com/book/phabricator/article/configuring_accounts_and_registration/

* Link Trac to github
 - used to login (OAuth support)
 - readonly issues (to begin with?).
   we already have a code mirror, why not mirror more content.
 - sync issues back between the two
 - gives us an ability to see which github users an issue affects
   since they can then reference it.
 - updates the users when an issue is fixed since it will be closed on GH.
 - Gives us an indication of the importance of the tickets

 As a whole, I find Trac MUCH better for ticket triaging than Github or Phab,
 both of which seem to be quite bare and simple in what they provide. I am not
 in favor of ditching it. Also we have and continue to accept patches just 
uploaded
 to Trac as a diff. We tend to ask people to upload it to phab for better 
reviews
 and so it's attributed to them when we commit. Some don't (and we then do it 
ourselves),
 most due. If they don't need another login then I suspect almost all would.
 
 There's a (seemingly) actively maintained project that does all the above, 
could we leverage it?
 https://github.com/trac-hacks/trac-github
 
* There is a trac plugin to generate a new section on trac
  /doc which allows you to render and edit documentations checked into repo.
  Could this be used to allow easier editing of non generated documentation?
  
  It's currently based on SVN, but maybe a git one exists too?
  https://github.com/trac-hacks/tracdocs

* Newcomers
 - Expose newcomers information more by creating a new landing page
 - Clean up build instructions. For windows, I have scripts to automate setup.
   Often heard complain is that it is hard, but never hear why it's hard.
   
   In any case, my setup script for a 100% unattended build env setup for 
Windows
   are here: https://github.com/Mistuke/GhcDevelChoco/releases
   
   These are entirely self contained environments that can be removed by a 
simple rm -rf /.
   You can have as many as you want on the same machine without them 
interfering with eachother
   or with whatever else you might have done to your GHC already installed.
   
   It's not 100% production ready but it works and does so well.

* Updated Phab reviewers list to be more automated
 - Assign reviewers next to the static list (as is currently done)
   to maybe also include significant contributors to that file?
   
   The reason for this is that currently it's always the same people reviewing 
patches.
   Their time is spread thin. Particularly on less popular platforms it 
basically comes
   down to 4 people.
 
* Update trac linters and pre-commit linters to be the same.
 - particularly reject summaries that would be rejected on commit.
   Often when I try landing patches (especially from others) I have to
   edit the summary. Maybe arc should reject the diff if a push would fail?
   
   Also I want to say I love the summary document you have to fill in.
   It ensures useful information is there later when I have to find out why
   a change was made. So whatever we do, don't remove this.

* Phab plugin to on signup ask for public key if none found.
 - It's recently been made a requirement to require a public key to push to 
phab.
   The error you get when you don't do this and try to push a patch is very very
   cryptic and unintuitive. Could we make a plugin that asks the user to upload
   a public key on trac if they haven't done so? Like a banner at the top?

* Automate trac tickets
 - Particular on new tickets post a friendly reminder that if they want they 
can give it a hand in fixing it themselves.
 - Parse information added, in particular check if reproduction steps are there 
etc.
 - If stack is used, kindly ask if a repo without can be used. The amount of 
bug reports with stack is increasing and regardless of my own opinion on the 
tool, these reports are not very useful as is.
 - Maybe automatically CC people from a pool based on the information in the 
ticket? I tend to miss tickets because my filters are quite strict. Generally 
if the ticket doesn't mention my name, is directed at me or has "Windows" in 
the bod

Default options for -threaded

[lonetiger]

Hi All,

A user on https://ghc.haskell.org/trac/ghc/ticket/11054 has asked why 
-N -qa isn’t the default for -threaded.

I’m afraid I don’t know a good reason why it’s not. Can anyone help shed some 
light on this?

If there is no good reason, Would anyone object to making it the default?

Thanks,
Tamar

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

RE: Aargh! Windows build is broken AGAIN

[lonetiger]

Hi Simon,

Sorry for the broken build again. Since your last email I do run a nightly 
build, but you were about an hour and a half before today’s build!

Anyway, I believe the offending commit is 
8c6a3d68c0301bb985aa2a462936bbcf7584ae9c ,
This unconditionally adds GHC.Event which then includes that TimerManager which 
is defined for POSIX only. 

Reverting that should get you building again. 

Cheers,
Tamar

From: Simon Peyton Jones via ghc-devs
Sent: Friday, October 14, 2016 22:38
To: ghc-devs@haskell.org
Subject: Aargh! Windows build is broken AGAIN

I really wish I did not have to be the Windows integration server.
Currently, from a clean build of HEAD, I’m getting
libraries\base\GHC\Event\TimerManager.hs:62:3: error:
 error: #error not implemented for this operating system
 # error not implemented for this operating system
   ^
I’d revert something if I could, but I can’t see what to revert.  Help, please!
Simon

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

RE: Aargh! Windows build is broken AGAIN

[lonetiger]

Seems I forgot to do a reply all…

From: loneti...@gmail.com
Sent: Friday, October 14, 2016 23:23
To: Simon Peyton Jones via ghc-devs
Subject: RE: Aargh! Windows build is broken AGAIN

Hi Simon,

Sorry for the broken build again. Since your last email I do run a nightly 
build, but you were about an hour and a half before today’s build!

Anyway, I believe the offending commit is 
8c6a3d68c0301bb985aa2a462936bbcf7584ae9c ,
This unconditionally adds GHC.Event which then includes that TimerManager which 
is defined for POSIX only. 

Reverting that should get you building again. 

Cheers,
Tamar

From: Simon Peyton Jones via ghc-devs
Sent: Friday, October 14, 2016 22:38
To: ghc-devs@haskell.org
Subject: Aargh! Windows build is broken AGAIN

I really wish I did not have to be the Windows integration server.
Currently, from a clean build of HEAD, I’m getting
libraries\base\GHC\Event\TimerManager.hs:62:3: error:
 error: #error not implemented for this operating system
 # error not implemented for this operating system
   ^
I’d revert something if I could, but I can’t see what to revert.  Help, please!
Simon


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

Testsuite threadsafety

[lonetiger]

Hi *,

I’m trying to understand  a few pieces of code in the testsuite,

As it so happens quite a few tests randomly fail on newer msys2 and python 
installs:

   r:/temp/ghctest-0u4c8o/test   spaces/./th/T12407.run 
   T12407 [ext-interp] ([Error 183] Cannot create a file when that file 
already exists: 'r:/temp/ghctest-0u4c8o/test   spaces/./th/T12407.run')
   r:/temp/ghctest-0u4c8o/test   spaces/./th/T11463.run 
   T11463 [ext-interp] ([Error 183] Cannot create a file when that file 
already exists: 'r:/temp/ghctest-0u4c8o/test   spaces/./th/T11463.run')
   r:/temp/ghctest-0u4c8o/test   spaces/./th/T12478_4.run   
   T12478_4 [ext-interp] ([Error 183] Cannot create a file when that 
file already exists: 'r:/temp/ghctest-0u4c8o/test   spaces/./th/T12478_4.run')
   r:/temp/ghctest-0u4c8o/test   spaces/./th/T12478_3.run   
   T12478_3 [ext-interp] ([Error 183] Cannot create a file when that 
file already exists: 'r:/temp/ghctest-0u4c8o/test   spaces/./th/T12478_3.run')

(I say random, but the set of tests seem to be the same ones, just within that 
group a few randomly pass every so often. It’s mostly TH tests.)

Anyone have any ideas? I’m not very familiar with the internals of the 
testsuite.

Secondly, I’ve noticed all paths in the testsuite are relative paths. And this 
hand me wondering, relative to what. 

I see that in do_test we actually change directories

837 if opts.pre_cmd: 
838 exit_code = runCmd('cd "{0}" && {1}'.format(opts.testdir, 
opts.pre_cmd))

So I am now assuming that the relative paths are relative to the cwd. Which 
brings up the question.. how is this thread safe and working on Linux?

Surely any two tests can change the cwd and then one of them would be writing 
to the wrong place? Am I missing something here?

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

RE: Testsuite threadsafety

[lonetiger]

Thanks!
Had missed the spawning of a new process part.

From: Ben Gamari
Sent: Saturday, October 15, 2016 00:12
To: loneti...@gmail.com; ghc-devs@haskell.org
Subject: Re: Testsuite threadsafety

loneti...@gmail.com writes:

> Hi *,
>
> I’m trying to understand  a few pieces of code in the testsuite,
>
> As it so happens quite a few tests randomly fail on newer msys2 and python 
> installs:
>
>r:/temp/ghctest-0u4c8o/test   spaces/./th/T12407.run   
>  T12407 [ext-interp] ([Error 183] Cannot create a file when that 
> file already exists: 'r:/temp/ghctest-0u4c8o/test   spaces/./th/T12407.run')
>r:/temp/ghctest-0u4c8o/test   spaces/./th/T11463.run   
>  T11463 [ext-interp] ([Error 183] Cannot create a file when that 
> file already exists: 'r:/temp/ghctest-0u4c8o/test   spaces/./th/T11463.run')
>r:/temp/ghctest-0u4c8o/test   spaces/./th/T12478_4.run 
>  T12478_4 [ext-interp] ([Error 183] Cannot create a file when 
> that file already exists: 'r:/temp/ghctest-0u4c8o/test   
> spaces/./th/T12478_4.run')
>r:/temp/ghctest-0u4c8o/test   spaces/./th/T12478_3.run 
>  T12478_3 [ext-interp] ([Error 183] Cannot create a file when 
> that file already exists: 'r:/temp/ghctest-0u4c8o/test   
> spaces/./th/T12478_3.run')
>
> (I say random, but the set of tests seem to be the same ones, just within 
> that group a few randomly pass every so often. It’s mostly TH tests.)
>
> Anyone have any ideas? I’m not very familiar with the internals of the 
> testsuite.
>
> Secondly, I’ve noticed all paths in the testsuite are relative paths. And 
> this hand me wondering, relative to what. 
>
> I see that in do_test we actually change directories
>
> 837 if opts.pre_cmd: 
> 838 exit_code = runCmd('cd "{0}" && {1}'.format(opts.testdir, 
> opts.pre_cmd))
>
If I understand this correctly, this is merely spawning off a child
shell process which then moves its own cwd to opts.testdir. This should
not affect the cwd of the testsuite driver, which means that it should
be perfectly safe.

Cheers,

- Ben

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

RE: Windows Builder Disabled

[lonetiger]

Hi Matthew,

These tests are only run sequential right? As in, Phab doesn’t build two diffs 
concurrently?

If it used to pass then there might be something running on the server 
consuming memory.

The pagefile is probably set to auto, but that means a certain % of the disk, 
if it needs more for some
Reason it won’t grow beyond this maximum.

Someone would need to login to see what’s going on 😊

Tamar

From: Ben Gamari
Sent: Saturday, October 22, 2016 20:39
To: Matthew Pickering; GHC developers; loneti...@gmail.com
Subject: Re: Windows Builder Disabled

Matthew Pickering  writes:

> I have disabled the windows builder as it is consistently failing with
> the same error message.
>
> From this log for example:
> https://phabricator.haskell.org/harbormaster/build/14430/
>
> ghc.exe: getMBlocks: VirtualAlloc MEM_COMMIT failed: The paging file
> is too small for this operation to complete.
> 764ghc.exe: failed to create OS thread: The paging file is too small
> for this operation to complete.
>
Thanks for doing this Matthew!

> Do you have any ideas Ben/Tamar? I can't see any recent commits which
> would have caused this failure.
>
Sadly no. This is quite odd. I'll need to look into this when I get back
from Hac Phi.

Cheers,

- Ben

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

Dynamic Linking help

[lonetiger]

Hi *,

I’ve been working the past 4 or so months on reviving dynamic linking support 
for Windows in a way that has the most chance of working.

My first patch in the series is up on Phabricator and with this patch dynamic 
linking work again, but only for the threaded RTS.

The reason for this is because the core libraries that get distributed with GHC 
get compiled with -threaded and shared libraries on Windows can’t have dangling 
symbols. 

In any case, I’m at the point now where I need to be able to delay the 
selection of the runtime library till the final link. E.g. when the exe or dll 
is made. The problem however is that when linked normally, dependencies are 
satisfied by the Windows loader, before the program is run. One way I could do 
this is with Window’s equivalent to SONAME. Unfortunately this only works with 
SxS Assemblies, and I’ll need Admin rights to be able to register the shared 
libraries.

This is a problem for running tests in the testsuite using the inplace GHC.

Typically on Windows the way you would do this is by delay loading the dll. 
This allows me to write some code on startup and manually load the runtime dll. 
The Windows loader would then just use the loaded dll. Unfortunately delay 
loading does not support const extern data. Such as const extern RtsConfig 
defaultRtsConfig; 

The RTS/GHC is full of such usage so it won’t be easy to change. Though I’d 
only have to change those exposed by Rts.h.

So I have two options:
1) Replace all const externs with a function call. This would work, but isn’t 
ideal because it would break if someone in the future adds a new data entry 
instead of a function. And we have an extra function call everywhere.

2) I could do some hacks on the Windows side, e.g. compile the program to a 
shared library, embed the shared library inside the exe and on startup after 
loading the propert rts, load the DLL from (mmapped) memory and run the code.

I don’t like either approach and am hoping someone here has a better solution 
for me.

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

RE: Dynamic Linking help

[lonetiger]

Hi Ben,

Thanks for the reply!

> 
> > Hi *,
> >
> > I’ve been working the past 4 or so months on reviving dynamic linking
> > support for Windows in a way that has the most chance of working.
> >
> > My first patch in the series is up on Phabricator and with this patch
> > dynamic linking work again, but only for the threaded RTS.
> >
> Thanks for all of your work on this, Tamar!
> 

Home stretch :)

> 
> > The reason for this is because the core libraries that get distributed
> > with GHC get compiled with -threaded and shared libraries on Windows
> > can’t have dangling symbols.
> >
> Let me make sure we are on the same page here: By "dangling symbols" do
> you just mean symbols that the linker did not find a definition for at
> link time (e.g. as is the case with libHSrts symbols when we link
> libHSbase)?

Yes, indeed.

> 
> > In any case, I’m at the point now where I need to be able to delay the
> > selection of the runtime library till the final link. E.g. when the
> > exe or dll is made. The problem however is that when linked normally,
> > dependencies are satisfied by the Windows loader, before the program
> > is run. One way I could do this is with Window’s equivalent to SONAME.
> > Unfortunately this only works with SxS Assemblies, and I’ll need Admin
> > rights to be able to register the shared libraries.
> >
> Hmm, why? I thought recent Windows releases had a notion of "user local"
> installation, no? From what little I have heard it sounds like SxS
> assemblies is the right solution here.

Yes, so to be clear, SxS absolutely solve this problem. For final installs.
The majority of the issue is that the testsuite won't have the assemblies in
the SxS cache.

There *is* a sort of RPATH equivalent for SxS that can be used here, it however
has two problems:
1) Even though the API has no such limit, the implementation in the Windows 
loader
   limits it per application to 5 entries. Obviously this won't be enough. 
   So this is absolutely another option (maybe even preferable now that I think 
about it
   since it require almost no code change, mostly some build system changes.).
   Can do either one of two things:
   a) Copy all dll's to the lib folder when they're compiled instead of leaving 
them in place and
  add a single SxS search entry to find them.
   b) Turn of SxS in the testsuite for any Assemblies not the RTS, and add the 
inplace RTS directory to
  the SxS search path. Since it's only the RTS that's an issue.
  
2) The other problem is that the paths specified have to be relative to the 
application.
   (Of the top of my head) It doesn't support absolute paths. Which means I 
can't have GHC generate the entry because I have no idea where the testsuite 
intends to run the binary.
   One way around this is to have the testsuite generate the needed config 
file. That should be do-able.
   
I'll investigate this method first. I had discarded it for some reason before 
but now can't remember...

> 
> > This is a problem for running tests in the testsuite using the inplace GHC.
> >
> > Typically on Windows the way you would do this is by delay loading the
> > dll. This allows me to write some code on startup and manually load
> > the runtime dll. The Windows loader would then just use the loaded
> > dll. Unfortunately delay loading does not support const extern data.
> > Such as const extern RtsConfig defaultRtsConfig;
> >
> Silly Windows.

Yeah, unfortunately this is because this isn't done by any OS functions. Lazy 
loading is purely something
implemented by linkers on Windows and the appropriate runtimes. In essense it 
just creates a stub that replaces all functions, which first checks if the dll 
is loaded, if not load it and then call the real function. Which is why it only 
works for functions.

> 
> > The RTS/GHC is full of such usage so it won’t be easy to change.
> > Though I’d only have to change those exposed by Rts.h.
> >
> > So I have two options:
> > 1) Replace all const externs with a function call. This would work,
> >but isn’t ideal because it would break if someone in the future
> >adds a new data entry instead of a function. And we have an extra
> >function call everywhere.
> 
> Right, I'm really not a fan of this option. Crippling the RTS's use of C
> on account of arbitrary limitations of the Windows dynamic linker
> doesn't seem very appealing.

I was not a fan of this either. Would imagine I would be chased around with 
flaming pitchforks were I to do this..

> 
> > 2) I could do some hacks on the Windows side, e.g. compile the program
> > to a shared library, embed the shared library inside the exe and on
> > startup after loading the propert rts, load the DLL from (mmapped)
> > memory and run the code.
> 
> This sounds like it would get the job done, although it certainly adds
> complexity. Do you have any intuition for how much work it would be to
> implement this?

We sorta already do 80% of this. For Windows when making a dynamic version

RE: Linker reorganization

[lonetiger]

> Simon Marlow  writes:
> 
> >> One concern that I have is that the RTS's header file structure (where
> >> everything is #include'd via Rts.h) doesn't work very well for this
> >> particular use, where we have a group of headers specific to a
> >> particular subsystem (e.g. linker/*.h). Consequently, these header files
> >> currently lack enclosing `extern "C"` blocks (as well as
> >> Begin/EndPrivate blocks). It would be easy to add these, but I was
> >> curious to hear if others had any better ideas.
> >>
> >>
> > Not sure I understand the problem.  Rts.h is for *public* APIs, those that
> > are accessible outside the RTS, but these APIs are mostly *internal*.  The
> > public-facing linker API is in includes/rts/Linker.h.
> >
> > We don't need extern "C" in the internal header files because we're never
> > going to include these from C++ (we do in the external ones though). But we
> > should have BeginPrivate.h/EndPrivate.h in the internal headers.
> >
> 
> Ahh, right; silly me. I'll just add the necessary BeginPrivates and
> hopefully we get this merged after Karel reports back with the results
> of his testing. Thanks Simon!

Great work! I'm itching to take an Axe to the PE stuff. lots of constants can 
just go.

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

RE: Dynamic Linking help

[lonetiger]

> >   
> > 2) The other problem is that the paths specified have to be relative to the 
> > application.
> >(Of the top of my head) It doesn't support absolute paths. Which
> >means I can't have GHC generate the entry because I have no idea
> >where the testsuite intends to run the binary.
> >One way around this is to have the testsuite generate the needed config 
> > file. That should be do-able.
> >
> > I'll investigate this method first. I had discarded it for some reason 
> > before but now can't remember...
> >
> Right, it sounds like this is a workable option and the fact that it
> requires adding no further complexity to the compiler is quite a merit.
> The only question is what other use-cases might run into this same issue.
> For instance, what happens when I run `cabal build` and try to run an
> executable from `dist/build`. Then I run `cabal install` and run it from
> `.cabal/bin`. Surely Cabal will need to take some sort of action in this
> case. I suppose this means that using plain `ghc -dynamic` alone is
> probably out of the question.

No, this would only be the case for development versions of GHC. For the end 
user, the GHC core libraries
*should* be registered in the SxS cache (much like the Microsoft, Intel, etc 
compilers do). This is part of
the distribution story we still have to have a chat about.

For user libraries, it wouldn't matter since the application would check the 
SxS Cache and it would always work.
Also the SxS assembly creation is opt-in. So if you rely on a dll, even one 
created by GHC (and not a core library) then by default it won't be an SxS 
assembly (as is currently the case.).

This does however mean, that if you just use the tarball, you can't run 
programs created with -dynamic.

In the implementation I also have an override `-fno-gen-sxs-assembly` which 
will create a binary which will not try to use SxS at all to find it's 
depencencies. In this case you'd have to have the proper PATH entries.
So by adjusting your PATH you can still get the development/in-place ghc to run 
from abritrary locations. Since this method can't be used to satisfy the loader 
than that the right runtime was already loaded it does mean that Stack won't be 
able to support -dynamic out of the box. However they can probably get it to 
work using the same methods the testsuite uses.

The testsuite always compiles applications using this override, and then 
corrects the PATH entries before running. This is why a large part of the tests 
still run fine.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Windows toolchain update

[lonetiger]

Hi Windows devs,

The Windows GCC has been updated to 6.2.0 and binutils to 2.27.

At some point please  rebuild using these binaries. 
Do throw away your old toolchain cache before getting the new one:

rm -rf ghc-tarballs && ./configure --enable-tarballs-autodownload

The plan is to ship these versions with GHC 8.2, though binutils will likely
Get another minor bump.

Thanks,
Tamar

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

RE: Windows build

[lonetiger]

Hi Simon,

For the tests what Ben’s email forgot to say was that the build system doesn’t 
pick up on changes to Timeout.

So you’d need to nuke it to get the fixes for timing related things: rm -rf 
testsuite/timeout/dist && rm -rf testsuite/timeout/install-inplace

And rerun the tests should fix a few including prog003. For the plugin ones we 
reverted the commit that caused the failures.

I’m currently working on fixing the hsc2hs ones you might see pop up every now 
and again. The haddock one is new as well, Don’t know what caused it. If you 
can nuke timeout and rebase to head you should only have the haddock one left.

Also we’ve nuked support for python 2. If you’re up to date with master then we 
only accept python 3 so that should be alright.

If you still have these failures (particularly the framework failures ones) 
could you possibly send me the errors printed on stderr?
The errors are hard to reproduce on all machines so logs help a lot.

Thanks,
Tamar

From: Simon Peyton Jones via ghc-devs
Sent: Wednesday, November 30, 2016 22:50
To: ghc-devs@haskell.org
Subject: Windows build

Thanks for all the work you’ve been doing on the Windows build.
As requested by Tamar I removed ghc-tarballs, and reconfigured.
Then I built from scratch.
I get the following testsuite failures
Simon
Unexpected failures:
   ghci/prog003/prog003.run    prog003 [bad exit code] (ghci)
   plugins/plugins05.run   plugins05 [exit code non-0] (normal)
   plugins/plugins01.run   plugins01 [bad exit code] (normal)
   plugins/plugins07.run   plugins07 [bad exit code] (normal)
   plugins/T10420.run  T10420 [bad exit code] (normal)
   plugins/T10294a.run     T10294a [bad exit code] (normal)
   plugins/T11244.run  T11244 [bad stderr] (normal)
   plugins/T12567a.run T12567a [bad exit code] (normal)
   rts/testmblockalloc.run testmblockalloc [bad exit code] (normal)
  simplCore/should_compile/T7702.run  T7702 [exit code non-0] (normal)

Unexpected stat failures:
   perf/haddock/haddock.compiler.run  haddock.compiler [stat not good enough] 
(normal)

Framework failures:
   ghci/scripts/ghci062.run  ghci062 [ghci-ext] ([Errno 17] File exists: 
'/c/Users/simonpj/AppData/Local/Temp/ghctest-anc5s5mh/test   
spaces/./ghci/scripts/ghci062.run')
   plugins/plugins07.run plugins07 [normal] (pre_cmd failed: 2)
   plugins/T10420.run    T10420 [normal] (pre_cmd failed: 2)
   plugins/T10294a.run   T10294a [normal] (pre_cmd failed: 2)
   plugins/T11244.run    T11244 [normal] (pre_cmd failed: 2)
   th/TH_repPrim.run TH_repPrim [ext-interp] ([Errno 17] File exists: 
'/c/Users/simonpj/AppData/Local/Temp/ghctest-anc5s5mh/test   
spaces/./th/TH_repPrim.run')
   th/TH_repPatSig.run   TH_repPatSig [ext-interp] ([Errno 17] File exists: 
'/c/Users/simonpj/AppData/Local/Temp/ghctest-anc5s5mh/test   
spaces/./th/TH_repPatSig.run')


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

RE: Windows build

[lonetiger]

Hi Simon,

Thanks for the update, I can reproduce a similar failure on the build bot and 
one of my own machines. I’m looking into what might be causing it, I have 
something I want to try but not
Sure yet it will solve it.

I don’t need more information atm as I can reproduce the race condition by 
doing enough I/O.

Thanks,
Tamar

From: Simon Peyton Jones
Sent: Tuesday, January 17, 2017 08:13
To: Phyx
Cc: ghc-devs
Subject: Windows build

Hi Tamar
The current state of a clean Windows build has improved – but still has 
multiple failures.  See below
Thanks for your work on this.
I can send more details if that’d be helpful
Simon
Unexpected failures:
   plugins/plugins07.run  plugins07 [bad exit code] (normal)
   plugins/T10420.run T10420 [bad exit code] (normal)
   plugins/T10294a.run    T10294a [bad exit code] (normal)
   plugins/T11244.run T11244 [bad stderr] (normal)

Framework failures:
   backpack/cabal/bkpcabal03/bkpcabal03.run   bkpcabal03 [runTest] (Unhandled 
exception: [Errno 90] Directory not empty: 'autogen')
   plugins/plugins07.run  plugins07 [normal] (pre_cmd 
failed: 2)
   plugins/T10420.run T10420 [normal] (pre_cmd failed: 
2)
   plugins/T10294a.run    T10294a [normal] (pre_cmd failed: 
2)
   plugins/plugins07.run  plugins07 [runTest] (Unhandled 
exception: [Errno 90] Directory not empty: 'rule-defining-plugin-0.1')
   plugins/T11244.run     T11244 [normal] (pre_cmd failed: 
2)
   safeHaskell/check/pkg01/ImpSafeOnly03.run  ImpSafeOnly03 [runTest] 
(Unhandled exception: [Errno 90] Directory not empty: 
'safePkg01-1.0-COK8JB4prM8EuKYKd3XaX3')

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

RE: Windows build broken again

[lonetiger]

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

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

Phyx  writes:

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

Cheers,

- Ben


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

RE: Windows build failing in a new way

[lonetiger]

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 while everyone fixed the one 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 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

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

RE: Windows broken

[lonetiger]

Hi Simon,

What happens when you try to compile that simple test with the bundled gcc?

Could you also run it through strace, this will force msys2 not to swallow 
errors from the OS.

Should you get an exception dialog then rm -rf inplace/mingw and rerun 
configure (I assume you’re on a recent revision).

If none of the above give a clue, you could try ./configure 
--enable-distro-toolchain, this will have it skip the bundled GCC
And use any installed by msys2. If this work then try rm’ing the GHC-tarballs 
folder and the inplace/mingw folder and try again
With –enable-tarballs-autodownloads.

Tamar.

From: Simon Peyton Jones via ghc-devs
Sent: Thursday, June 29, 2017 00:35
To: ghc-devs
Subject: Windows broken

Help please!
Suddenly my Windows build has stopped working.   See below.  What should I do?  
I’m totally stuck.
This has never happened before.
I get this:
GHC path canonicalised to: c:/fp/ghc-8.0.2/bin/ghc
checking build system type... x86_64-pc-msys
checking host system type... x86_64-pc-msys
checking target system type... x86_64-pc-msys
Build platform inferred as: x86_64-unknown-mingw32
Host platform inferred as: x86_64-unknown-mingw32
Target platform inferred as: x86_64-unknown-mingw32
GHC build  : x86_64-unknown-mingw32
GHC host   : x86_64-unknown-mingw32
GHC target : x86_64-unknown-mingw32
LLVM target: x86_64-unknown-mingw32
checking for path to top of build tree... C:/code/HEAD
configure: Checking for Windows toolchain tarballs...
configure: Extracting Windows toolchain from archives (may take a while)...
configure: In-tree MingW-w64 tree created
configure: Making in-tree perl tree
configure: In-tree perl tree created
checking whether the C compiler works... no
configure: error: in `/c/code/HEAD':
configure: error: C compiler cannot create executables
See `config.log' for more details
Something wrong with the gcc.exe?  Config.log has this
gcc version 6.3.0 (Rev2, Built by MSYS2 project) 
configure:4950: $? = 0
configure:4939: C:/code/HEAD/inplace/mingw/bin/gcc.exe -V >&5
gcc.exe: error: unrecognized command line option '-V'
gcc.exe: fatal error: no input files
compilation terminated.
configure:4950: $? = 1
configure:4939: C:/code/HEAD/inplace/mingw/bin/gcc.exe -qversion >&5
gcc.exe: error: unrecognized command line option '-qversion'; did you mean 
'--version'?
gcc.exe: fatal error: no input files
compilation terminated.
configure:4950: $? = 1
configure:4970: checking whether the C compiler works
configure:4992: C:/code/HEAD/inplace/mingw/bin/gcc.exe    conftest.c  >&5
configure:4996: $? = 1
configure:5034: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "The Glorious Glasgow Haskell Compilation System"
| #define PACKAGE_TARNAME "ghc-8.3"
| #define PACKAGE_VERSION "8.3"
| #define PACKAGE_STRING "The Glorious Glasgow Haskell Compilation System 8.3"
| #define PACKAGE_BUGREPORT "glasgow-haskell-b...@haskell.org"
| #define PACKAGE_URL ""
| /* end confdefs.h.  */
| 
| int
| main ()
| {
| 
|   ;
|   return 0;
| }
configure:5039: error: in `/c/code/HEAD':
configure:5041: error: C compiler cannot create executables

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

RE: Windows broken

[lonetiger]

Oops, sorry, didn’t notice it because both mine and harbormaster’s msys2 have 
separate GCCs installed as well.

You can just leave it reverted, could you also push it? I don’t see an easy fix 
that would also work for end user
Configure based cabal installs. So I think I’ll have to go back to the drawing 
board for this one.

Thanks,
Tamar
From: Simon Peyton Jones
Sent: Thursday, June 29, 2017 09:10
To: loneti...@gmail.com; ghc-devs
Subject: RE: Windows broken

Tamar

Aha!  It’s you!   Reverting this commit fixes it
git revert d6cecde585b0980ed8e0050c5a1d315789fb6356
[master af9f0f4] Revert "Remove the Windows GCC driver."
5 files changed, 88 insertions(+), 30 deletions(-)
create mode 100644 driver/gcc/gcc.c

If you can see an easy fix I can try that.  Else I’ll probably just revert and 
let you investigate.

I appear not to have Cygwin, and no other gcc is not in my path.  I just rely 
on the one that comes with GHC.

After reverting, here’s what happens when I compile foo.c (trace below).   The 
invocation of cc1.exe looks rather different
C:/code/HEAD/inplace/mingw/bin/gcc.exe -v foo.c
Using built-in specs.
COLLECT_GCC=C:\\code\\HEAD\\inplace\\mingw\\bin/realgcc.exe
COLLECT_LTO_WRAPPER=C://code//HEAD//inplace//mingw//bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-6.3.0/configure --prefix=/mingw64 
--with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 
--with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include 
--libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 
--with-tune=generic --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada 
--enable-shared --enable-static --enable-libatomic --enable-threads=posix 
--enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-time=yes 
--disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check 
--enable-lto --enable-libgomp --disable-multilib --enable-checking=release 
--disable-rpath --disable-win32-registry --disable-nls --disable-werror 
--disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 
--with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 
--with-pkgversion='Rev2, Built by MSYS2 project' 
--with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld
Thread model: posix
gcc version 6.3.0 (Rev2, Built by MSYS2 project) 
COLLECT_GCC_OPTIONS='-B' 'C:\\code\\HEAD\\inplace\\mingw\\bin' '-B' 
'C:\\code\\HEAD\\inplace\\mingw\\bin/../lib' '-B' 
'C:\\code\\HEAD\\inplace\\mingw\\bin/../lib/gcc/x86_64-w64-mingw32/6.3.0' '-B' 
'C:\\code\\HEAD\\inplace\\mingw\\bin/../libexec/gcc/x86_64-w64-mingw32/6.3.0' 
'-v' '-mtune=generic' '-march=x86-64'
C://code//HEAD//inplace//mingw//bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/cc1.exe 
-quiet -v -iprefix 
C:/code/HEAD/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/ -isystem 
C://code//HEAD//inplace//mingw//bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/include 
-isystem 
C://code//HEAD//inplace//mingw//bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/include-fixed
 -D_REENTRANT foo.c -quiet -dumpbase foo.c -mtune=generic -march=x86-64 
-auxbase foo -version -o C:\Users\simonpj\AppData\Local\Temp\ccGa7vqE.s
GNU C11 (Rev2, Built by MSYS2 project) version 6.3.0 (x86_64-w64-mingw32)
  compiled by GNU C version 6.3.0, GMP version 6.1.2, MPFR version 
3.1.5-p2, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory 
"C:/code/HEAD/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/include"
ignoring duplicate directory 
"C:/code/HEAD/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/include-fixed"
ignoring duplicate directory 
"C:/code/HEAD/inplace/mingw/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/6.3.0/include"
ignoring nonexistent directory "C:/building/msys64/mingw64/include"
ignoring nonexistent directory "/mingw64/include"
ignoring duplicate directory 
"C:/code/HEAD/inplace/mingw/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/6.3.0/include-fixed"
ignoring duplicate directory 
"C:/code/HEAD/inplace/mingw/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/6.3.0/../../../../x86_64-w64-mingw32/include"
ignoring nonexistent directory 
"C:/building/msys64/mingw64/x86_64-w64-mingw32/include"
#include "..." search starts here:
#include <...> search starts here:
C://code//HEAD//inplace//mingw//bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/include
C://code//HEAD//inplace//mingw//bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/include-fixed
C:/code/HEAD/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/../../../../include
C:/code/HEAD/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/../../../../x86_64-w64-mingw32/include
End of search list.
GNU C11 (Rev2, Built by MSYS2 project) version 6.3.0 (x86_64-w64-mingw32)
  compiled by GNU C version 6.3.0, GMP version 6.1.2, MPFR version 
3.1.5-p2, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=1

dll-split

[lonetiger]

Hi All,

I have just killed off dll-split, this means that you no longer need to 
maintain a list
of modules in GHC.mk.

If you’re a non-Windows programmer you can stop reading here, for those that 
build on Windows:

The replacement for dll-split is called gen-dll, and it is able to 
automatically partition any library we build, so this issue is hopefully solved 
once and for all.

Currently dynamic linking is still turned off as I have a few more patches to 
upstream. When I do turn it on, by default you will get a large ~45min hit in 
compile time. This is because dlltool which BFD based is quite slow.

To mitigate this gen-dll supports the use of the msys2 project’s genlib tool. 
This tool finishes in seconds instead of tens of minutes like dlltool.

To install it just run pacman -Sy mingw-w64-$(uname -m)-tools-git

The wiki pages have been updated accordingly already. If you install this now 
you won’t notice any difference in build time later.

Thanks,
Tamar

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

RE: Haskell Platform 8.2.2 - virus?

[lonetiger]

Upload one of the binaries it flagged to https://www.virustotal.com/en/ and 
send the link.

As far as I can tell, they’re all clean

https://www.virustotal.com/en/file/9cc2a6032dde8d8ab572f9491041242ab4c76d2b7d36eea5283c82cf9bf9fd69/analysis/
https://www.virustotal.com/en/file/5ffdaa7da4381637ab2a0ec327118cd933398a477430e2f5d94e9d53c53f2782/analysis/

From: Matthew Lamari
Sent: Thursday, December 28, 2017 20:29
To: ghc-devs@haskell.org
Subject: Haskell Platform 8.2.2 - virus?


New Haskell install was tripping my Bitdefender like crazy and in weird
ways - not new as that's how bitdefender rolls. However, I retested in a
 clean test, with (free) Hitman Pro

I started from a base case with 2 clean windows 8 VMs.

New 8.2.2 install - has virus
Old 8.0.2 Jan 2017 - no virus


According to Hitman Pro, touchy.exe, haddock-8.2.2, ghc-8.2.2.exe, and
unlit.exe have some problem post-install. I went no further on the VMs.

"Detection Names
Kaspersky   Trojan-Downloader.Win32.Paph.fsv
"

Bitdefender didn't get it on install but would lock the whole thing down
on the first run of "Cabal".

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

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

RE: Haskell Platform 8.2.2 - virus?

[lonetiger]

Yes, AV software, especially HitmanPro are not gospel.

67 other AVs came out clean. But let’s say for the sake of argument that 
they’re all wrong.

“Trojan-Downloader” is a class of Trojan that downloads a payload. Which means 
they need to use a socket somehow.

$ sha256sum.exe ghc-8.2.2/lib/bin/touchy.exe
5ffdaa7da4381637ab2a0ec327118cd933398a477430e2f5d94e9d53c53f2782 
*ghc-8.2.2/lib/bin/touchy.exe

Is the binary I’m looking it, it matches the hash on the total virus link and 
yours.

This is the source of touchy 
https://github.com/ghc/ghc/blob/ghc-8.2/utils/touchy/touchy.c

The application does not import Winsock, so networking seems more unlikely, but 
it imports GetProcAddress, so let’s say for the sake of argument it’s
Dynamically binding to the socket library.

http://lpaste.net/3408264924009332736 is the full string table. Which contains 
no ascii string starting with “WSA”. So unlikely since you need to name the 
function
you want to call, and you need to initialize the sockets, so WSA.

This is the full disassembly of touchy.exe

http://lpaste.net/7667888088021991424

Below you’ll find an inline copy of main, it pretty much follows the source in 
touchy.c.

I’m pretty confident that HitmanPro is just throwing a false positive,  I won’t 
be going through the CRT startup code.

Here’s main:

004015c0 :
  4015c0:   41 57   push   %r15
  4015c2:   41 56   push   %r14
  4015c4:   41 55   push   %r13
  4015c6:   41 54   push   %r12
  4015c8:   55  push   %rbp
  4015c9:   57  push   %rdi
  4015ca:   56  push   %rsi
  4015cb:   53  push   %rbx
  4015cc:   48 83 ec 68 sub$0x68,%rsp
  4015d0:   89 ce   mov%ecx,%esi
  4015d2:   48 89 d7mov%rdx,%rdi
  4015d5:   e8 e6 02 00 00  callq  4018c0 <__main>
  4015da:   83 fe 01cmp$0x1,%esi
  4015dd:   74 10   je 4015ef 
  4015df:   b8 00 00 00 00  mov$0x0,%eax
  4015e4:   83 fe 01cmp$0x1,%esi
  4015e7:   0f 8e 4d 01 00 00   jle40173a 
  4015ed:   eb 26   jmp401615 
  4015ef:   48 8b 1fmov(%rdi),%rbx
  4015f2:   ff 15 1c 6d 00 00   callq  *0x6d1c(%rip)# 408314 
<__imp___iob_func>
  4015f8:   48 8d 48 60 lea0x60(%rax),%rcx
  4015fc:   49 89 d8mov%rbx,%r8
  4015ff:   48 8d 15 2a 2a 00 00lea0x2a2a(%rip),%rdx# 
404030 <.rdata>
  401606:   e8 65 17 00 00  callq  402d70 
  40160b:   b8 01 00 00 00  mov$0x1,%eax
  401610:   e9 25 01 00 00  jmpq   40173a 
  401615:   48 8d 5f 08 lea0x8(%rdi),%rbx
  401619:   8d 46 felea-0x2(%rsi),%eax
  40161c:   4c 8d 7c c7 10  lea0x10(%rdi,%rax,8),%r15
  401621:   4c 8b 2d ec 6b 00 00mov0x6bec(%rip),%r13# 
408214 <__imp_CreateFileA>
  401628:   48 8d 7c 24 50  lea0x50(%rsp),%rdi
  40162d:   4c 8b 25 30 6c 00 00mov0x6c30(%rip),%r12# 
408264 <__imp_GetSystemTimeAsFileTime>
  401634:   48 8b 2d 71 6c 00 00mov0x6c71(%rip),%rbp# 
4082ac <__imp_SetFileTime>
  40163b:   4c 8b 35 ca 6b 00 00mov0x6bca(%rip),%r14# 
40820c <__IAT_start__>
  401642:   48 89 5c 24 48  mov%rbx,0x48(%rsp)
  401647:   48 c7 44 24 30 00 00movq   $0x0,0x30(%rsp)
  40164e:   00 00 
  401650:   c7 44 24 28 80 00 00movl   $0x80,0x28(%rsp)
  401657:   00 
  401658:   c7 44 24 20 04 00 00movl   $0x4,0x20(%rsp)
  40165f:   00 
  401660:   41 b9 00 00 00 00   mov$0x0,%r9d
  401666:   41 b8 00 00 00 00   mov$0x0,%r8d
  40166c:   ba 00 00 00 40  mov$0x4000,%edx
  401671:   48 8b 0bmov(%rbx),%rcx
  401674:   41 ff d5callq  *%r13
  401677:   48 89 c6mov%rax,%rsi
  40167a:   48 83 f8 ff cmp$0x,%rax
  40167e:   75 2b   jne4016ab 
  401680:   48 8b 44 24 48  mov0x48(%rsp),%rax
  401685:   48 8b 18mov(%rax),%rbx
  401688:   ff 15 86 6c 00 00   callq  *0x6c86(%rip)# 408314 
<__imp___iob_func>
  40168e:   48 8d 48 60 lea0x60(%rax),%rcx
  401692:   49 89 d8mov%rbx,%r8
  401695:   48 8d 15 a7 29 00 00lea0x29a7(%rip),%rdx# 
404043 <.rdata+0x13>
  40169c:   e8 cf 16 00 00  callq  402d70 
  4016a1:   b9 01 00 00 00  mov$0x1,%ecx
  4016a6:   e8 cd 16 00 00  callq  402d78 
  4016ab:   48 89 f9mov%rdi,%rcx
  4016ae:

RE: Haskell Platform 8.2.2 - virus?

[lonetiger]

We have fixed this though, GHC 8.4 shouldn’t have this problem specifically. 

The issue is that hitman pro is injecting itself into every process by throwing 
a signal,
Prior to 8.4 we were pretty aggressive in how we treated first chance 
exceptions. We’ve now relaxed this.

That said I find the behavior of HitmanPro to be quite intrusive and I wouldn’t 
trust anything injecting code
Into my address space.

Fyi, this is what it caused:

ExceptionAddress: 7ffcc2b368ce (ntdll!RtlVirtualUnwind+0x001e)
ExceptionCode: c005 (Access violation)
ExceptionFlags: 
NumberParameters: 2
Parameter[0]: 
Parameter[1]: 046710f6
Attempt to read from address 046710f6
0:000> lmvm hmpalert
Browse full module list
start end module name
7ffc`ba4b 7ffc`ba595000 hmpalert (export symbols) hmpalert.dll
Loaded symbol image file: hmpalert.dll
Image path: C:\Windows\System32\hmpalert.dll
Image name: hmpalert.dll
Browse all global symbols functions data
Timestamp: Mon Jul 17 15:53:17 2017 (596CCF5D)
CheckSum: 000F490C
ImageSize: 000E5000
File version: 3.6.8.604
Product version: 3.6.8.604
File flags: 0 (Mask 3F)
File OS: 40004 NT Win32
File type: 2.0 Dll
File date: .
Translations: 0400.04b0
CompanyName: SurfRight B.V.
ProductName: HitmanPro.Alert
InternalName: hmpalert.dll
OriginalFilename: hmpalert_x64.dll
ProductVersion: 3.6.8.604
FileVersion: 3.6.8.604
FileDescription: HitmanPro.Alert 64-bit Support Library
LegalCopyright: © 2013-2017 SurfRight, a Sophos company
Comments: Incorporates Threatstar Exploit Mitigation Platform (EMP)

From: Gershom B
Sent: Thursday, December 28, 2017 22:24
To: ghc-devs@haskell.org Devs
Subject: RE: Haskell Platform 8.2.2 - virus?

Note that HitmanPro has caused plenty of problems with GHC in the
past, and should be avoided by Haskell devs:

https://www.reddit.com/r/haskell/comments/77from/gettting_segmentation_fault_on_stackcabal_any/

https://github.com/commercialhaskell/intero/issues/436
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

RE: Windows build broken -- help!

[lonetiger]

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 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 
 wrote:
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, carter
    
Differential Revision: https://phabricator.haskell.org/D4390
 
commit 4d1c3b72ec27c8e51fb40809bba3ce35246a2966
Author: Ben Gamari 
Date:   Tue Feb 6 13:27:35 2018 -0500
 
    rts: Add format attribute to barf
    
Test Plan: Validate
    
Reviewers: erikd, simonmar
    
Reviewed By: simonmar
    
Subscribers: rwbarton, thomie, carter
    
Differential Revision: https://phabricator.haskell.org/D4374
 
 
From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Simon Peyton 
Jones via ghc-devs
Sent: 07 February 2018 23:14
To: ghc-devs ; Phyx 
Subject: Windows build broken -- help!
 
Aargh. Windows build is broken again.  Log below.  Help!
Simon
 
"inplace/bin/ghc-stage1.exe" -optc-fno-stack-protector -optc-Wall -optc-Werror 
-optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes 
-optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return 
-optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs 
-optc-Wredundant-decls -optc-Wundef -optc-Iincludes -optc-Iincludes/dist 
-optc-Iincludes/dist-derivedconstants/header 
-optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build 
-optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common 
-optc-Irts/dist/build/./autogen -optc-Wno-error=inline -optc-O2 
-optc-fomit-frame-pointer -optc-g -optc-DRtsWay=\"rts_v\" 
-optc-DWINVER=0x06000100 -static  -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 -Wcpp-undef    
-Wnoncanonical-monad-instances  -c rts/StgPrimFloat.c -o 
rts/dist/build/StgPrimFloat.o
 
rts\Schedule.c:274:14: error:
 error: unknown conversion type character 'l' in format [-Werror=format=]
 barf("sched_state: %" FMT_Word, sched_state);
  ^~~~
    |
274 | barf("sched_state: %" FMT_Word, sched_state);
    |  ^
In file included from 
C:/code/HEAD-1/inplace/mingw/x86_64-w64-mingw32/include/stdio.h:1036:0,
 from includes/rts/Flags.h:16,
 from includes/Rts.h:191,
 
 from rts\Schedule.c:11:0: error: 
C:/code/HEAD-1/inplace/mingw/x86_64-w64-mingw32/include/_mingw_print_pop.h:86:18:
 note: format string is defined here
#define PRIu64 "llu"
  ^
 
rts\Schedule.c:274:14: error:
 error: too many arguments for format [-Werror=format-extra-args]
 barf("sched_state: %" FMT_Word, sched_state);
  ^~~~
    |
274 | barf("sched_state: %" FMT_Word, sched_state);
    |  ^
cc1.exe: all warnings being treated as errors
`gcc.exe' failed in phase `C Compiler'. (Exit code: 1)
"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-Wundef -optc-Iincludes -optc-Iincludes/dist 
-optc-Iincludes/dist-derivedconstants/header 
-optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build 
-optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common 
-optc-Irts/dist/build/./autogen -optc-Wno-error=inline -optc-O2 
-optc-fomit-frame-pointer -optc-g -optc-DRtsWay=\"rts_v\" 
-optc-DWINVER=0x06000100 -static  -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 -Wcpp-undef    
-Wnoncanonical-monad-instances  -c rts/Profiling.c -o rts/dist/build/Profiling.o
make[1]: *** [rts/ghc.mk:295: rts/dist/build/Schedule.o] Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [Makefile:127: all] Error 2
/c/code/HEAD-1$

__

RE: Windows

[lonetiger]

Hi Simon,

You need

export MSYSTEM=MINGW64

in your bash profile.

Regards,
Tamar

From: Simon Peyton Jones via ghc-devs
Sent: Friday, March 23, 2018 22:21
To: ghc-devs@haskell.org
Subject: Windows

I’ve just got  a new laptop (the old one’s hard disk died) so I’m trying to get 
to the point of being able to build GHC again.
I’m currently stuck here:
./configure
configure: loading site script /usr/local/etc/config.site
checking for gfind... no
checking for find... /usr/bin/find
checking for sort... /usr/bin/sort
checking for GHC version date... inferred 8.5.20180323
checking for GHC Git commit id... inferred 
affdea82bb70e5a912b679a169c6e9a230e4c93e
checking for ghc... /c/fp/HP-8.2.2/bin/ghc
checking version of ghc... 8.2.2
GHC path canonicalised to: c:/fp/HP-8.2.2/bin/ghc
checking build system type... x86_64-pc-msys
checking host system type... x86_64-pc-msys
checking target system type... x86_64-pc-msys
Unknown OS msys
Any ideas?
Thanks
Simon

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

RE: Windows

[lonetiger]

“C:\msys64\msys2_shell.cmd -mingw64 -mintty”

Won’t work for you as it spawns a new process using mintty as your terminal 
emulator.
If I remember correctly you have a setup where you use bash directly in emacs. 
In which case you just need
To set the environment variables and add /mingw64/bin to your path.

I would personally avoid the use of mintty because of how it implements pty. 
Lots of interactive programs don’t work
Correctly under it, including ghci where we need specific hacks to work around 
some of it’s issues https://github.com/mintty/mintty/issues/56.

From: Simon Peyton Jones via ghc-devs
Sent: Monday, March 26, 2018 11:03
To: Shao, Cheng; ghc-devs@haskell.org
Subject: RE: Windows

If the build environment is managed by an MSYS2 installation, then the MinGW64 
shell startup script automatically sets up "MSYSTEM" for you. It can be 
launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty".
Well I just followed the Method A instructions at 
https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows

Are you saying that I should run “C:\msys64\msys2_shell.cmd -mingw64 -mintty" 
just once, after installing?  Or repeatedly?  Or that I should somehow us it as 
my main shell?  And what does that commend actually do?
Sorry to be dense

Simon

From: ghc-devs  On Behalf Of Shao, Cheng
Sent: 26 March 2018 10:59
To: ghc-devs@haskell.org
Subject: Re: Windows

Hi Simon,

If the build environment is managed by an MSYS2 installation, then the MinGW64 
shell startup script automatically sets up "MSYSTEM" for you. It can be 
launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty".

On Mon, Mar 26, 2018 at 5:46 PM, Simon Peyton Jones via ghc-devs 
 wrote:
Making it part of the error message would be v helpful.

I have added a section to "Troubleshooting" on
https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows

But it should really be part of the instructions higher up to sa
        export MSYSTEM=MINGW64

Might someone do that?  I wasn't quite sure where

Simon

|  -Original Message-
|  From: ghc-devs  On Behalf Of Ben Gamari
|  Sent: 24 March 2018 16:42
|  To: Gabor Greif ; loneti...@gmail.com
|  Cc: ghc-devs@haskell.org
|  Subject: Re: Windows
|
|  Gabor Greif  writes:
|
|  > Just an idea...
|  >
|  > could this hint be part of the `configure` error message?
|  >
|  Indeed. See D4526.
|
|  Cheers,
|
|  - Ben
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


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

RE: End of Windows Vista support in GHC-8.6?

[lonetiger]

I’ve started a build, note that you will also need a PR to Hadrian to update 
WINVER.

From: Simon Jakobi
Sent: Wednesday, May 9, 2018 09:49
To: Phyx
Cc: Ben Gamari; ghc-devs@haskell.org Devs
Subject: Re: End of Windows Vista support in GHC-8.6?

Thanks for the reminder, Tamar!

I have just created https://phabricator.haskell.org/D4679. I would be
very grateful if you could test it on 32bit Windows.

Cheers,
Simon

2018-05-05 12:07 GMT+02:00 Phyx :
> Hi Simon,
>
> Whatever happened to this? The wiki was updated but I don't see a commit
> actually removing vista support.
>
> Did you end up not doing this anymore?
>
> Thanks,
> Tamar
>
> On Mon, Mar 5, 2018 at 7:21 PM, Simon Jakobi 
> wrote:
>>
>> Thanks everyone!
>>
>> I have updated https://ghc.haskell.org/trac/ghc/wiki/Platforms/Windows
>> accordingly.
>>
>> Cheers,
>> Simon
>>
>> 2018-03-05 18:29 GMT+01:00 Phyx :
>>>
>>>
>>>
>>> On Mon, Mar 5, 2018, 17:23 Ben Gamari  wrote:

 Simon Jakobi via ghc-devs  writes:

 > Hi!
 >
 > Given that Vista’s EOL was in April 2017
 >
 > 
 > i assume that there’s no intention to keep supporting it in GHC-8.6!?
 >
 > I’m asking because I intend to use a function
 >
 > 
 > that requires Windows 7 or newer for #13362
 > .
 >
 Given that it's EOL'd, dropping Vista sounds reasonable to me.

 Tamar, any objection?
>>>
>>>
>>> No objections, however do make sure to test both 32 and 64 bit builds of
>>> ghc when you use the API, it's new enough and rare enough that it may not be
>>> implemented in both mingw-64 tool chains (we've had similar issues before).
>>>
>>> Thanks,
>>> Tamar
>>>

 Cheers,

 - Ben
>>
>>
>

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

Running IO function from RTS

[lonetiger]

Hi all,

I’m looking for a way to initiate a call from the RTS into Haskell (base 
function) running and evaluating an IO function using the non-threaded RTS.

For the threaded RTS I can use rts_evalIO with the RTS capability, but for the 
non-threaded I can’t find a way that doesn’t trigger the

if (cap->in_haskell) {
  errorBelch("schedule: re-entered unsafely.\n"
 "   Perhaps a 'foreign import unsafe' should be 'safe'?");
  stg_exit(EXIT_FAILURE);
}

Clause in the scheduler.

Taking a look at how the non-threaded I/O manager currently works on Windows, 
it seems that re-uses the TSO from the blocked thread doing the I/O call to 
give notifications back.
This approach doesn’t work for me since the new I/O manager doesn’t block doing 
a foreign call boundary, instead It blocks in Haskell on an MVar, and I only 
want to wake up very specific threads.

In short, does anyone know of a way to initialize an I/O operation from the 
non-threaded RTS?

Thanks,
Tamar

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