subject:"More windows"

RE: More windows

2018-04-04 Thread Simon Peyton Jones via ghc-devs

The solution seems to be to cache the user info locally instead of it having to 
query the domain controller everytime.

Ah yes: here’s a better expressed post: http://bjg.io/guide/cygwin-ad/

I did the following

  *   commented out the “db” part for passwd and group in 
c:/msys64/etc/nsswitch.conf, to give this:

# Begin /etc/nsswitch.conf



passwd: files #db

group: files #db



db_enum: cache builtin



db_home: windows

db_shell: cygwin desc

db_gecos: cygwin desc



# End /etc/nsswitch.conf


  *   Note that I also set db_home to ‘windows’, so that it gets my windows 
home directory.  I think an explicit path would also be OK
  *   However I discovered that having just “files” for “passwd” in 
nsswitch.conf means that ssh looks in c:/msys64/etc/passwd to find the home 
directory for .ssh, totally ignoring the $HOME environment variable, and 
ignoring the db_home setting.
  *   But there IS no /etc/passwd file!   So I created one

mkpasswd -c > /etc/passwd

mkgroup -c > /etc/group

And then I manually edited /etc/passwd to put in the correct home directory.

What a saga!


Is it faster now?  Hard to tell.
Simon

From: Phyx <loneti...@gmail.com>
Sent: 03 April 2018 07:00
To: Simon Peyton Jones <simo...@microsoft.com>
Cc: ghc-devs@haskell.org
Subject: Re: More windows

Hi Simon,

Hmm I'm not sure about replacing sh with bash. I think bash has some Non-POSIX 
extensions that may affect the behavior of valid posix scripts.

Is bash --login slow as well? How about once sh or bash starts, are commands 
still slow then?

I assume your computer is domain joined and you may be hitting a very long 
standing issue with certain domain joined machines 
https://github.com/Alexpux/MSYS2-packages/issues/138#issuecomment-70813762<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAlexpux%2FMSYS2-packages%2Fissues%2F138%23issuecomment-70813762=02%7C01%7Csimonpj%40microsoft.com%7C185492e20be9494ebdf008d599282bcd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636583320164876915=MYHQSKqds%2FJXXEkX1jXF2psZmZntrrgtBqEUXtfGQBs%3D=0>

The solution seems to be to cache the user info locally instead of it having to 
query the domain controller everytime. See solution 2 here
https://gist.github.com/k-takata/9b8d143f0f3fef5abdab<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgist.github.com%2Fk-takata%2F9b8d143f0f3fef5abdab=02%7C01%7Csimonpj%40microsoft.com%7C185492e20be9494ebdf008d599282bcd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636583320164876915=Qb1BMV9NoSijP%2F%2F5e4ZNNJ%2FGHhMrGksFTM6eVRL4dQQ%3D=0>
 for instructions

Does that help the problem?

I believe you had a similar problem last time setting up a new machine. At that 
time magit was also slow.

Kind regards,
Tamar

On Mon, Apr 2, 2018, 23:23 Simon Peyton Jones 
<simo...@microsoft.com<mailto:simo...@microsoft.com>> wrote:
Tamar
I’ve noticed that “sh” (which is invoked at lot by make etc) takes AGES to 
start up.  At least I think it’s ‘sh’ that is causing the delay.
I think it’s c:/msys64/usr/bin/sh.exe
From searching the web (eg 
https://www2.cs.duke.edu/csl/docs/unix_course/intro-60.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww2.cs.duke.edu%2Fcsl%2Fdocs%2Funix_course%2Fintro-60.html=02%7C01%7Csimonpj%40microsoft.com%7C185492e20be9494ebdf008d599282bcd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636583320164876915=74ecRU4VAdzlHW1Tjul6VEqdxsEsnd7xBSYnMoYsqfg%3D=0>)
  it seems likely that it executes c:/msys64/etc/profile first.
And If I put an ‘echo’ at the start and end of that file, they do seem to take 
place with a significant gap between them.
I have not started sprinkling more echos, but does that ring any bells?
Can I replace ‘sh’ with c:/msys64/usr/bin/bash.exe, which seems to be faster?   
(My evnt variable SHELL already points to bash.exe. )  And if so, how would I 
do that? An environment variable.  Physically copy bash.exe to sh.exe?  Or what?
Thanks
Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: More windows

2018-04-03 Thread Phyx

Hi Simon,

Hmm I'm not sure about replacing sh with bash. I think bash has some
Non-POSIX extensions that may affect the behavior of valid posix scripts.

Is bash --login slow as well? How about once sh or bash starts, are
commands still slow then?

I assume your computer is domain joined and you may be hitting a very long
standing issue with certain domain joined machines
https://github.com/Alexpux/MSYS2-packages/issues/138#issuecomment-70813762

The solution seems to be to cache the user info locally instead of it
having to query the domain controller everytime. See solution 2 here
https://gist.github.com/k-takata/9b8d143f0f3fef5abdab for instructions

Does that help the problem?

I believe you had a similar problem last time setting up a new machine. At
that time magit was also slow.

Kind regards,
Tamar

On Mon, Apr 2, 2018, 23:23 Simon Peyton Jones  wrote:

> Tamar
>
> I’ve noticed that “sh” (which is invoked at lot by make etc) takes AGES to
> start up.  At least I think it’s ‘sh’ that is causing the delay.
>
> I think it’s c:/msys64/usr/bin/sh.exe
>
> From searching the web (eg
> https://www2.cs.duke.edu/csl/docs/unix_course/intro-60.html)  it seems
> likely that it executes c:/msys64/etc/profile first.
>
> And If I put an ‘echo’ at the start and end of that file, they do seem to
> take place with a significant gap between them.
>
> I have not started sprinkling more echos, but does that ring any bells?
>
> Can I replace ‘sh’ with c:/msys64/usr/bin/bash.exe, which seems to be
> faster?   (My evnt variable SHELL already points to bash.exe. )  And if so,
> how would I do that? An environment variable.  Physically copy bash.exe to
> sh.exe?  Or what?
>
> Thanks
>
> Simon
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: More windows

2017-10-20 Thread Simon Peyton Jones via ghc-devs

Oddly it's started working.   I have no idea why.  I'll yell if it breaks again.

Simon

| -Original Message-
| From: Ben Gamari [mailto:b...@well-typed.com]
| Sent: 11 October 2017 14:11
| To: Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org>; Simon Peyton
| Jones <simo...@microsoft.com>; GHC developers <ghc-devs@haskell.org>
| Subject: RE: More windows
| 
| Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> writes:
| 
| > Any ideas anyone? When I restart the build, it gets past the blockage
| > (which seems highly specific). But it’s jolly annoying.
| >
| Hi Simon,
| 
| Perhaps let's try this,
| 
|  1. download and run the procmon tool from [1]
|  2. from the "Filter" menu select the "Filter..." option
|  3. select "Path" in the first drop-down
|  4. select "contains" in the second drop-down
|  5. enter "ghc-cabal.exe" in the third text box
|  6. select "Include in the fourth drop-down
|  8. click the "Add" button
|  7. click the "Ok" button
| 
| Now you should be logging events pertaining to the file in question. Now
| simply run `./validate` to try to reproduce the issue.
| 
| With luck this will produce a handful of events, some of which ought to
| point to the process that it responsible for meddling with the GHC
| build.
| 
| Now export this log,
| 
|  1. select "Save" from the "File" menu
|  2. select the "Events displayed using current filter" option
|  3. select the "CSV" format, select a path that will be easy to file
|  4. return this file to me (perhaps via GitHub Gist [2]?)
| 
| Hopefully this will give us some insight into what is happening.
| 
| Cheers,
| 
| - Ben
| 
| 
| [1] https://docs.microsoft.com/en-us/sysinternals/downloads/procmon
| [2] https://gist.github.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: More windows

2017-10-11 Thread Ben Gamari

Simon Peyton Jones via ghc-devs  writes:

> Any ideas anyone? When I restart the build, it gets past the blockage
> (which seems highly specific). But it’s jolly annoying.
>
Hi Simon,

Perhaps let's try this,

 1. download and run the procmon tool from [1]
 2. from the "Filter" menu select the "Filter..." option
 3. select "Path" in the first drop-down
 4. select "contains" in the second drop-down
 5. enter "ghc-cabal.exe" in the third text box
 6. select "Include in the fourth drop-down
 8. click the "Add" button
 7. click the "Ok" button

Now you should be logging events pertaining to the file in question. Now
simply run `./validate` to try to reproduce the issue.

With luck this will produce a handful of events, some of which ought to
point to the process that it responsible for meddling with the GHC
build.

Now export this log,

 1. select "Save" from the "File" menu
 2. select the "Events displayed using current filter" option
 3. select the "CSV" format, select a path that will be easy to file
 4. return this file to me (perhaps via GitHub Gist [2]?)

Hopefully this will give us some insight into what is happening.

Cheers,

- Ben

[1] https://docs.microsoft.com/en-us/sysinternals/downloads/procmon
[2] https://gist.github.com/

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

RE: More windows

2017-10-10 Thread Simon Peyton Jones via ghc-devs

Any ideas anyone?   When I restart the build, it gets past the blockage (which 
seems highly specific).  But it’s jolly annoying.

Simon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Simon Peyton 
Jones via ghc-devs
Sent: 04 October 2017 17:25
To: Phyx <loneti...@gmail.com>; ghc-devs@haskell.org
Subject: RE: More windows

As you’ll see the directory is empty when the crash happens.  And yes the 
folder is excluded (from virus checking).

Also this behaviour is new.

Simon

From: Phyx [mailto:loneti...@gmail.com]
Sent: 04 October 2017 14:17
To: Simon Peyton Jones <simo...@microsoft.com<mailto:simo...@microsoft.com>>; 
ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>
Subject: Re: More windows


This looks like a file lock issue. Just to double check, but do you have the 
build folder excluded from the antivirus scanner?

On Wed, Oct 4, 2017, 13:57 Simon Peyton Jones via ghc-devs 
<ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>> wrote:
Now in my Windows build, staring with “sh validate –fast –no-clean” I get

[230 of 232] Compiling Distribution.PackageDescription.Parsec ( 
libraries\Cabal\Cabal\Distribution\PackageDescription\Parsec.hs, 
bootstrapping\Distribution\PackageDescription\Parsec.o )

[231 of 232] Compiling Distribution.Simple ( 
libraries\Cabal\Cabal\Distribution\Simple.hs, 
bootstrapping\Distribution\Simple.o )

[232 of 232] Compiling Main ( utils\ghc-cabal\Main.hs, 
bootstrapping\Main.o )

Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ...

"inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

utils/genprimopcode/ghc.mk:19<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk%3A19=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281=RBB0ZLl%2FEYwO7EfcTXr%2FKugBfnr1ecN%2Febs0rAKu1VE%3D=0>:
 
utils/genprimopcode/dist/package-data.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpackage-data.mk=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281=QeEhyXBxi5n%2FhisTO6hX309ZFk47ek5NtGVDBNKbWLY%3D=0>:
 No such file or directory

make[1]: *** 
[utils/ghc-cabal/ghc.mk:57<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk%3A57=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281=8qZlM0TvQvcySuregiRG5Ip%2FOR%2BVDAM6Dad1hUNEB%2FQ%3D=0>:
 utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1

make[1]: *** Deleting file 'utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe'

make: *** [Makefile:123: all] Error 2

Simply repeating, thus “sh validate –fast”, I then get the same error

/c/code/HEAD$ ls -l utils/ghc-cabal/dist/build/tmp/

total 0

/c/code/HEAD$ sh validate --fast --no-clean

using THREADS=5

make: Entering directory '/c/code/HEAD/utils/checkUniques'

./check-uniques.py ../..

make: Leaving directory '/c/code/HEAD/utils/checkUniques'

===--- building phase 0

make --no-print-directory -f 
ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281=npxwtvhNnwLposvw%2B3k6rdhcQHEW7erd10hWCi5bvjg%3D=0>
 phase=0 phase_0_builds

"c:/fp/ghc-8.0.2/bin/ghc.exe" -O0 -H64m -Wall \

   -optc-Wall -optc-Werror -optc-fno-stack-protector \

\

   -hide-all-packages \

   -package ghc-prim -package base -package array -package transformers 
-package time -package containers -package bytestring -package deepseq -package 
process -package pretty -package directory -package Win32 \

   --make utils/ghc-cabal/Main.hs -o 
utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe \

   -no-user-package-db \

   -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \

   -DCABAL_VERSION=2,0,0,2 \

   -DCABAL_PARSEC \

   -DBOOTSTRAPPING \

   -odir  bootstrapping \

   -hidir bootstrapping \

   bootstrapping/Cabal/Distribution/Parsec/Lexer.hs \

   -ilibraries/Cabal/Cabal \

   -ilibraries/binary/src \

   -ilibraries/filepath \

   -ilibraries/hpc \

   -ilibraries/mtl \

   -ilibraries/text \

   libraries/text/cbits/cbits.c \

   -Ilibraries/text/include \

   -ilibraries/parsec \

\



Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ...

"inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

make[1]: *** 
[utils/ghc-cabal/ghc.mk:57<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk%3A57=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141

Re: More windows

2017-10-04 Thread Phyx

Oh sorry, I missed the ls line, I'll try building master.

On Wed, Oct 4, 2017 at 5:24 PM, Simon Peyton Jones <simo...@microsoft.com>
wrote:

> As you’ll see the directory is empty when the crash happens.  And yes the
> folder is excluded.
>
>
>
> Also this behaviour is new.
>
>
>
> Simon
>
>
>
> *From:* Phyx [mailto:loneti...@gmail.com]
> *Sent:* 04 October 2017 14:17
> *To:* Simon Peyton Jones <simo...@microsoft.com>; ghc-devs@haskell.org
> *Subject:* Re: More windows
>
>
>
> This looks like a file lock issue. Just to double check, but do you have
> the build folder excluded from the antivirus scanner?
>
>
>
> On Wed, Oct 4, 2017, 13:57 Simon Peyton Jones via ghc-devs <
> ghc-devs@haskell.org> wrote:
>
> Now in my Windows build, staring with “sh validate –fast –no-clean” I get
>
> [230 of 232] Compiling Distribution.PackageDescription.Parsec (
> libraries\Cabal\Cabal\Distribution\PackageDescription\Parsec.hs,
> bootstrapping\Distribution\PackageDescription\Parsec.o )
>
> [231 of 232] Compiling Distribution.Simple ( 
> libraries\Cabal\Cabal\Distribution\Simple.hs,
> bootstrapping\Distribution\Simple.o )
>
> [232 of 232] Compiling Main ( utils\ghc-cabal\Main.hs,
> bootstrapping\Main.o )
>
> Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ...
>
> "inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe
>
> Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe
>
> utils/genprimopcode/ghc.mk:19
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk%3A19=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281=RBB0ZLl%2FEYwO7EfcTXr%2FKugBfnr1ecN%2Febs0rAKu1VE%3D=0>:
> utils/genprimopcode/dist/package-data.mk
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpackage-data.mk=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281=QeEhyXBxi5n%2FhisTO6hX309ZFk47ek5NtGVDBNKbWLY%3D=0>:
> No such file or directory
>
> make[1]: *** [utils/ghc-cabal/ghc.mk:57
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk%3A57=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281=8qZlM0TvQvcySuregiRG5Ip%2FOR%2BVDAM6Dad1hUNEB%2FQ%3D=0>:
> utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1
>
> make[1]: *** Deleting file 'utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe'
>
> make: *** [Makefile:123: all] Error 2
>
>
>
> Simply repeating, thus “sh validate –fast”, I then get the same error
>
> /c/code/HEAD$ ls -l utils/ghc-cabal/dist/build/tmp/
>
> total 0
>
> /c/code/HEAD$ sh validate --fast --no-clean
>
> using THREADS=5
>
> make: Entering directory '/c/code/HEAD/utils/checkUniques'
>
> ./check-uniques.py ../..
>
> make: Leaving directory '/c/code/HEAD/utils/checkUniques'
>
> ===--- building phase 0
>
> make --no-print-directory -f ghc.mk
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281=npxwtvhNnwLposvw%2B3k6rdhcQHEW7erd10hWCi5bvjg%3D=0>
> phase=0 phase_0_builds
>
> "c:/fp/ghc-8.0.2/bin/ghc.exe" -O0 -H64m -Wall \
>
>-optc-Wall -optc-Werror -optc-fno-stack-protector \
>
> \
>
>-hide-all-packages \
>
>-package ghc-prim -package base -package array -package
> transformers -package time -package containers -package bytestring -package
> deepseq -package process -package pretty -package directory -package Win32 \
>
>--make utils/ghc-cabal/Main.hs -o 
> utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe
> \
>
>-no-user-package-db \
>
>-Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \
>
>-DCABAL_VERSION=2,0,0,2 \
>
>-DCABAL_PARSEC \
>
>-DBOOTSTRAPPING \
>
>-odir  bootstrapping \
>
>-hidir bootstrapping \
>
>bootstrapping/Cabal/Distribution/Parsec/Lexer.hs \
>
>-ilibraries/Cabal/Cabal \
>
>-ilibraries/binary/src \
>
>-ilibraries/filepath \
>
>-ilibraries/hpc \
>
>-ilibraries/mtl \
>
>-ilibraries/text \
>
>libraries/text/cbits/cbits.c \
>
>-Ilibraries/text/include \
>
>-ilibraries/parsec \
>
> \
>
>
>
> Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ...
>
> "inplace/lib/bin/touchy.

RE: More windows

2017-10-04 Thread Simon Peyton Jones via ghc-devs

As you’ll see the directory is empty when the crash happens.  And yes the 
folder is excluded.

Also this behaviour is new.

Simon

From: Phyx [mailto:loneti...@gmail.com]
Sent: 04 October 2017 14:17
To: Simon Peyton Jones <simo...@microsoft.com>; ghc-devs@haskell.org
Subject: Re: More windows


This looks like a file lock issue. Just to double check, but do you have the 
build folder excluded from the antivirus scanner?

On Wed, Oct 4, 2017, 13:57 Simon Peyton Jones via ghc-devs 
<ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>> wrote:
Now in my Windows build, staring with “sh validate –fast –no-clean” I get

[230 of 232] Compiling Distribution.PackageDescription.Parsec ( 
libraries\Cabal\Cabal\Distribution\PackageDescription\Parsec.hs, 
bootstrapping\Distribution\PackageDescription\Parsec.o )

[231 of 232] Compiling Distribution.Simple ( 
libraries\Cabal\Cabal\Distribution\Simple.hs, 
bootstrapping\Distribution\Simple.o )

[232 of 232] Compiling Main ( utils\ghc-cabal\Main.hs, 
bootstrapping\Main.o )

Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ...

"inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

utils/genprimopcode/ghc.mk:19<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk%3A19=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281=RBB0ZLl%2FEYwO7EfcTXr%2FKugBfnr1ecN%2Febs0rAKu1VE%3D=0>:
 
utils/genprimopcode/dist/package-data.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpackage-data.mk=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281=QeEhyXBxi5n%2FhisTO6hX309ZFk47ek5NtGVDBNKbWLY%3D=0>:
 No such file or directory

make[1]: *** 
[utils/ghc-cabal/ghc.mk:57<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk%3A57=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281=8qZlM0TvQvcySuregiRG5Ip%2FOR%2BVDAM6Dad1hUNEB%2FQ%3D=0>:
 utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1

make[1]: *** Deleting file 'utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe'

make: *** [Makefile:123: all] Error 2

Simply repeating, thus “sh validate –fast”, I then get the same error

/c/code/HEAD$ ls -l utils/ghc-cabal/dist/build/tmp/

total 0

/c/code/HEAD$ sh validate --fast --no-clean

using THREADS=5

make: Entering directory '/c/code/HEAD/utils/checkUniques'

./check-uniques.py ../..

make: Leaving directory '/c/code/HEAD/utils/checkUniques'

===--- building phase 0

make --no-print-directory -f 
ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281=npxwtvhNnwLposvw%2B3k6rdhcQHEW7erd10hWCi5bvjg%3D=0>
 phase=0 phase_0_builds

"c:/fp/ghc-8.0.2/bin/ghc.exe" -O0 -H64m -Wall \

   -optc-Wall -optc-Werror -optc-fno-stack-protector \

\

   -hide-all-packages \

   -package ghc-prim -package base -package array -package transformers 
-package time -package containers -package bytestring -package deepseq -package 
process -package pretty -package directory -package Win32 \

   --make utils/ghc-cabal/Main.hs -o 
utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe \

   -no-user-package-db \

   -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \

   -DCABAL_VERSION=2,0,0,2 \

   -DCABAL_PARSEC \

   -DBOOTSTRAPPING \

   -odir  bootstrapping \

   -hidir bootstrapping \

   bootstrapping/Cabal/Distribution/Parsec/Lexer.hs \

   -ilibraries/Cabal/Cabal \

   -ilibraries/binary/src \

   -ilibraries/filepath \

   -ilibraries/hpc \

   -ilibraries/mtl \

   -ilibraries/text \

   libraries/text/cbits/cbits.c \

   -Ilibraries/text/include \

   -ilibraries/parsec \

\



Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ...

"inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

make[1]: *** 
[utils/ghc-cabal/ghc.mk:57<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk%3A57=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281=8qZlM0TvQvcySuregiRG5Ip%2FOR%2BVDAM6Dad1hUNEB%2FQ%3D=0>:
 utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1

make[1]: *** Deleting file 'utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe'

make: *** [Makefile:123: all] Error 2

But trying “sh validate –fast” once more succeeds:

/c/code/HEAD$ sh validate --fast --no-clean

using THREADS=5

make: Entering directory '/c/code/HEAD/utils/checkU

Re: More windows

2017-10-04 Thread Phyx

This looks like a file lock issue. Just to double check, but do you have
the build folder excluded from the antivirus scanner?

On Wed, Oct 4, 2017, 13:57 Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> Now in my Windows build, staring with “sh validate –fast –no-clean” I get
>
> [230 of 232] Compiling Distribution.PackageDescription.Parsec (
> libraries\Cabal\Cabal\Distribution\PackageDescription\Parsec.hs,
> bootstrapping\Distribution\PackageDescription\Parsec.o )
>
> [231 of 232] Compiling Distribution.Simple (
> libraries\Cabal\Cabal\Distribution\Simple.hs,
> bootstrapping\Distribution\Simple.o )
>
> [232 of 232] Compiling Main ( utils\ghc-cabal\Main.hs,
> bootstrapping\Main.o )
>
> Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ...
>
> "inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe
>
> Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe
>
> utils/genprimopcode/ghc.mk:19: utils/genprimopcode/dist/package-data.mk:
> No such file or directory
>
> make[1]: *** [utils/ghc-cabal/ghc.mk:57:
> utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1
>
> make[1]: *** Deleting file 'utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe'
>
> make: *** [Makefile:123: all] Error 2
>
>
>
> Simply repeating, thus “sh validate –fast”, I then get the same error
>
> /c/code/HEAD$ ls -l utils/ghc-cabal/dist/build/tmp/
>
> total 0
>
> /c/code/HEAD$ sh validate --fast --no-clean
>
> using THREADS=5
>
> make: Entering directory '/c/code/HEAD/utils/checkUniques'
>
> ./check-uniques.py ../..
>
> make: Leaving directory '/c/code/HEAD/utils/checkUniques'
>
> ===--- building phase 0
>
> make --no-print-directory -f ghc.mk phase=0 phase_0_builds
>
> "c:/fp/ghc-8.0.2/bin/ghc.exe" -O0 -H64m -Wall \
>
>-optc-Wall -optc-Werror -optc-fno-stack-protector \
>
> \
>
>-hide-all-packages \
>
>-package ghc-prim -package base -package array -package
> transformers -package time -package containers -package bytestring -package
> deepseq -package process -package pretty -package directory -package Win32 \
>
>--make utils/ghc-cabal/Main.hs -o
> utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe \
>
>-no-user-package-db \
>
>-Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \
>
>-DCABAL_VERSION=2,0,0,2 \
>
>-DCABAL_PARSEC \
>
>-DBOOTSTRAPPING \
>
>-odir  bootstrapping \
>
>-hidir bootstrapping \
>
>bootstrapping/Cabal/Distribution/Parsec/Lexer.hs \
>
>-ilibraries/Cabal/Cabal \
>
>-ilibraries/binary/src \
>
>-ilibraries/filepath \
>
>-ilibraries/hpc \
>
>-ilibraries/mtl \
>
>-ilibraries/text \
>
>libraries/text/cbits/cbits.c \
>
>-Ilibraries/text/include \
>
>-ilibraries/parsec \
>
> \
>
>
>
> Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ...
>
> "inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe
>
> Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe
>
> make[1]: *** [utils/ghc-cabal/ghc.mk:57:
> utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1
>
> make[1]: *** Deleting file 'utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe'
>
> make: *** [Makefile:123: all] Error 2
>
>
>
> But trying “sh validate –fast” once more succeeds:
>
> /c/code/HEAD$ sh validate --fast --no-clean
>
> using THREADS=5
>
> make: Entering directory '/c/code/HEAD/utils/checkUniques'
>
> ./check-uniques.py ../..
>
> make: Leaving directory '/c/code/HEAD/utils/checkUniques'
>
> ===--- building phase 0
>
> make --no-print-directory -f ghc.mk phase=0 phase_0_builds
>
> "c:/fp/ghc-8.0.2/bin/ghc.exe" -O0 -H64m -Wall \
>
>-optc-Wall -optc-Werror -optc-fno-stack-protector \
>
> \
>
>-hide-all-packages \
>
>-package ghc-prim -package base -package array -package
> transformers -package time -package containers -package bytestring -package
> deepseq -package process -package pretty -package directory -package Win32 \
>
>--make utils/ghc-cabal/Main.hs -o
> utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe \
>
>-no-user-package-db \
>
>-Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \
>
>-DCABAL_VERSION=2,0,0,2 \
>
>-DCABAL_PARSEC \
>
>-DBOOTSTRAPPING \
>
>-odir  bootstrapping \
>
>-hidir bootstrapping \
>
>bootstrapping/Cabal/Distribution/Parsec/Lexer.hs \
>
>-ilibraries/Cabal/Cabal \
>
>-ilibraries/binary/src \
>
>-ilibraries/filepath \
>
>-ilibraries/hpc \
>
>-ilibraries/mtl \
>
>-ilibraries/text \
>
>libraries/text/cbits/cbits.c \
>
>-Ilibraries/text/include \
>
>-ilibraries/parsec \
>
> \
>
>
>
> Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ...
>
> "inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe
>
> "cp" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe inplace/bin/ghc-cabal.exe

More windows

2017-10-04 Thread Simon Peyton Jones via ghc-devs

Now in my Windows build, staring with "sh validate -fast -no-clean" I get

[230 of 232] Compiling Distribution.PackageDescription.Parsec ( 
libraries\Cabal\Cabal\Distribution\PackageDescription\Parsec.hs, 
bootstrapping\Distribution\PackageDescription\Parsec.o )

[231 of 232] Compiling Distribution.Simple ( 
libraries\Cabal\Cabal\Distribution\Simple.hs, 
bootstrapping\Distribution\Simple.o )

[232 of 232] Compiling Main ( utils\ghc-cabal\Main.hs, 
bootstrapping\Main.o )

Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ...

"inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

utils/genprimopcode/ghc.mk:19: utils/genprimopcode/dist/package-data.mk: No 
such file or directory

make[1]: *** [utils/ghc-cabal/ghc.mk:57: 
utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1

make[1]: *** Deleting file 'utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe'

make: *** [Makefile:123: all] Error 2

Simply repeating, thus "sh validate -fast", I then get the same error

/c/code/HEAD$ ls -l utils/ghc-cabal/dist/build/tmp/

total 0

/c/code/HEAD$ sh validate --fast --no-clean

using THREADS=5

make: Entering directory '/c/code/HEAD/utils/checkUniques'

./check-uniques.py ../..

make: Leaving directory '/c/code/HEAD/utils/checkUniques'

===--- building phase 0

make --no-print-directory -f ghc.mk phase=0 phase_0_builds

"c:/fp/ghc-8.0.2/bin/ghc.exe" -O0 -H64m -Wall \

   -optc-Wall -optc-Werror -optc-fno-stack-protector \

\

   -hide-all-packages \

   -package ghc-prim -package base -package array -package transformers 
-package time -package containers -package bytestring -package deepseq -package 
process -package pretty -package directory -package Win32 \

   --make utils/ghc-cabal/Main.hs -o 
utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe \

   -no-user-package-db \

   -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \

   -DCABAL_VERSION=2,0,0,2 \

   -DCABAL_PARSEC \

   -DBOOTSTRAPPING \

   -odir  bootstrapping \

   -hidir bootstrapping \

   bootstrapping/Cabal/Distribution/Parsec/Lexer.hs \

   -ilibraries/Cabal/Cabal \

   -ilibraries/binary/src \

   -ilibraries/filepath \

   -ilibraries/hpc \

   -ilibraries/mtl \

   -ilibraries/text \

   libraries/text/cbits/cbits.c \

   -Ilibraries/text/include \

   -ilibraries/parsec \

\



Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ...

"inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

make[1]: *** [utils/ghc-cabal/ghc.mk:57: 
utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1

make[1]: *** Deleting file 'utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe'

make: *** [Makefile:123: all] Error 2

But trying "sh validate -fast" once more succeeds:

/c/code/HEAD$ sh validate --fast --no-clean

using THREADS=5

make: Entering directory '/c/code/HEAD/utils/checkUniques'

./check-uniques.py ../..

make: Leaving directory '/c/code/HEAD/utils/checkUniques'

===--- building phase 0

make --no-print-directory -f ghc.mk phase=0 phase_0_builds

"c:/fp/ghc-8.0.2/bin/ghc.exe" -O0 -H64m -Wall \

   -optc-Wall -optc-Werror -optc-fno-stack-protector \

\

   -hide-all-packages \

   -package ghc-prim -package base -package array -package transformers 
-package time -package containers -package bytestring -package deepseq -package 
process -package pretty -package directory -package Win32 \

   --make utils/ghc-cabal/Main.hs -o 
utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe \

   -no-user-package-db \

   -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \

   -DCABAL_VERSION=2,0,0,2 \

   -DCABAL_PARSEC \

   -DBOOTSTRAPPING \

   -odir  bootstrapping \

   -hidir bootstrapping \

   bootstrapping/Cabal/Distribution/Parsec/Lexer.hs \

   -ilibraries/Cabal/Cabal \

   -ilibraries/binary/src \

   -ilibraries/filepath \

   -ilibraries/hpc \

   -ilibraries/mtl \

   -ilibraries/text \

   libraries/text/cbits/cbits.c \

   -Ilibraries/text/include \

   -ilibraries/parsec \

\



Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ...

"inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

"cp" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe inplace/bin/ghc-cabal.exe

"inplace/bin/ghc-cabal.exe" configure libraries/binary dist-boot 
--with-ghc="c:/fp/ghc-8.0.2/bin/ghc.exe" 
--with-ghc-pkg="c:/fp/ghc-8.0.2/bin/ghc-pkg"  
--package-db=C:/code/HEAD/libraries/bootstrapping.conf 
--disable-library-for-ghci --enable-library-vanilla --enable-library-for-ghci 
--disable-library-profiling --disable-shared 
--with-hscolour="/c/fp/HP-8.0.1/lib/extralibs/bin/HsColour" 
--configure-option=CFLAGS="-Wall -fno-stack-protector-Wno-error=inline"

RE: More windows woe

2016-12-10 Thread Simon Peyton Jones via ghc-devs

Adding unlock_file makes ghci work.

Simon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Simon Peyton 
Jones via ghc-devs
Sent: 10 December 2016 10:57
To: Phyx <loneti...@gmail.com>
Cc: GHC developers <ghc-devs@haskell.org>
Subject: RE: More windows woe

Reverting didn’t work
Appluying D2817 didn’t work:

/c/code/HEAD$ c:/code/HEAD/inplace/bin/ghc-stage2 --interactive

GHCi, version 8.1.20161209: http://www.haskell.org/ghc/  :? for help

ghc-stage2.exe: unable to load package `base-4.9.0.0'

ghc-stage2.exe: C:\code\HEAD\inplace\mingw\x86_64-w64-mingw32\lib\libmingwex.a: 
unknown symbol `_unlock_file'
Now it’s ‘unlock_file’.

I’ll try adding that.

Simon

From: Phyx [mailto:loneti...@gmail.com]
Sent: 09 December 2016 23:07
To: Simon Peyton Jones <simo...@microsoft.com<mailto:simo...@microsoft.com>>
Subject: Re: More windows woe

When fixing bootstrapping with pre 7.10.3 compilers this accidentally broke.

There's a patch up to fix it https://phabricator.haskell.org/D2817

If you're on 7.10.3 or later for your bootstrapping compiler revert 
6da62535469149d69ec98674db1c51dbde0efab1 and it should work again.

Just waiting for a buildbot build to commit the above patch.

On Fri, Dec 9, 2016 at 10:44 PM, Simon Peyton Jones via ghc-devs 
<ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>> wrote:
I see that anything involving ghci fails:

/c/code/HEAD/inplace/bin/ghc-stage2 --interactive

GHCi, version 8.1.20161209: 
http://www.haskell.org/ghc/<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.haskell.org%2Fghc%2F=02%7C01%7Csimonpj%40microsoft.com%7C645b80a482bc46d4e53908d4208822bd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636169216450988956=oJXATz0N9foTtRlW6ZzI4RrP%2BkLRGvTP7l2mDqbsYG8%3D=0>
  :? for help

ghc-stage2.exe: unable to load package `base-4.9.0.0'

ghc-stage2.exe: C:\code\HEAD\inplace\mingw\x86_64-w64-mingw32\lib\libmingwex.a: 
unknown symbol `_lock_file'

ghc-stage2.exe: Could not on-demand load symbol '__mingw_vfprintf'

ghc-stage2.exe: 
C:\code\HEAD\libraries\base\dist-install\build\HSbase-4.9.0.0.o: unknown symbol 
`__mingw_vfprintf'

It’s frustrating.  It used to work!
Simon

___
ghc-devs mailing list
ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs=02%7C01%7Csimonpj%40microsoft.com%7C645b80a482bc46d4e53908d4208822bd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636169216450988956=KyMde8fx2GXKK1MocZ6dHobUYXMKuWvA%2FH%2F24kqmwYA%3D=0>

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

RE: More windows woe

2016-12-10 Thread Simon Peyton Jones via ghc-devs

But meanwhile is there any way to get a working windows build?  I'm totally 
stalled on all fronts.  

It was ok a few days ago

Thanks

Simon

| -Original Message-
| From: Ben Gamari [mailto:b...@well-typed.com]
| Sent: 10 December 2016 03:44
| To: Simon Peyton Jones <simo...@microsoft.com>; GHC developers 
| Subject: Re: More windows woe
| 
| Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> writes:
| 
| > I see that anything involving ghci fails:
| >
| > /c/code/HEAD/inplace/bin/ghc-stage2 --interactive
| >
| > GHCi, version 8.1.20161209: http://www.haskell.org/ghc/  :? for help
| >
| > ghc-stage2.exe: unable to load package `base-4.9.0.0'
| >
| > ghc-stage2.exe: C:\code\HEAD\inplace\mingw\x86_64-w64-
| mingw32\lib\libmingwex.a: unknown symbol `_lock_file'
| >
| Yes, Tamar and I were working on tracking this down over the last few
| days. The patch (which I will merge after a running validation finishes)
| is D2817.
| 
| In short, the problem is that we recently upgraded the Windows toolchain.
| For better or worse, the new mingw-w64 toolchain now has an atomic printf
| implementation, which requires the use of the _lock_file function
| provided by Microsoft's C runtime. However, the _lock_file symbol is only
| exported by certain variants of msvcrt (e.g. msvcrt90.dll), but not the
| distribution which mingw-w64 uses (apparently due to license
| considerations [1], although the exact reason isn't clear).
| 
| To hack around this, mingw-w64 ships a static library, msvcrt.a, which
| wraps msvcrt.dll and provides hand-rolled implementations of some needed
| symbols, including _lock_file. However, this means that the static
| library msvcrt.a, and the dynamic library msvcrt.dll don't export the
| same set of symbols, which causes GHCi to blow up if dynamically linked.
| Consequently we need to
| 
| All of this coupled with another recent but quite unrelated cleanup
| (D2579) breaking the Windows build when bootstrapped with GHC 7.10, the
| recent testsuite debacle, as well as a number of other Windows quirks
| I've discovered in the past few weeks, meant that figuring all of this
| out took quite some time (which is why the Windows builder *still* isn't
| quite up). On the bright side, one happy side-effort of this is that it
| prompted me to write down some notes on the interactions between the many
| components of our Windows toolchain [2].
| 
| Anyways, we are getting quite close. I expect we'll finally have the
| Windows builder up by next week. Hopefully from that point forth it will
| be considerably harder to break the Windows build.
| 
| Cheers,
| 
| - Ben
| 
| 
| [1] https://sourceforge.net/p/mingw-
| w64/discussion/723797/thread/55520785/
| [2] https://ghc.haskell.org/trac/ghc/wiki/SurvivingWIndows
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: More windows woe

2016-12-10 Thread Simon Peyton Jones via ghc-devs

Reverting didn’t work
Appluying D2817 didn’t work:

/c/code/HEAD$ c:/code/HEAD/inplace/bin/ghc-stage2 --interactive

GHCi, version 8.1.20161209: http://www.haskell.org/ghc/  :? for help

ghc-stage2.exe: unable to load package `base-4.9.0.0'

ghc-stage2.exe: C:\code\HEAD\inplace\mingw\x86_64-w64-mingw32\lib\libmingwex.a: 
unknown symbol `_unlock_file'
Now it’s ‘unlock_file’.

I’ll try adding that.

Simon

From: Phyx [mailto:loneti...@gmail.com]
Sent: 09 December 2016 23:07
To: Simon Peyton Jones <simo...@microsoft.com>
Subject: Re: More windows woe

When fixing bootstrapping with pre 7.10.3 compilers this accidentally broke.

There's a patch up to fix it https://phabricator.haskell.org/D2817

If you're on 7.10.3 or later for your bootstrapping compiler revert 
6da62535469149d69ec98674db1c51dbde0efab1 and it should work again.

Just waiting for a buildbot build to commit the above patch.

On Fri, Dec 9, 2016 at 10:44 PM, Simon Peyton Jones via ghc-devs 
<ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>> wrote:
I see that anything involving ghci fails:

/c/code/HEAD/inplace/bin/ghc-stage2 --interactive

GHCi, version 8.1.20161209: 
http://www.haskell.org/ghc/<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.haskell.org%2Fghc%2F=02%7C01%7Csimonpj%40microsoft.com%7C645b80a482bc46d4e53908d4208822bd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636169216450988956=oJXATz0N9foTtRlW6ZzI4RrP%2BkLRGvTP7l2mDqbsYG8%3D=0>
  :? for help

ghc-stage2.exe: unable to load package `base-4.9.0.0'

ghc-stage2.exe: C:\code\HEAD\inplace\mingw\x86_64-w64-mingw32\lib\libmingwex.a: 
unknown symbol `_lock_file'



ghc-stage2.exe: Could not on-demand load symbol '__mingw_vfprintf'



ghc-stage2.exe: 
C:\code\HEAD\libraries\base\dist-install\build\HSbase-4.9.0.0.o: unknown symbol 
`__mingw_vfprintf'

It’s frustrating.  It used to work!
Simon



___
ghc-devs mailing list
ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs=02%7C01%7Csimonpj%40microsoft.com%7C645b80a482bc46d4e53908d4208822bd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636169216450988956=KyMde8fx2GXKK1MocZ6dHobUYXMKuWvA%2FH%2F24kqmwYA%3D=0>

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

Re: More windows woe

2016-12-09 Thread Ben Gamari

Ben Gamari  writes:

> Simon Peyton Jones via ghc-devs  writes:
>
>> I see that anything involving ghci fails:
>>
>> /c/code/HEAD/inplace/bin/ghc-stage2 --interactive
>>
>> GHCi, version 8.1.20161209: http://www.haskell.org/ghc/  :? for help
>>
>> ghc-stage2.exe: unable to load package `base-4.9.0.0'
>>
>> ghc-stage2.exe: 
>> C:\code\HEAD\inplace\mingw\x86_64-w64-mingw32\lib\libmingwex.a: unknown 
>> symbol `_lock_file'
>>
> Yes, Tamar and I were working on tracking this down over the last few
> days. The patch (which I will merge after a running validation finishes)
> is D2817.
>
For the record I was able to validate this locally and merged it.
Unfortunately it seems that Harbormaster still chokes, so your milage
may vary. I'll have a look tomorrow.

The saga continues...

Cheers,

- Ben



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

Re: More windows woe

2016-12-09 Thread Ben Gamari

Edward Yang pointed out a truncated sentence in this message. See below.
Thank you Edward!

Cheers,

- Ben



Ben Gamari  writes:

> Simon Peyton Jones via ghc-devs  writes:
>
...
>
> To hack around this, mingw-w64 ships a static library, msvcrt.a, which
> wraps msvcrt.dll and provides hand-rolled implementations of some needed
> symbols, including _lock_file. However, this means that the static
> library msvcrt.a, and the dynamic library msvcrt.dll don't export the
> same set of symbols, which causes GHCi to blow up if dynamically linked.
> Consequently we need to 
>
The last sentence should have read,

> Consequently we need to ensure that the runtime linker seeds its
> own symbol table with these symbols.



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

Re: More windows woe

2016-12-09 Thread Ben Gamari

Simon Peyton Jones via ghc-devs  writes:

> I see that anything involving ghci fails:
>
> /c/code/HEAD/inplace/bin/ghc-stage2 --interactive
>
> GHCi, version 8.1.20161209: http://www.haskell.org/ghc/  :? for help
>
> ghc-stage2.exe: unable to load package `base-4.9.0.0'
>
> ghc-stage2.exe: 
> C:\code\HEAD\inplace\mingw\x86_64-w64-mingw32\lib\libmingwex.a: unknown 
> symbol `_lock_file'
>
Yes, Tamar and I were working on tracking this down over the last few
days. The patch (which I will merge after a running validation finishes)
is D2817.

In short, the problem is that we recently upgraded the Windows toolchain.
For better or worse, the new mingw-w64 toolchain now has an atomic
printf implementation, which requires the use of the _lock_file function
provided by Microsoft's C runtime. However, the _lock_file symbol is
only exported by certain variants of msvcrt (e.g. msvcrt90.dll), but not
the distribution which mingw-w64 uses (apparently due to license
considerations [1], although the exact reason isn't clear).

To hack around this, mingw-w64 ships a static library, msvcrt.a, which
wraps msvcrt.dll and provides hand-rolled implementations of some needed
symbols, including _lock_file. However, this means that the static
library msvcrt.a, and the dynamic library msvcrt.dll don't export the
same set of symbols, which causes GHCi to blow up if dynamically linked.
Consequently we need to 

All of this coupled with another recent but quite unrelated cleanup
(D2579) breaking the Windows build when bootstrapped with GHC 7.10, the
recent testsuite debacle, as well as a number of other Windows quirks
I've discovered in the past few weeks, meant that figuring all of this
out took quite some time (which is why the Windows builder *still* isn't
quite up). On the bright side, one happy side-effort of this is that it
prompted me to write down some notes on the interactions between the
many components of our Windows toolchain [2].

Anyways, we are getting quite close. I expect we'll finally have the
Windows builder up by next week. Hopefully from that point forth it will
be considerably harder to break the Windows build.

Cheers,

- Ben

[1] https://sourceforge.net/p/mingw-w64/discussion/723797/thread/55520785/
[2] https://ghc.haskell.org/trac/ghc/wiki/SurvivingWIndows

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

More windows woe

2016-12-09 Thread Simon Peyton Jones via ghc-devs

I see that anything involving ghci fails:

/c/code/HEAD/inplace/bin/ghc-stage2 --interactive

GHCi, version 8.1.20161209: http://www.haskell.org/ghc/  :? for help

ghc-stage2.exe: unable to load package `base-4.9.0.0'

ghc-stage2.exe: C:\code\HEAD\inplace\mingw\x86_64-w64-mingw32\lib\libmingwex.a: 
unknown symbol `_lock_file'



ghc-stage2.exe: Could not on-demand load symbol '__mingw_vfprintf'



ghc-stage2.exe: 
C:\code\HEAD\libraries\base\dist-install\build\HSbase-4.9.0.0.o: unknown symbol 
`__mingw_vfprintf'

It's frustrating.  It used to work!
Simon


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

RE: More windows woe

2013-09-04 Thread Edward Z. Yang

I got my hands on a Windows build box, so I'll also go and see if
I can get a build working on Windows.

Excerpts from Simon Peyton-Jones's message of Tue Sep 03 07:33:32 -0700 2013:
 Simon Marlow: please help!
 At the moment windows builds are hosed, which is a Bad Situation.
 
 Actually it turns out that what want is
 
   debugBelch(Checking whether to unload %S\n, oc-fileName));
 
 That is, use %S rather than %s as format specifier for wide chars.
 
 Sadly, this works on Windows, but not on Linux:
 rts/CheckUnload.c:260:13:
  error: format ‘%S’ expects argument of type ‘wchar_t *’, but argument 2 
 has type ‘pathchar *’ [-Werror=format]
 
 
 So what I need guidance on, please!, is what the approved way to deal with 
 this is.  I suppose that I could identify each use of %s on a filepath and say
 
 #ifdef mingw32_HOST_OS
   debugBelch(Checking whether to unload %S\n, oc-fileName));
 #else
   debugBelch(Checking whether to unload %s\n, oc-fileName));
 #endif
 
 But that seems deeply unsatisfactory doesn't it?
 
 If not that, then what?
 
 
 Simon
 
 | -Original Message-
 | From: Edward Z. Yang [mailto:ezy...@mit.edu]
 | Sent: 28 August 2013 20:59
 | To: Simon Peyton-Jones
 | Cc: ghc-devs@haskell.org
 | Subject: Re: More windows woe
 | 
 | My guess is the printf's need to be replaced with swprintf's.
 | 
 | Edward
 | 
 | Excerpts from Simon Peyton-Jones's message of Wed Aug 28 01:25:26 -0700
 | 2013:
 |  OK, so now my windows build is getting further, but it now falls over
 | here.  This one looks more straightforward!  Can anyone help?
 | 
 |  Simon
 | 
 |  inplace/bin/ghc-stage1.exe -optc-Werror -optc-Wall -optc-Wall -optc-
 | Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-
 | Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-
 | Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-
 | Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-
 | Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-
 | ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-
 | DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-O2 -
 | optc-fomit-frame-pointer -optc-fno-omit-frame-pointer -optc-g -optc-O0 -
 | optc-DRtsWay=\rts_debug\ -static -optc-DDEBUG -ticky -DTICKY_TICKY  -
 | H32m -O -Werror -Wall -H64m -O0 -Iincludes -Iincludes/dist -
 | Iincludes/dist-derivedconstants/header -Iincludes/dist-
 | ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name
 | rts -dcmm-lint  -i -irts -irts/dist/build -irts/dist/build/autogen -
 | Irts/dist/build -Irts/dist/build/autogen   -O2 -O0-c
 | rts/CheckUnload.c -o rts/dist/build/CheckUnload.debug_o
 |  cc1.exe: warnings being treated as errors
 |  rts\CheckUnload.c: In function 'checkUnload':
 | 
 |  rts\CheckUnload.c:257:7:
 |   error: format '%s' expects type 'char *', but argument 2 has type
 | 'pathchar *'
 | 
 |  rts\CheckUnload.c:293:11:
 |   error: format '%s' expects type 'char *', but argument 2 has type
 | 'pathchar *'
 | 
 |  rts\CheckUnload.c:297:11:
 |   error: format '%s' expects type 'char *', but argument 2 has type
 | 'pathchar *'
 |  bash-3.1$

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

Re: RE: More windows woe

2013-09-04 Thread Edward Z. Yang

I think this is reasonable, with the added caveat that
the macros should be placed in includes/rts/Linker.h, because that is
where pathchar is defined.  So how about something like:

diff --git a/includes/rts/Linker.h b/includes/rts/Linker.h
index e900e85..871b8cd 100644
--- a/includes/rts/Linker.h
+++ b/includes/rts/Linker.h
@@ -16,8 +16,10 @@

 #if defined(mingw32_HOST_OS)
 typedef wchar_t pathchar;
+#define FMT_PATH %S
 #else
 typedef charpathchar;
+#define FMT_PATH %s
 #endif

 /* initialize the object linker */
diff --git a/rts/CheckUnload.c b/rts/CheckUnload.c
index a758b06..8dc8fdc 100644
--- a/rts/CheckUnload.c
+++ b/rts/CheckUnload.c
@@ -254,7 +254,7 @@ void checkUnload (StgClosure *static_objects)

   // Mark every unloadable object as unreferenced initially
   for (oc = unloaded_objects; oc; oc = oc-next) {
-  IF_DEBUG(linker, debugBelch(Checking whether to unload %s\n,
+  IF_DEBUG(linker, debugBelch(Checking whether to unload  FMT_PATH \n,
   oc-fileName));
   oc-referenced = rtsFalse;
   }
@@ -290,11 +290,11 @@ void checkUnload (StgClosure *static_objects)
   } else {
   prev-next = oc-next;
   }
-  IF_DEBUG(linker, debugBelch(Unloading object file %s\n,
+  IF_DEBUG(linker, debugBelch(Unloading object file  FMT_PATH \n,
   oc-fileName));
   freeObjectCode(oc);
   } else {
-  IF_DEBUG(linker, debugBelch(Object file still in use: %s\n,
+  IF_DEBUG(linker, debugBelch(Object file still in use:  FMT_PATH 
\n,
   oc-fileName));
   }
   }
diff --git a/rts/Linker.c b/rts/Linker.c
index 6490242..4f0a1c4 100644
--- a/rts/Linker.c
+++ b/rts/Linker.c
@@ -2790,7 +2790,7 @@ unloadObj( pathchar *path )

 initLinker();

-IF_DEBUG(linker, debugBelch(unloadObj: %s\n, path));
+IF_DEBUG(linker, debugBelch(unloadObj:  FMT_PATH \n, path));

 prev = NULL;
 for (oc = objects; oc; prev = oc, oc = next) {

Excerpts from Jost Berthold's message of Tue Sep 03 12:56:03 -0700 2013:
  From: Simon Peyton-Jones simo...@microsoft.com
  To: Edward Z. Yang ezy...@mit.edu, Simon Marlow
  marlo...@gmail.com
  Cc: ghc-devs@haskell.org ghc-devs@haskell.org
  Subject: RE: More windows woe
  Message-ID:
  
  59543203684b2244980d7e4057d5fbc1485bb...@db3ex14mbxc308.europe.corp.microsoft.com
  
  Content-Type: text/plain; charset=utf-8
 
  Simon Marlow: please help!
  At the moment windows builds are hosed, which is a Bad Situation.
 
  Actually it turns out that what want is
 
 debugBelch(Checking whether to unload %S\n, oc-fileName));
 
  That is, use %S rather than %s as format specifier for wide chars.
 
  Sadly, this works on Windows, but not on Linux:
  rts/CheckUnload.c:260:13:
error: format ?%S? expects argument of type ?wchar_t *?, but argument 
  2 has type ?pathchar *? [-Werror=format]
 
 
  So what I need guidance on, please!, is what the approved way to deal with 
  this is.  I suppose that I could identify each use of %s on a filepath and 
  say
 
  #ifdef mingw32_HOST_OS
 debugBelch(Checking whether to unload %S\n, oc-fileName));
  #else
 debugBelch(Checking whether to unload %s\n, oc-fileName));
  #endif
 
  But that seems deeply unsatisfactory doesn't it?
 
  If not that, then what?
 
 
  Simon
 
 Similar code is in place to distinguish between 32-bit and 64-bit StgWords:
 
   grep -r -e FMT_Word includes/
 includes/stg/Types.h:#define FMT_Word32u
 includes/stg/Types.h:#define FMT_Word32lu
 includes/stg/Types.h:#define FMT_Word64lu
 includes/stg/Types.h:#define FMT_Word64llu
 includes/stg/Types.h:#define FMT_Word FMT_Word64
 includes/stg/Types.h:#define FMT_Word FMT_Word32
 
 and format strings like blabla  FMT_Word  ..blabla are used inside 
 rts/. One could do the same for FMT_Path and introduce it where required.
 
 Maybe this would be acceptable?
 
 / Jost
 

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

RE: RE: More windows woe

2013-09-04 Thread Simon Peyton-Jones

 IF_DEBUG(linker, debugBelch(Checking whether to unload  FMT_PATH \n,

doesn't that expand to 

 IF_DEBUG(linker, debugBelch(Checking whether to unload  %S \n,

What does the C compiler make of three strings in a row?  Does it automatically 
concatenate them? Is that ANSI C?

S

| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Edward
| Z. Yang
| Sent: 04 September 2013 10:15
| To: Jost Berthold
| Cc: ghc-devs
| Subject: Re: RE: More windows woe
| 
| I think this is reasonable, with the added caveat that
| the macros should be placed in includes/rts/Linker.h, because that is
| where pathchar is defined.  So how about something like:
| 
| diff --git a/includes/rts/Linker.h b/includes/rts/Linker.h
| index e900e85..871b8cd 100644
| --- a/includes/rts/Linker.h
| +++ b/includes/rts/Linker.h
| @@ -16,8 +16,10 @@
| 
|  #if defined(mingw32_HOST_OS)
|  typedef wchar_t pathchar;
| +#define FMT_PATH %S
|  #else
|  typedef charpathchar;
| +#define FMT_PATH %s
|  #endif
| 
|  /* initialize the object linker */
| diff --git a/rts/CheckUnload.c b/rts/CheckUnload.c
| index a758b06..8dc8fdc 100644
| --- a/rts/CheckUnload.c
| +++ b/rts/CheckUnload.c
| @@ -254,7 +254,7 @@ void checkUnload (StgClosure *static_objects)
| 
|// Mark every unloadable object as unreferenced initially
|for (oc = unloaded_objects; oc; oc = oc-next) {
| -  IF_DEBUG(linker, debugBelch(Checking whether to unload %s\n,
| +  IF_DEBUG(linker, debugBelch(Checking whether to unload 
| FMT_PATH \n,
|oc-fileName));
|oc-referenced = rtsFalse;
|}
| @@ -290,11 +290,11 @@ void checkUnload (StgClosure *static_objects)
|} else {
|prev-next = oc-next;
|}
| -  IF_DEBUG(linker, debugBelch(Unloading object file %s\n,
| +  IF_DEBUG(linker, debugBelch(Unloading object file  FMT_PATH
| \n,
|oc-fileName));
|freeObjectCode(oc);
|} else {
| -  IF_DEBUG(linker, debugBelch(Object file still in use: %s\n,
| +  IF_DEBUG(linker, debugBelch(Object file still in use: 
| FMT_PATH \n,
|oc-fileName));
|}
|}
| diff --git a/rts/Linker.c b/rts/Linker.c
| index 6490242..4f0a1c4 100644
| --- a/rts/Linker.c
| +++ b/rts/Linker.c
| @@ -2790,7 +2790,7 @@ unloadObj( pathchar *path )
| 
|  initLinker();
| 
| -IF_DEBUG(linker, debugBelch(unloadObj: %s\n, path));
| +IF_DEBUG(linker, debugBelch(unloadObj:  FMT_PATH \n, path));
| 
|  prev = NULL;
|  for (oc = objects; oc; prev = oc, oc = next) {
| 
| Excerpts from Jost Berthold's message of Tue Sep 03 12:56:03 -0700 2013:
|   From: Simon Peyton-Jones simo...@microsoft.com
|   To: Edward Z. Yang ezy...@mit.edu, Simon Marlow
|   marlo...@gmail.com
|   Cc: ghc-devs@haskell.org ghc-devs@haskell.org
|   Subject: RE: More windows woe
|   Message-ID:
|  
| 59543203684b2244980d7e4057d5fbc1485bb...@db3ex14mbxc308.europe.corp.mic
| rosoft.com
|  
|   Content-Type: text/plain; charset=utf-8
|  
|   Simon Marlow: please help!
|   At the moment windows builds are hosed, which is a Bad Situation.
|  
|   Actually it turns out that what want is
|  
|  debugBelch(Checking whether to unload %S\n, oc-fileName));
|  
|   That is, use %S rather than %s as format specifier for wide
| chars.
|  
|   Sadly, this works on Windows, but not on Linux:
|   rts/CheckUnload.c:260:13:
| error: format ?%S? expects argument of type ?wchar_t *?, but
| argument 2 has type ?pathchar *? [-Werror=format]
|  
|  
|   So what I need guidance on, please!, is what the approved way to
| deal with this is.  I suppose that I could identify each use of %s on a
| filepath and say
|  
|   #ifdef mingw32_HOST_OS
|  debugBelch(Checking whether to unload %S\n, oc-fileName));
|   #else
|  debugBelch(Checking whether to unload %s\n, oc-fileName));
|   #endif
|  
|   But that seems deeply unsatisfactory doesn't it?
|  
|   If not that, then what?
|  
|  
|   Simon
| 
|  Similar code is in place to distinguish between 32-bit and 64-bit
| StgWords:
| 
|grep -r -e FMT_Word includes/
|  includes/stg/Types.h:#define FMT_Word32u
|  includes/stg/Types.h:#define FMT_Word32lu
|  includes/stg/Types.h:#define FMT_Word64lu
|  includes/stg/Types.h:#define FMT_Word64llu
|  includes/stg/Types.h:#define FMT_Word FMT_Word64
|  includes/stg/Types.h:#define FMT_Word FMT_Word32
| 
|  and format strings like blabla  FMT_Word  ..blabla are used inside
|  rts/. One could do the same for FMT_Path and introduce it where
| required.
| 
|  Maybe this would be acceptable?
| 
|  / Jost
| 
| 
| ___
| 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

RE: RE: More windows woe

2013-09-04 Thread Edward Z. Yang

Yep, it's string concatenation, and it's ANSI C as per 5.1.1.2.  We use this
idiom in other parts of the RTS.

Cheers,
Edward

Excerpts from Simon Peyton-Jones's message of Wed Sep 04 02:22:48 -0700 2013:
  IF_DEBUG(linker, debugBelch(Checking whether to unload  FMT_PATH \n,
 
 doesn't that expand to 
 
  IF_DEBUG(linker, debugBelch(Checking whether to unload  %S \n,
 
 What does the C compiler make of three strings in a row?  Does it 
 automatically concatenate them? Is that ANSI C?
 
 S
 
 | -Original Message-
 | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Edward
 | Z. Yang
 | Sent: 04 September 2013 10:15
 | To: Jost Berthold
 | Cc: ghc-devs
 | Subject: Re: RE: More windows woe
 | 
 | I think this is reasonable, with the added caveat that
 | the macros should be placed in includes/rts/Linker.h, because that is
 | where pathchar is defined.  So how about something like:
 | 
 | diff --git a/includes/rts/Linker.h b/includes/rts/Linker.h
 | index e900e85..871b8cd 100644
 | --- a/includes/rts/Linker.h
 | +++ b/includes/rts/Linker.h
 | @@ -16,8 +16,10 @@
 | 
 |  #if defined(mingw32_HOST_OS)
 |  typedef wchar_t pathchar;
 | +#define FMT_PATH %S
 |  #else
 |  typedef charpathchar;
 | +#define FMT_PATH %s
 |  #endif
 | 
 |  /* initialize the object linker */
 | diff --git a/rts/CheckUnload.c b/rts/CheckUnload.c
 | index a758b06..8dc8fdc 100644
 | --- a/rts/CheckUnload.c
 | +++ b/rts/CheckUnload.c
 | @@ -254,7 +254,7 @@ void checkUnload (StgClosure *static_objects)
 | 
 |// Mark every unloadable object as unreferenced initially
 |for (oc = unloaded_objects; oc; oc = oc-next) {
 | -  IF_DEBUG(linker, debugBelch(Checking whether to unload %s\n,
 | +  IF_DEBUG(linker, debugBelch(Checking whether to unload 
 | FMT_PATH \n,
 |oc-fileName));
 |oc-referenced = rtsFalse;
 |}
 | @@ -290,11 +290,11 @@ void checkUnload (StgClosure *static_objects)
 |} else {
 |prev-next = oc-next;
 |}
 | -  IF_DEBUG(linker, debugBelch(Unloading object file %s\n,
 | +  IF_DEBUG(linker, debugBelch(Unloading object file  FMT_PATH
 | \n,
 |oc-fileName));
 |freeObjectCode(oc);
 |} else {
 | -  IF_DEBUG(linker, debugBelch(Object file still in use: %s\n,
 | +  IF_DEBUG(linker, debugBelch(Object file still in use: 
 | FMT_PATH \n,
 |oc-fileName));
 |}
 |}
 | diff --git a/rts/Linker.c b/rts/Linker.c
 | index 6490242..4f0a1c4 100644
 | --- a/rts/Linker.c
 | +++ b/rts/Linker.c
 | @@ -2790,7 +2790,7 @@ unloadObj( pathchar *path )
 | 
 |  initLinker();
 | 
 | -IF_DEBUG(linker, debugBelch(unloadObj: %s\n, path));
 | +IF_DEBUG(linker, debugBelch(unloadObj:  FMT_PATH \n, path));
 | 
 |  prev = NULL;
 |  for (oc = objects; oc; prev = oc, oc = next) {
 | 
 | Excerpts from Jost Berthold's message of Tue Sep 03 12:56:03 -0700 2013:
 |   From: Simon Peyton-Jones simo...@microsoft.com
 |   To: Edward Z. Yang ezy...@mit.edu, Simon Marlow
 |   marlo...@gmail.com
 |   Cc: ghc-devs@haskell.org ghc-devs@haskell.org
 |   Subject: RE: More windows woe
 |   Message-ID:
 |  
 | 59543203684b2244980d7e4057d5fbc1485bb...@db3ex14mbxc308.europe.corp.mic
 | rosoft.com
 |  
 |   Content-Type: text/plain; charset=utf-8
 |  
 |   Simon Marlow: please help!
 |   At the moment windows builds are hosed, which is a Bad Situation.
 |  
 |   Actually it turns out that what want is
 |  
 |  debugBelch(Checking whether to unload %S\n, oc-fileName));
 |  
 |   That is, use %S rather than %s as format specifier for wide
 | chars.
 |  
 |   Sadly, this works on Windows, but not on Linux:
 |   rts/CheckUnload.c:260:13:
 | error: format ?%S? expects argument of type ?wchar_t *?, but
 | argument 2 has type ?pathchar *? [-Werror=format]
 |  
 |  
 |   So what I need guidance on, please!, is what the approved way to
 | deal with this is.  I suppose that I could identify each use of %s on a
 | filepath and say
 |  
 |   #ifdef mingw32_HOST_OS
 |  debugBelch(Checking whether to unload %S\n, oc-fileName));
 |   #else
 |  debugBelch(Checking whether to unload %s\n, oc-fileName));
 |   #endif
 |  
 |   But that seems deeply unsatisfactory doesn't it?
 |  
 |   If not that, then what?
 |  
 |  
 |   Simon
 | 
 |  Similar code is in place to distinguish between 32-bit and 64-bit
 | StgWords:
 | 
 |grep -r -e FMT_Word includes/
 |  includes/stg/Types.h:#define FMT_Word32u
 |  includes/stg/Types.h:#define FMT_Word32lu
 |  includes/stg/Types.h:#define FMT_Word64lu
 |  includes/stg/Types.h:#define FMT_Word64llu
 |  includes/stg/Types.h:#define FMT_Word FMT_Word64
 |  includes/stg/Types.h:#define FMT_Word FMT_Word32
 | 
 |  and format strings like blabla  FMT_Word  ..blabla are used inside
 |  rts/. One could do the same for FMT_Path and introduce

RE: RE: More windows woe

2013-09-04 Thread Kyle Van Berendonck

A quick search reveals that this is valid ANSI C.

Regards,

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

Re: RE: More windows woe

2013-09-04 Thread naur

Hello cvs-devs,

On a relatively recent Linux, man sprintf says S [conversion specifier] (Not 
in C99, but in SUSv2.) Synonym for ls. Don't use., so perhaps %ls is better 
than %S.

Best regards
Thorkil

- Original meddelelse -
 Fra: Edward Z. Yang ezy...@mit.edu
 Til: Jost Berthold berth...@mathematik.uni-marburg.de
 Cc: ghc-devs ghc-devs@haskell.org
 Dato: Ons, 04. sep 2013 11:15
 Emne: Re: RE: More windows woe
 
 I think this is reasonable, with the added caveat that
 the macros should be placed in includes/rts/Linker.h, because that
 is
 where pathchar is defined.  So how about something like:
 
 diff --git a/includes/rts/Linker.h b/includes/rts/Linker.h
 index e900e85..871b8cd 100644
 --- a/includes/rts/Linker.h
 +++ b/includes/rts/Linker.h
 @@ -16,8 +16,10 @@
 
  #if defined(mingw32_HOST_OS)
  typedef wchar_t pathchar;
 +#define FMT_PATH %S
  #else
  typedef charpathchar;
 +#define FMT_PATH %s
  #endif
 
  /* initialize the object linker */
 diff --git a/rts/CheckUnload.c b/rts/CheckUnload.c
 index a758b06..8dc8fdc 100644
 --- a/rts/CheckUnload.c
 +++ b/rts/CheckUnload.c
 @@ -254,7 +254,7 @@ void checkUnload (StgClosure *static_objects)
 
// Mark every unloadable object as unreferenced initially
for (oc = unloaded_objects; oc; oc = oc-next) {
 -  IF_DEBUG(linker, debugBelch(Checking whether to unload
 %s\n,
 +  IF_DEBUG(linker, debugBelch(Checking whether to unload 
 FMT_PATH \n,
oc-fileName));
oc-referenced = rtsFalse;
}
 @@ -290,11 +290,11 @@ void checkUnload (StgClosure *static_objects)
} else {
prev-next = oc-next;
}
 -  IF_DEBUG(linker, debugBelch(Unloading object file
 %s\n,
 +  IF_DEBUG(linker, debugBelch(Unloading object file 
 FMT_PATH \n,
oc-fileName));
freeObjectCode(oc);
} else {
 -  IF_DEBUG(linker, debugBelch(Object file still in use:
 %s\n,
 +  IF_DEBUG(linker, debugBelch(Object file still in use: 
 FMT_PATH \n,
oc-fileName));
}
}
 diff --git a/rts/Linker.c b/rts/Linker.c
 index 6490242..4f0a1c4 100644
 --- a/rts/Linker.c
 +++ b/rts/Linker.c
 @@ -2790,7 +2790,7 @@ unloadObj( pathchar *path )
 
  initLinker();
 
 -IF_DEBUG(linker, debugBelch(unloadObj: %s\n, path));
 +IF_DEBUG(linker, debugBelch(unloadObj:  FMT_PATH \n,
 path));
 
  prev = NULL;
  for (oc = objects; oc; prev = oc, oc = next) {
 
 Excerpts from Jost Berthold's message of Tue Sep 03 12:56:03 -0700
 2013:
   From: Simon Peyton-Jones simo...@microsoft.com
   To: Edward Z. Yang ezy...@mit.edu, Simon Marlow
   marlo...@gmail.com
   Cc: ghc-devs@haskell.org ghc-devs@haskell.org
   Subject: RE: More windows woe
   Message-ID:
  
 59543203684b2244980d7e4057d5fbc1485bb...@db3ex14mbxc308.europe.corp
 .microsoft.com
   
   Content-Type: text/plain; charset=utf-8
  
   Simon Marlow: please help!
   At the moment windows builds are hosed, which is a Bad
 Situation.
  
   Actually it turns out that what want is
  
  debugBelch(Checking whether to unload %S\n,
 oc-fileName));
  
   That is, use %S rather than %s as format specifier for wide
 chars.
  
   Sadly, this works on Windows, but not on Linux:
   rts/CheckUnload.c:260:13:
 error: format ?%S? expects argument of type ?wchar_t *?,
 but argument 2 has type ?pathchar *? [-Werror=format]
  
  
   So what I need guidance on, please!, is what the approved way to
 deal with this is.  I suppose that I could identify each use of %s
 on a filepath and say
  
   #ifdef mingw32_HOST_OS
  debugBelch(Checking whether to unload %S\n,
 oc-fileName));
   #else
  debugBelch(Checking whether to unload %s\n,
 oc-fileName));
   #endif
  
   But that seems deeply unsatisfactory doesn't it?
  
   If not that, then what?
  
  
   Simon
  
  Similar code is in place to distinguish between 32-bit and 64-bit
 StgWords:
  
grep -r -e FMT_Word includes/
  includes/stg/Types.h:#define FMT_Word32u
  includes/stg/Types.h:#define FMT_Word32lu
  includes/stg/Types.h:#define FMT_Word64lu
  includes/stg/Types.h:#define FMT_Word64llu
  includes/stg/Types.h:#define FMT_Word FMT_Word64
  includes/stg/Types.h:#define FMT_Word FMT_Word32
  
  and format strings like blabla  FMT_Word  ..blabla are used
 inside 
  rts/. One could do the same for FMT_Path and introduce it where
 required.
  
  Maybe this would be acceptable?
  
  / Jost
  
 
 ___
 ghc-devs mailing list
 ghc-devs@haskell.org
 http://www.haskell.org/mailman/listinfo/ghc-devs


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

Re: More windows woe

2013-09-04 Thread Edward Z. Yang

 that I could identify each use of %s on a filepath and 
  say
 
  #ifdef mingw32_HOST_OS
 debugBelch(Checking whether to unload %S\n, oc-fileName));
  #else
 debugBelch(Checking whether to unload %s\n, oc-fileName));
  #endif
 
  But that seems deeply unsatisfactory doesn't it?
 
  If not that, then what?
 
 
  Simon
 
 
 
  | -Original Message-
  | From: Edward Z. Yang [mailto:ezy...@mit.edu]
  | Sent: 28 August 2013 20:59
  | To: Simon Peyton-Jones
  | Cc: ghc-devs@haskell.org
  | Subject: Re: More windows woe
  |
  | My guess is the printf's need to be replaced with swprintf's.
  |
  | Edward
  |
  | Excerpts from Simon Peyton-Jones's message of Wed Aug 28 01:25:26 -0700
  | 2013:
  |  OK, so now my windows build is getting further, but it now falls over
  | here.  This one looks more straightforward!  Can anyone help?
  | 
  |  Simon
  | 
  |  inplace/bin/ghc-stage1.exe -optc-Werror -optc-Wall -optc-Wall -optc-
  | Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-
  | Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-
  | Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-
  | Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-
  | Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-
  | ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-
  | DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-O2 -
  | optc-fomit-frame-pointer -optc-fno-omit-frame-pointer -optc-g -optc-O0 -
  | optc-DRtsWay=\rts_debug\ -static -optc-DDEBUG -ticky -DTICKY_TICKY  -
  | H32m -O -Werror -Wall -H64m -O0 -Iincludes -Iincludes/dist -
  | Iincludes/dist-derivedconstants/header -Iincludes/dist-
  | ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name
  | rts -dcmm-lint  -i -irts -irts/dist/build -irts/dist/build/autogen -
  | Irts/dist/build -Irts/dist/build/autogen   -O2 -O0-c
  | rts/CheckUnload.c -o rts/dist/build/CheckUnload.debug_o
  |  cc1.exe: warnings being treated as errors
  |  rts\CheckUnload.c: In function 'checkUnload':
  | 
  |  rts\CheckUnload.c:257:7:
  |   error: format '%s' expects type 'char *', but argument 2 has type
  | 'pathchar *'
  | 
  |  rts\CheckUnload.c:293:11:
  |   error: format '%s' expects type 'char *', but argument 2 has type
  | 'pathchar *'
  | 
  |  rts\CheckUnload.c:297:11:
  |   error: format '%s' expects type 'char *', but argument 2 has type
  | 'pathchar *'
  |  bash-3.1$
 

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

Re: More windows woe

2013-09-04 Thread Edward Z. Yang

/CheckUnload.c:260:13:
 error: format ‘%S’ expects argument of type ‘wchar_t *’, but 
   argument 2 has type ‘pathchar *’ [-Werror=format]
  
  
   So what I need guidance on, please!, is what the approved way to deal 
   with this is.  I suppose that I could identify each use of %s on a 
   filepath and say
  
   #ifdef mingw32_HOST_OS
  debugBelch(Checking whether to unload %S\n, oc-fileName));
   #else
  debugBelch(Checking whether to unload %s\n, oc-fileName));
   #endif
  
   But that seems deeply unsatisfactory doesn't it?
  
   If not that, then what?
  
  
   Simon
  
  
  
   | -Original Message-
   | From: Edward Z. Yang [mailto:ezy...@mit.edu]
   | Sent: 28 August 2013 20:59
   | To: Simon Peyton-Jones
   | Cc: ghc-devs@haskell.org
   | Subject: Re: More windows woe
   |
   | My guess is the printf's need to be replaced with swprintf's.
   |
   | Edward
   |
   | Excerpts from Simon Peyton-Jones's message of Wed Aug 28 01:25:26 -0700
   | 2013:
   |  OK, so now my windows build is getting further, but it now falls over
   | here.  This one looks more straightforward!  Can anyone help?
   | 
   |  Simon
   | 
   |  inplace/bin/ghc-stage1.exe -optc-Werror -optc-Wall -optc-Wall -optc-
   | Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-
   | Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-
   | Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-
   | Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-
   | Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-
   | ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-
   | DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-O2 -
   | optc-fomit-frame-pointer -optc-fno-omit-frame-pointer -optc-g -optc-O0 -
   | optc-DRtsWay=\rts_debug\ -static -optc-DDEBUG -ticky -DTICKY_TICKY  -
   | H32m -O -Werror -Wall -H64m -O0 -Iincludes -Iincludes/dist -
   | Iincludes/dist-derivedconstants/header -Iincludes/dist-
   | ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name
   | rts -dcmm-lint  -i -irts -irts/dist/build -irts/dist/build/autogen -
   | Irts/dist/build -Irts/dist/build/autogen   -O2 -O0-c
   | rts/CheckUnload.c -o rts/dist/build/CheckUnload.debug_o
   |  cc1.exe: warnings being treated as errors
   |  rts\CheckUnload.c: In function 'checkUnload':
   | 
   |  rts\CheckUnload.c:257:7:
   |   error: format '%s' expects type 'char *', but argument 2 has type
   | 'pathchar *'
   | 
   |  rts\CheckUnload.c:293:11:
   |   error: format '%s' expects type 'char *', but argument 2 has type
   | 'pathchar *'
   | 
   |  rts\CheckUnload.c:297:11:
   |   error: format '%s' expects type 'char *', but argument 2 has type
   | 'pathchar *'
   |  bash-3.1$
  
 

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

Re: RE: More windows woe

2013-09-04 Thread Edward Z. Yang

I've gotten GHC to build on Windows, but the test suite is finicky. Here
is an error I am getting:

= T5267(normal) 50 of 3724 [0, 0, 0]   
  
cd ./arrows/should_compile  
'c:/Users/ezyang/Dev/ghc-validate/bindisttest/install   dir/bin/ghc.exe'
 -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db 
-rtsopts -fno-ghci-histor
y -c T5267.hsT5267.comp.stderr 21
  
Compile failed (status 256) errors were:
  

  
T5267.hs:11:15: 
  
tee: standard output: Permission denied  

It consistently fails on this test, and when I look at the process
list I see:

I103215481548   4064  con  500 14:54:08 /usr/bin/tee

I was seeing something similar when I used parallel make, apparently
there is a known deadlock when running make -j2 (or higher). But I
don't know why tee would be deadlocking.

Edward

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

Re: RE: More windows woe

2013-09-04 Thread Edward Z. Yang

I manually removed the tee from the validate script, and sallied on.
Here's the next error.

= cabal01(normal) 81 of 3724 [0, 0, 0]
cd ./cabal/cabal01  $MAKE -s --no-print-directory cabal01 
VANILLA=--enable-library-vanilla PR
OF=--disable-library-profiling DYN=--enable-shared CLEANUP=1/dev/null 
cabal01.run.stdout
2cabal01.run.stderr
Wrong exit code (expected 0 , actual 2 )
Stdout:

Stderr:
Creating library file: dist\build\libHStest-1.0-ghc7.7.20130904.dll.a
setup.exe: Error: Could not find module: A with any suffix: [dyn_hi] in the
search path: [dist\\build]
make[3]: *** [cabal01] Error 1

*** unexpected failure for cabal01(normal)

Cheers,
Edward

Excerpts from Edward Z. Yang's message of Wed Sep 04 14:56:30 -0700 2013:
 I've gotten GHC to build on Windows, but the test suite is finicky. Here
 is an error I am getting:
 
 = T5267(normal) 50 of 3724 [0, 0, 0] 
 
 cd ./arrows/should_compile  
 'c:/Users/ezyang/Dev/ghc-validate/bindisttest/install   dir/bin/ghc.exe'
  -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db 
 -rtsopts -fno-ghci-histor
 y -c T5267.hsT5267.comp.stderr 21  
 
 Compile failed (status 256) errors were:  
 
   
 
 T5267.hs:11:15:   
 
 tee: standard output: Permission denied  
 
 It consistently fails on this test, and when I look at the process
 list I see:
 
 I103215481548   4064  con  500 14:54:08 /usr/bin/tee
 
 I was seeing something similar when I used parallel make, apparently
 there is a known deadlock when running make -j2 (or higher). But I
 don't know why tee would be deadlocking.
 
 Edward

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

Re: RE: More windows woe

2013-09-03 Thread Jost Berthold

From: Simon Peyton-Jones simo...@microsoft.com
To: Edward Z. Yang ezy...@mit.edu, Simon Marlow
marlo...@gmail.com
Cc: ghc-devs@haskell.org ghc-devs@haskell.org
Subject: RE: More windows woe
Message-ID:

59543203684b2244980d7e4057d5fbc1485bb...@db3ex14mbxc308.europe.corp.microsoft.com

Content-Type: text/plain; charset=utf-8

Simon Marlow: please help!
At the moment windows builds are hosed, which is a Bad Situation.

Actually it turns out that what want is

   debugBelch(Checking whether to unload %S\n, oc-fileName));

That is, use %S rather than %s as format specifier for wide chars.

Sadly, this works on Windows, but not on Linux:
rts/CheckUnload.c:260:13:
  error: format ?%S? expects argument of type ?wchar_t *?, but argument 2 
has type ?pathchar *? [-Werror=format]

So what I need guidance on, please!, is what the approved way to deal with this 
is.  I suppose that I could identify each use of %s on a filepath and say

#ifdef mingw32_HOST_OS
   debugBelch(Checking whether to unload %S\n, oc-fileName));
#else
   debugBelch(Checking whether to unload %s\n, oc-fileName));
#endif

But that seems deeply unsatisfactory doesn't it?

If not that, then what?

Simon

Similar code is in place to distinguish between 32-bit and 64-bit StgWords:

 grep -r -e FMT_Word includes/
includes/stg/Types.h:#define FMT_Word32u
includes/stg/Types.h:#define FMT_Word32lu
includes/stg/Types.h:#define FMT_Word64lu
includes/stg/Types.h:#define FMT_Word64llu
includes/stg/Types.h:#define FMT_Word FMT_Word64
includes/stg/Types.h:#define FMT_Word FMT_Word32

and format strings like blabla  FMT_Word  ..blabla are used inside 
rts/. One could do the same for FMT_Path and introduce it where required.

Maybe this would be acceptable?

/ Jost

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

More windows woe

2013-08-28 Thread Simon Peyton-Jones

OK, so now my windows build is getting further, but it now falls over here.  
This one looks more straightforward!  Can anyone help?

Simon

inplace/bin/ghc-stage1.exe -optc-Werror -optc-Wall -optc-Wall -optc-Wextra 
-optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations 
-optc-Winline -optc-Waggregate-return -optc-Wpointer-arith 
-optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls 
-optc-Iincludes -optc-Iincludes/dist 
-optc-Iincludes/dist-derivedconstants/header 
-optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build 
-optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-O2 
-optc-fomit-frame-pointer -optc-fno-omit-frame-pointer -optc-g -optc-O0 
-optc-DRtsWay=\rts_debug\ -static -optc-DDEBUG -ticky -DTICKY_TICKY  -H32m -O 
-Werror -Wall -H64m -O0 -Iincludes -Iincludes/dist 
-Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header 
-Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint  -i 
-irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build 
-Irts/dist/build/autogen   -O2 -O0-c rts/CheckUnload.c -o 
rts/dist/build/CheckUnload.debug_o
cc1.exe: warnings being treated as errors
rts\CheckUnload.c: In function 'checkUnload':

rts\CheckUnload.c:257:7:
 error: format '%s' expects type 'char *', but argument 2 has type 
'pathchar *'

rts\CheckUnload.c:293:11:
 error: format '%s' expects type 'char *', but argument 2 has type 
'pathchar *'

rts\CheckUnload.c:297:11:
 error: format '%s' expects type 'char *', but argument 2 has type 
'pathchar *'
bash-3.1$
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: More windows woe

2013-08-28 Thread Simon Peyton-Jones

My query below may have got lost in the server failure. Does anyone have any 
ideas?  Thanks!

SImon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Simon 
Peyton-Jones
Sent: 28 August 2013 09:25
To: ghc-devs@haskell.org
Subject: More windows woe

OK, so now my windows build is getting further, but it now falls over here.  
This one looks more straightforward!  Can anyone help?

Simon

inplace/bin/ghc-stage1.exe -optc-Werror -optc-Wall -optc-Wall -optc-Wextra 
-optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations 
-optc-Winline -optc-Waggregate-return -optc-Wpointer-arith 
-optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls 
-optc-Iincludes -optc-Iincludes/dist 
-optc-Iincludes/dist-derivedconstants/header 
-optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build 
-optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-O2 
-optc-fomit-frame-pointer -optc-fno-omit-frame-pointer -optc-g -optc-O0 
-optc-DRtsWay=\rts_debug\ -static -optc-DDEBUG -ticky -DTICKY_TICKY  -H32m -O 
-Werror -Wall -H64m -O0 -Iincludes -Iincludes/dist 
-Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header 
-Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint  -i 
-irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build 
-Irts/dist/build/autogen   -O2 -O0-c rts/CheckUnload.c -o 
rts/dist/build/CheckUnload.debug_o
cc1.exe: warnings being treated as errors
rts\CheckUnload.c: In function 'checkUnload':

rts\CheckUnload.c:257:7:
 error: format '%s' expects type 'char *', but argument 2 has type 
'pathchar *'

rts\CheckUnload.c:293:11:
 error: format '%s' expects type 'char *', but argument 2 has type 
'pathchar *'

rts\CheckUnload.c:297:11:
 error: format '%s' expects type 'char *', but argument 2 has type 
'pathchar *'
bash-3.1$
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: More windows woe

2013-08-28 Thread Edward Z. Yang

My guess is the printf's need to be replaced with swprintf's.

Edward

Excerpts from Simon Peyton-Jones's message of Wed Aug 28 01:25:26 -0700 2013:
 OK, so now my windows build is getting further, but it now falls over here.  
 This one looks more straightforward!  Can anyone help?
 
 Simon
 
 inplace/bin/ghc-stage1.exe -optc-Werror -optc-Wall -optc-Wall -optc-Wextra 
 -optc-Wstrict-prototypes -optc-Wmissing-prototypes 
 -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return 
 -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs 
 -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist 
 -optc-Iincludes/dist-derivedconstants/header 
 -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build 
 -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-O2 
 -optc-fomit-frame-pointer -optc-fno-omit-frame-pointer -optc-g -optc-O0 
 -optc-DRtsWay=\rts_debug\ -static -optc-DDEBUG -ticky -DTICKY_TICKY  -H32m 
 -O -Werror -Wall -H64m -O0 -Iincludes -Iincludes/dist 
 -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header 
 -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint  -i 
 -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build 
 -Irts/dist/build/autogen   -O2 -O0-c rts/CheckUnloa
 d.c -o rts/dist/build/CheckUnload.debug_o
 cc1.exe: warnings being treated as errors
 rts\CheckUnload.c: In function 'checkUnload':
 
 rts\CheckUnload.c:257:7:
  error: format '%s' expects type 'char *', but argument 2 has type 
 'pathchar *'
 
 rts\CheckUnload.c:293:11:
  error: format '%s' expects type 'char *', but argument 2 has type 
 'pathchar *'
 
 rts\CheckUnload.c:297:11:
  error: format '%s' expects type 'char *', but argument 2 has type 
 'pathchar *'
 bash-3.1$

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

RE: More windows

Re: More windows

RE: More windows

RE: More windows

RE: More windows

Re: More windows

RE: More windows

Re: More windows

More windows

RE: More windows woe

RE: More windows woe

RE: More windows woe

Re: More windows woe

Re: More windows woe

Re: More windows woe

More windows woe

RE: More windows woe

Re: RE: More windows woe

RE: RE: More windows woe

RE: RE: More windows woe

RE: RE: More windows woe

Re: RE: More windows woe

Re: More windows woe

Re: More windows woe

Re: RE: More windows woe

Re: RE: More windows woe

Re: RE: More windows woe

More windows woe

RE: More windows woe

Re: More windows woe

30 matches

Site Navigation

Mail list logo

Footer information