GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:48:16Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/7760iOS patch no 15: remove HSC2HS_EXTRA from hsc2hs's stage0 wrapper2019-07-07T18:48:16ZStephenBlackheathiOS patch no 15: remove HSC2HS_EXTRA from hsc2hs's stage0 wrapperhsc2hs gets built in stage0 and stage1. The stage0 binary is used during the build, and the stage1 binary is the one that get released.
The hsc2hs that gets built in stage0 is used during the build in both in stage0 and in stage1. Curre...hsc2hs gets built in stage0 and stage1. The stage0 binary is used during the build, and the stage1 binary is the one that get released.
The hsc2hs that gets built in stage0 is used during the build in both in stage0 and in stage1. Currently some options specific to the platform are encoded into the hsc2hs wrapper script (inplace/bin/hsc2hs) in a variable called HSC2HS_EXTRA. The problem with this is that in stage0 and stage1 we need different options.
The solution is very simple: Just don't put these options into the stage0 wrapper. The build system passes the right options for whatever stage it's up to anyway when it invokes it.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"iOS patch no 15: remove HSC2HS_EXTRA from hsc2hs's stage0 wrapper","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"hsc2hs gets built in stage0 and stage1. The stage0 binary is used during the build, and the stage1 binary is the one that get released.\r\n\r\nThe hsc2hs that gets built in stage0 is used during the build in both in stage0 and in stage1. Currently some options specific to the platform are encoded into the hsc2hs wrapper script (inplace/bin/hsc2hs) in a variable called HSC2HS_EXTRA. The problem with this is that in stage0 and stage1 we need different options.\r\n\r\nThe solution is very simple: Just don't put these options into the stage0 wrapper. The build system passes the right options for whatever stage it's up to anyway when it invokes it.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7759iOS patch no 14: libraries/base changes2019-07-07T18:48:16ZStephenBlackheathiOS patch no 14: libraries/base changesIn this patch there are two changes to apply to libraries/base.
'GHC/Event/KQueue.hsc': The issue here is that the \#defines EVFILT_READ and EVFILT_WRITE have the values -1 and -2. The original code translates that to `filterRead = Filt...In this patch there are two changes to apply to libraries/base.
'GHC/Event/KQueue.hsc': The issue here is that the \#defines EVFILT_READ and EVFILT_WRITE have the values -1 and -2. The original code translates that to `filterRead = Filter -1` which is wrong Haskell and fails to compile. The modified code produces the correct code `filterRead = Filter (-1)`
'cbits/DarwinUtils.c': This code is needed for iOS as well as Darwin, and on iOS we need to explicitly include \<mach/mach_time.h\> which is the correct file for Mac OS/X too.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"iOS patch no 14: libraries/base changes","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In this patch there are two changes to apply to libraries/base.\r\n\r\n'GHC/Event/KQueue.hsc': The issue here is that the #defines EVFILT_READ and EVFILT_WRITE have the values -1 and -2. The original code translates that to {{{filterRead = Filter -1}}} which is wrong Haskell and fails to compile. The modified code produces the correct code {{{filterRead = Filter (-1)}}}\r\n\r\n'cbits/DarwinUtils.c': This code is needed for iOS as well as Darwin, and on iOS we need to explicitly include <mach/mach_time.h> which is the correct file for Mac OS/X too.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7753Profiling report broken with foreign exported functions2019-07-07T18:48:17Ztakano-akioProfiling report broken with foreign exported functionsSave the following Haskell source as wrapper.hs:
```
import Foreign.Ptr
import Control.Monad
main = do
fptr <- wrap wrapped
replicateM 100 $ (return$!) =<< dyn fptr 4
wrapped :: Double -> IO Double
wrapped x = return $ f 10000 x
...Save the following Haskell source as wrapper.hs:
```
import Foreign.Ptr
import Control.Monad
main = do
fptr <- wrap wrapped
replicateM 100 $ (return$!) =<< dyn fptr 4
wrapped :: Double -> IO Double
wrapped x = return $ f 10000 x
f :: Int -> Double -> Double
f 0 u = u
f n u = (u / fromIntegral n) * f (n-1) u
foreign import ccall "wrapper" wrap :: (Double -> IO Double) -> IO (FunPtr (Double -> IO Double))
foreign import ccall "dynamic" dyn :: FunPtr (Double -> IO Double) -> Double -> IO Double
```
Then compile and run it with:
```
$ ghc -O2 wrapper.hs -fprof-auto -prof
$ ./wrapper +RTS -p
```
It generates wrapper.prof (attached). The file contains the following lines:
```
CAF GHC.IO.Encoding.Iconv 58 0 0.0 0.2 0.0 0.2
wrapped Main 80 100 0.0 1.1 0.0 0.0
f Main 81 1000100 100.0 0.0 0.0 0.0
```
I see two problems here, (1) the inherited column is 0 for 'wrapped' and 'f' but this is incorrect, and (2) 'wrapped' and 'f' belongs to the wrong cost center, 'GHC.IO.Encoding.Iconv'.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Profiling report broken with foreign exported functions","status":"New","operating_system":"","component":"Profiling","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Save the following Haskell source as wrapper.hs:\r\n\r\n{{{\r\nimport Foreign.Ptr\r\nimport Control.Monad\r\n\r\nmain = do\r\n fptr <- wrap wrapped\r\n replicateM 100 $ (return$!) =<< dyn fptr 4 \r\n\r\nwrapped :: Double -> IO Double\r\nwrapped x = return $ f 10000 x\r\n\r\nf :: Int -> Double -> Double\r\nf 0 u = u\r\nf n u = (u / fromIntegral n) * f (n-1) u\r\n\r\nforeign import ccall \"wrapper\" wrap :: (Double -> IO Double) -> IO (FunPtr (Double -> IO Double))\r\nforeign import ccall \"dynamic\" dyn :: FunPtr (Double -> IO Double) -> Double -> IO Double\r\n}}}\r\n\r\nThen compile and run it with:\r\n\r\n{{{\r\n$ ghc -O2 wrapper.hs -fprof-auto -prof\r\n$ ./wrapper +RTS -p\r\n}}}\r\n\r\nIt generates wrapper.prof (attached). The file contains the following lines:\r\n\r\n{{{\r\n CAF GHC.IO.Encoding.Iconv 58 0 0.0 0.2 0.0 0.2\r\n wrapped Main 80 100 0.0 1.1 0.0 0.0\r\n f Main 81 1000100 100.0 0.0 0.0 0.0\r\n}}}\r\n\r\nI see two problems here, (1) the inherited column is 0 for 'wrapped' and 'f' but this is incorrect, and (2) 'wrapped' and 'f' belongs to the wrong cost center, 'GHC.IO.Encoding.Iconv'.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7752GHC as a library documentation out of sync2019-07-07T18:48:18ZtibbeGHC as a library documentation out of syncThe example program(s) at
http://www.haskell.org/ghc/docs/latest/html/users_guide/ghc-as-a-library.html
no longer compile. The docs probably just need a bit of tweaking.
<details><summary>Trac metadata</summary>
| Trac field ...The example program(s) at
http://www.haskell.org/ghc/docs/latest/html/users_guide/ghc-as-a-library.html
no longer compile. The docs probably just need a bit of tweaking.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 7.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC as a library documentation out of sync","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The example program(s) at\r\n\r\nhttp://www.haskell.org/ghc/docs/latest/html/users_guide/ghc-as-a-library.html\r\n\r\nno longer compile. The docs probably just need a bit of tweaking.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7751Incremental heap census2019-07-07T18:48:18ZEdward Z. YangIncremental heap censusAt the moment, a heap census forces a major garbage collection, because a heap census is always traverses the entire heap, and the only time when there is no slop is right after a major GC. What would be nice is if we only carried out he...At the moment, a heap census forces a major garbage collection, because a heap census is always traverses the entire heap, and the only time when there is no slop is right after a major GC. What would be nice is if we only carried out heap census on portions of the heap which were \*immediately\* GC'd; i.e. an incremental census.
The question, then, is how do we reconstruct full heap state from only a partial census? In particular, how do we know if an object that was previously present got collected or got promoted? If we always assume that it got collected (the naive implementation), a promoted object will disappear from the census, and only mysteriously reappear when we do a full census. The trick we want to employ is to save the starting pointer of all of the generations: while the entire generation is not slop free, the remainder of the first block and all of the later blocks are. I believe this is sufficient to reconstruct full heap state.
#4225 has related discussion.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Incremental heap census","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"At the moment, a heap census forces a major garbage collection, because a heap census is always traverses the entire heap, and the only time when there is no slop is right after a major GC. What would be nice is if we only carried out heap census on portions of the heap which were *immediately* GC'd; i.e. an incremental census.\r\n\r\nThe question, then, is how do we reconstruct full heap state from only a partial census? In particular, how do we know if an object that was previously present got collected or got promoted? If we always assume that it got collected (the naive implementation), a promoted object will disappear from the census, and only mysteriously reappear when we do a full census. The trick we want to employ is to save the starting pointer of all of the generations: while the entire generation is not slop free, the remainder of the first block and all of the later blocks are. I believe this is sufficient to reconstruct full heap state.\r\n\r\n#4225 has related discussion.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/7744Can't install conduit via cabal-install2019-07-07T18:48:19ZguestCan't install conduit via cabal-installWhen I did `cabal install hoogle` it failed on one of the dependencies, called conduit. Here is the output:
```
Downloading conduit-1.0.2...
Configuring conduit-1.0.2...
Building conduit-1.0.2...
Preprocessing library conduit-1.0.2...
[...When I did `cabal install hoogle` it failed on one of the dependencies, called conduit. Here is the output:
```
Downloading conduit-1.0.2...
Configuring conduit-1.0.2...
Building conduit-1.0.2...
Preprocessing library conduit-1.0.2...
[1 of 7] Compiling Data.Conduit.Internal ( Data/Conduit/Internal.hs, dist/build/Data/Conduit/Internal.o )
[2 of 7] Compiling Data.Conduit.Util ( Data/Conduit/Util.hs, dist/build/Data/Conduit/Util.o )
[3 of 7] Compiling Data.Conduit ( Data/Conduit.hs, dist/build/Data/Conduit.o )
[4 of 7] Compiling Data.Conduit.List ( Data/Conduit/List.hs, dist/build/Data/Conduit/List.o )
[5 of 7] Compiling Data.Conduit.Binary ( Data/Conduit/Binary.hs, dist/build/Data/Conduit/Binary.o )
ghc: internal error: evacuate: strange closure type 8
(GHC version 7.6.2 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Failed to install conduit-1.0.2
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Linux |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Can't install conduit via cabal-install","status":"New","operating_system":"Linux","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When I did {{{cabal install hoogle}}} it failed on one of the dependencies, called conduit. Here is the output:\r\n\r\n{{{\r\nDownloading conduit-1.0.2...\r\nConfiguring conduit-1.0.2...\r\nBuilding conduit-1.0.2...\r\nPreprocessing library conduit-1.0.2...\r\n[1 of 7] Compiling Data.Conduit.Internal ( Data/Conduit/Internal.hs, dist/build/Data/Conduit/Internal.o )\r\n[2 of 7] Compiling Data.Conduit.Util ( Data/Conduit/Util.hs, dist/build/Data/Conduit/Util.o )\r\n[3 of 7] Compiling Data.Conduit ( Data/Conduit.hs, dist/build/Data/Conduit.o )\r\n[4 of 7] Compiling Data.Conduit.List ( Data/Conduit/List.hs, dist/build/Data/Conduit/List.o )\r\n[5 of 7] Compiling Data.Conduit.Binary ( Data/Conduit/Binary.hs, dist/build/Data/Conduit/Binary.o )\r\nghc: internal error: evacuate: strange closure type 8\r\n (GHC version 7.6.2 for x86_64_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nFailed to install conduit-1.0.2\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7740Remove direct cabal imports in Linker and Finder modules2019-07-07T18:48:20ZrodlogicRemove direct cabal imports in Linker and Finder modulesThis is a low priority change, that mostly marks my first contribution :-)
See pull request and additional details here:
https://github.com/ghc/ghc/pull/6
<details><summary>Trac metadata</summary>
| Trac field | Value ...This is a low priority change, that mostly marks my first contribution :-)
See pull request and additional details here:
https://github.com/ghc/ghc/pull/6
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Remove direct cabal imports in Linker and Finder modules","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This is a low priority change, that mostly marks my first contribution :-)\r\n\r\nSee pull request and additional details here:\r\n\r\nhttps://github.com/ghc/ghc/pull/6","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7739Testsuite failures for HPC way tests on Windows2019-07-07T18:48:21ZbtuttTestsuite failures for HPC way tests on WindowsHere's what happens on GHC-HEAD:
```
=====> annrun01(hpc) 15 of 3566 [0, 0, 6]
cd ./annotations/should_run && $MAKE -s --no-print-directory config
Creating Config.hs ...
cd ./annotations/should_run && 'd:/Dev/ghc/ghc/inplace/bin/ghc-sta...Here's what happens on GHC-HEAD:
```
=====> annrun01(hpc) 15 of 3566 [0, 0, 6]
cd ./annotations/should_run && $MAKE -s --no-print-directory config
Creating Config.hs ...
cd ./annotations/should_run && 'd:/Dev/ghc/ghc/inplace/bin/ghc-stage2.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history --make -o annrun01 annrun01 -O -fhpc -hpcdir .hpc.annrun01 -package ghc >annrun01.comp.stderr 2>&1
cd ./annotations/should_run && ./annrun01 </dev/null >annrun01.run.stdout 2>annrun01.run.stderr
Wrong exit code (expected 0 , actual 1 )
Stdout:
Stderr:
in module 'Config'
Hpc failure: module mismatch with .tix/.mix file hash number
(perhaps remove annrun01.exe.tix file?)
*** unexpected failure for annrun01(hpc)
```
The cause appears to be due to not cleaning up .exe.tix files.
After deleting the files the tests pass again.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Testsuite failures for HPC way tests on Windows","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Here's what happens on GHC-HEAD:\r\n\r\n{{{\r\n=====> annrun01(hpc) 15 of 3566 [0, 0, 6]\r\ncd ./annotations/should_run && $MAKE -s --no-print-directory config\r\nCreating Config.hs ...\r\ncd ./annotations/should_run && 'd:/Dev/ghc/ghc/inplace/bin/ghc-stage2.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history --make -o annrun01 annrun01 -O -fhpc -hpcdir .hpc.annrun01 -package ghc >annrun01.comp.stderr 2>&1\r\ncd ./annotations/should_run && ./annrun01 </dev/null >annrun01.run.stdout 2>annrun01.run.stderr\r\nWrong exit code (expected 0 , actual 1 )\r\nStdout:\r\n\r\nStderr:\r\nin module 'Config'\r\nHpc failure: module mismatch with .tix/.mix file hash number\r\n(perhaps remove annrun01.exe.tix file?)\r\n\r\n*** unexpected failure for annrun01(hpc)\r\n}}}\r\n\r\nThe cause appears to be due to not cleaning up .exe.tix files.\r\nAfter deleting the files the tests pass again.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7738Testsuite failures for ghci tests normalising stderr output for .exe2019-07-07T18:48:21ZbtuttTestsuite failures for ghci tests normalising stderr output for .exeOn GHC-Head:
Tests getDirContents002 and process004 both specify normalise_exe in their options, but these both only generate expected error results on stderr.
Here's an example of what happens currently:
```
--- ./getDirContents002.s...On GHC-Head:
Tests getDirContents002 and process004 both specify normalise_exe in their options, but these both only generate expected error results on stderr.
Here's an example of what happens currently:
```
--- ./getDirContents002.stderr-mingw32 2013-02-09 21:09:27 -0500
+++ ./getDirContents002.run.stderr 2013-03-04 17:29:34 -0500
@@ -1 +1 @@
-getDirContents002.exe: nonexistent: getDirectoryContents: does not exist (The system cannot find the path specified.)
+getDirContents002: nonexistent: getDirectoryContents: does not exist (The system cannot find the path specified.)
*** unexpected failure for getDirContents002(ghci)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Testsuite failures for ghci tests normalising stderr output for .exe","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"On GHC-Head:\r\n\r\nTests getDirContents002 and process004 both specify normalise_exe in their options, but these both only generate expected error results on stderr. \r\n\r\nHere's an example of what happens currently:\r\n{{{\r\n--- ./getDirContents002.stderr-mingw32 2013-02-09 21:09:27 -0500\r\n+++ ./getDirContents002.run.stderr 2013-03-04 17:29:34 -0500\r\n@@ -1 +1 @@\r\n-getDirContents002.exe: nonexistent: getDirectoryContents: does not exist (The system cannot find the path specified.)\r\n+getDirContents002: nonexistent: getDirectoryContents: does not exist (The system cannot find the path specified.)\r\n*** unexpected failure for getDirContents002(ghci)\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/7734Missing backticks in error message2019-07-07T18:48:22ZKrzysztof GogolewskiMissing backticks in error messageThe code
```
x `f` y = x x
(&) x y = x x
```
gives errors with missing backticks and parentheses:
```
A.hs:1:13:
Occurs check: cannot construct the infinite type: t1 = t1 -> t0
In the first argument of `x', namely `x'
In t...The code
```
x `f` y = x x
(&) x y = x x
```
gives errors with missing backticks and parentheses:
```
A.hs:1:13:
Occurs check: cannot construct the infinite type: t1 = t1 -> t0
In the first argument of `x', namely `x'
In the expression: x x
In an equation for `f': x f y = x x
^^^^^
A.hs:2:13:
Occurs check: cannot construct the infinite type: t1 = t1 -> t0
In the first argument of `x', namely `x'
In the expression: x x
In an equation for `&': & x y = x x
^^^^^
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Missing backticks in error message","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The code\r\n\r\n{{{\r\nx `f` y = x x\r\n(&) x y = x x\r\n}}}\r\n\r\ngives errors with missing backticks and parentheses:\r\n\r\n{{{\r\nA.hs:1:13:\r\n Occurs check: cannot construct the infinite type: t1 = t1 -> t0\r\n In the first argument of `x', namely `x'\r\n In the expression: x x\r\n In an equation for `f': x f y = x x\r\n ^^^^^\r\n\r\nA.hs:2:13:\r\n Occurs check: cannot construct the infinite type: t1 = t1 -> t0\r\n In the first argument of `x', namely `x'\r\n In the expression: x x\r\n In an equation for `&': & x y = x x\r\n ^^^^^\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7726unexpected out of memory error on FreeBSD2019-07-07T18:48:23Znejstastnejsisteneunexpected out of memory error on FreeBSDI wrote a daemon that periodically scrapes information from a webpage that crashes after about 20 hours with the error: "out of memory (requested 1048576 bytes)". The program runs fine on my Ubuntu machine, but always crashes on FreeBSD ...I wrote a daemon that periodically scrapes information from a webpage that crashes after about 20 hours with the error: "out of memory (requested 1048576 bytes)". The program runs fine on my Ubuntu machine, but always crashes on FreeBSD even though there is plenty of memory to spare/memory stays constant/etc.
I boiled it down to the following code, which consistently crashes after about 4000-6000 iterations when compiled with -O2, and about 35000 without.
```
import Data.Conduit
import Data.Conduit.List
import qualified Data.ByteString as B
import Network.HTTP.Conduit
main :: IO ()
main = do
manager <- newManager def
loop manager 1
loop :: Manager -> Int -> IO ()
loop manager i = do
putStrLn $ show i
request <- parseUrl "http://localhost:8000/courselist.html"
html <- runResourceT $ do
response <- http request manager
fmap B.concat $ responseBody response $$+- consume
loop manager $ i + 1
```
For debugging, I served a copy of of a typical html sample from localhost using "python -m SimpleHTTPServer". The html file is attached.
Sample Output:\[\[BR\]\]
```
...
35361
35362
35363
35364
35365
main: out of memory (requested 1048576 bytes)
```
Other information:
```
$ uname -a
FreeBSD oriskova 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243826: Tue Dec 4 06:55:39 UTC 2012 root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386
```
```
$ gcc -v
Using built-in specs.
Target: i386-undermydesk-freebsd
Configured with: FreeBSD/i386 system compiler
Thread model: posix[[BR]]
gcc version 4.2.1 20070831 patched [FreeBSD]
```
I wasn't sure if I should submit this or not since it seemed fairly specific to http-conduit, but the wiki said to go ahead and submit runtime errors, so that's what I did. This is my first time ever submitting a bug report and I tried my best to follow all the instructions at [http://hackage.haskell.org/trac/ghc/wiki/ReportABug](http://hackage.haskell.org/trac/ghc/wiki/ReportABug), but please tell me if there is something I'm doing wrong.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"unexpected out of memory error on FreeBSD","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I wrote a daemon that periodically scrapes information from a webpage that crashes after about 20 hours with the error: \"out of memory (requested 1048576 bytes)\". The program runs fine on my Ubuntu machine, but always crashes on FreeBSD even though there is plenty of memory to spare/memory stays constant/etc.\r\n\r\nI boiled it down to the following code, which consistently crashes after about 4000-6000 iterations when compiled with -O2, and about 35000 without.\r\n{{{\r\nimport Data.Conduit\r\nimport Data.Conduit.List\r\nimport qualified Data.ByteString as B\r\nimport Network.HTTP.Conduit\r\n\r\nmain :: IO ()\r\nmain = do\r\n manager <- newManager def\r\n loop manager 1\r\n\r\nloop :: Manager -> Int -> IO ()\r\nloop manager i = do\r\n putStrLn $ show i\r\n request <- parseUrl \"http://localhost:8000/courselist.html\"\r\n html <- runResourceT $ do\r\n response <- http request manager\r\n fmap B.concat $ responseBody response $$+- consume\r\n loop manager $ i + 1\r\n}}}\r\n\r\nFor debugging, I served a copy of of a typical html sample from localhost using \"python -m SimpleHTTPServer\". The html file is attached.\r\n\r\nSample Output:[[BR]]\r\n{{{\r\n...\r\n35361\r\n35362\r\n35363\r\n35364\r\n35365\r\nmain: out of memory (requested 1048576 bytes)\r\n}}}\r\n\r\nOther information:\r\n{{{\r\n$ uname -a\r\nFreeBSD oriskova 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243826: Tue Dec 4 06:55:39 UTC 2012 root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386\r\n}}}\r\n\r\n{{{\r\n$ gcc -v\r\nUsing built-in specs.\r\nTarget: i386-undermydesk-freebsd\r\nConfigured with: FreeBSD/i386 system compiler\r\nThread model: posix[[BR]]\r\ngcc version 4.2.1 20070831 patched [FreeBSD]\r\n}}}\r\n\r\nI wasn't sure if I should submit this or not since it seemed fairly specific to http-conduit, but the wiki said to go ahead and submit runtime errors, so that's what I did. This is my first time ever submitting a bug report and I tried my best to follow all the instructions at [http://hackage.haskell.org/trac/ghc/wiki/ReportABug], but please tell me if there is something I'm doing wrong.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1pgjpgjhttps://gitlab.haskell.org/ghc/ghc/-/issues/7725Operators without colons2019-07-07T18:48:24ZKrzysztof GogolewskiOperators without colonsThis code is accepted:
```
data A x y = (&) x y
```
but it's wrong - as far as I know operators on the value level are constructors iff they start with a colon `(:&)`. (In fact `a = (&)` reports "Not in scope: (&)".)
<details><summary...This code is accepted:
```
data A x y = (&) x y
```
but it's wrong - as far as I know operators on the value level are constructors iff they start with a colon `(:&)`. (In fact `a = (&)` reports "Not in scope: (&)".)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Operators without colons","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This code is accepted:\r\n\r\n{{{\r\ndata A x y = (&) x y\r\n}}}\r\n\r\nbut it's wrong - as far as I know operators on the value level are constructors iff they start with a colon `(:&)`. (In fact {{{a = (&)}}} reports \"Not in scope: (&)\".)","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7724cross-compile to iOS2019-07-07T18:48:24ZStephenBlackheathcross-compile to iOSA bug for the whole task of cross-compiling to iOS, so we can block it by the individual tasks.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| -----------...A bug for the whole task of cross-compiling to iOS, so we can block it by the individual tasks.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------------------------------------ |
| Version | 7.7 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | #7700, #7705, #7707, #7709, #7718, #7720, #7721, #7722 |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[7700,7705,7707,7709,7718,7720,7721,7722],"summary":"cross-compile to iOS","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"A bug for the whole task of cross-compiling to iOS, so we can block it by the individual tasks.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7720iOS patch no 9: Linking2019-07-07T18:48:25ZStephenBlackheathiOS patch no 9: LinkingThese are all the changes necessary to make the iOS cross compiler link in the right way for iOS.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Versi...These are all the changes necessary to make the iOS cross compiler link in the right way for iOS.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"iOS patch no 9: Linking","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"These are all the changes necessary to make the iOS cross compiler link in the right way for iOS.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7719System.Timeout.timeout may leak <<timeout>> exceptions2019-07-07T18:48:25ZBertram FelgenhauerSystem.Timeout.timeout may leak <<timeout>> exceptionsThe current implementation of `timeout` can leak `Timeout` exceptions if an asynchronous exception is delivered at the wrong time. The most worrysome such case is another `Timeout` exception raised by surrounding call to `timeout`. The f...The current implementation of `timeout` can leak `Timeout` exceptions if an asynchronous exception is delivered at the wrong time. The most worrysome such case is another `Timeout` exception raised by surrounding call to `timeout`. The following program reproduces the issue reliably for me:
```
import System.Timeout
import Control.Monad
import Control.Concurrent
t d = timeout d $ timeout d $ timeout d $ timeout d $ timeout d $ timeout (10^9) $ threadDelay 100
main = forever $ mapM_ t [1..200]
-- > ghc -O2 -rtsopts -threaded --make TT.hs
-- > ./TT +RTS -N1
-- TT: <<timeout>>
```
Context: A recent thread on `ghc-users`, starting with http://www.haskell.org/pipermail/glasgow-haskell-users/2013-February/023811.html, got me thinking about corner cases of timeout handling again.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"System.Timeout.timeout may leak <<timeout>> exceptions","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The current implementation of {{{timeout}}} can leak {{{Timeout}}} exceptions if an asynchronous exception is delivered at the wrong time. The most worrysome such case is another {{{Timeout}}} exception raised by surrounding call to {{{timeout}}}. The following program reproduces the issue reliably for me:\r\n{{{\r\nimport System.Timeout\r\nimport Control.Monad\r\nimport Control.Concurrent\r\n\r\nt d = timeout d $ timeout d $ timeout d $ timeout d $ timeout d $ timeout (10^9) $ threadDelay 100\r\n\r\nmain = forever $ mapM_ t [1..200]\r\n\r\n-- > ghc -O2 -rtsopts -threaded --make TT.hs\r\n-- > ./TT +RTS -N1\r\n-- TT: <<timeout>>\r\n}}}\r\n\r\nContext: A recent thread on {{{ghc-users}}}, starting with http://www.haskell.org/pipermail/glasgow-haskell-users/2013-February/023811.html, got me thinking about corner cases of timeout handling again.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7718ios patch no 8: adjustor pools2020-10-07T06:16:26ZStephenBlackheathios patch no 8: adjustor pools"Adjustor" is the term used for a C function pointer that allows C code to call back to Haskell. Normally these are generated at runtime.
However, the iOS kernel doesn't allow self-modifying code. So, on iOS we use a pool of precompiled..."Adjustor" is the term used for a C function pointer that allows C code to call back to Haskell. Normally these are generated at runtime.
However, the iOS kernel doesn't allow self-modifying code. So, on iOS we use a pool of precompiled adjustors of a fixed size, and this patch is the implementation for that.
It consists of three parts:
1. A POOLSIZE pragma, that is used like this:
```
foreign import ccall safe "wrapper" {-# POOLSIZE 100 #-}
mkDelegate :: IO () -> IO (FunPtr (IO ()))
```
> This patch makes this pragma work on all platforms, but it'll have no effect on platforms other than iOS.
I am not sure what the procedure is for additions of pragmas. Do pragmas require {-\# LANGUAGE xx \#-} ? Anyway, please review whether the approach taken here is acceptable.
1. The Haskell code in the compiler to generate the stubs for the pooled adjustors.
1. The runtime system's implementation of pooled adjustors in C.7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7715threadDelay causes segfault on Mac if compiled by 32bit GHC2019-07-07T18:48:26Zkazu-yamamotothreadDelay causes segfault on Mac if compiled by 32bit GHCThe following code causes segfault
```
main :: IO ()
main = do
replicateM_ 100 $ forkIO $ do
threadDelay 1000000
putStrLn "Hello, world!"
threadDelay 5000000
```
if compiled with 32bit GHC head on Mac.
64bit G...The following code causes segfault
```
main :: IO ()
main = do
replicateM_ 100 $ forkIO $ do
threadDelay 1000000
putStrLn "Hello, world!"
threadDelay 5000000
```
if compiled with 32bit GHC head on Mac.
64bit GHC head does not cause this problem. 32bit GHC 7.4.2 does not, either. I don't see this bug both on FreeBSD and Linux.
"gdb" caught the following on each run:
```
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000005
[Switching to process 51076 thread 0x20b]
0x00000005 in ?? ()
```
```
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000019
[Switching to process 50933 thread 0x20b]
0x00000019 in ?? ()
```
```
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x40e40348
[Switching to process 51004 thread 0x20b]
0x00f28aa5 in base_GHCziEventziPSQ_atMostzuzdszdwatMosts_info ()
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | Unknown/Multiple |
</details>
<!-- {"blocked_by":[],"summary":"threadDelay causes segfault on Mac if compiled by 32bit GHC","status":"New","operating_system":"Unknown/Multiple","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown/Multiple","cc":[""],"type":"Bug","description":"The following code causes segfault\r\n{{{\r\nmain :: IO ()\r\nmain = do\r\n replicateM_ 100 $ forkIO $ do\r\n threadDelay 1000000 \r\n putStrLn \"Hello, world!\"\r\n threadDelay 5000000\r\n}}}\r\nif compiled with 32bit GHC head on Mac.\r\n\r\n64bit GHC head does not cause this problem. 32bit GHC 7.4.2 does not, either. I don't see this bug both on FreeBSD and Linux.\r\n\r\n\"gdb\" caught the following on each run:\r\n\r\n{{{\r\nProgram received signal EXC_BAD_ACCESS, Could not access memory.\r\nReason: KERN_PROTECTION_FAILURE at address: 0x00000005\r\n[Switching to process 51076 thread 0x20b]\r\n0x00000005 in ?? ()\r\n}}}\r\n\r\n{{{\r\nProgram received signal EXC_BAD_ACCESS, Could not access memory.\r\nReason: KERN_PROTECTION_FAILURE at address: 0x00000019\r\n[Switching to process 50933 thread 0x20b]\r\n0x00000019 in ?? ()\r\n}}}\r\n\r\n{{{\r\nProgram received signal EXC_BAD_ACCESS, Could not access memory.\r\nReason: KERN_INVALID_ADDRESS at address: 0x40e40348\r\n[Switching to process 51004 thread 0x20b]\r\n0x00f28aa5 in base_GHCziEventziPSQ_atMostzuzdszdwatMosts_info ()\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7713Panic! make_exp (App _ (Coercion _)) when compiled with -fext-core2019-07-07T18:48:27ZEduardSergeevPanic! make_exp (App _ (Coercion _)) when compiled with -fext-coreAn attempt to compile the attached file with 7.6.2 (and 7.4.2) with "-O2 -fext-core" leads to:
```
ghc: panic! (the 'impossible' happened)
(GHC version 7.6.2 for x86_64-unknown-linux):
make_exp (App _ (Coercion _))
```An attempt to compile the attached file with 7.6.2 (and 7.4.2) with "-O2 -fext-core" leads to:
```
ghc: panic! (the 'impossible' happened)
(GHC version 7.6.2 for x86_64-unknown-linux):
make_exp (App _ (Coercion _))
```7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7712"make install" fails on Windows2019-07-07T18:48:27Zdpratt71"make install" fails on WindowsRunning the 'make install' command under Windows 8/MinGW produces an error. The full output of 'make install':
```
$ make install
===--- building phase 0
make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds
make[1]: Nothing to ...Running the 'make install' command under Windows 8/MinGW produces an error. The full output of 'make install':
```
$ make install
===--- building phase 0
make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds
make[1]: Nothing to be done for `phase_0_builds'.
===--- building phase 1
make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds
make[1]: Nothing to be done for `phase_1_builds'.
===--- building final phase
make -r --no-print-directory -f ghc.mk phase=final install
/bin/install -c -m 755 -d "/usr/local/lib"
/bin/install -c -m 755 driver/split/dist/ghc-split "/usr/local/lib"
driver/ghci/ghc.mk:56: *** removeFiles: Got leading slash: /usr/local/bin/ghcii.sh. Stop.
make: *** [install] Error 2
```
It seems that the removeFiles function specifically disallows paths that start with a "/". Looking around at other places where removeFiles was being called with a rooted path, the path was also quoted. I added quotes to the path in the line mentioned in the error above (and one other place) and thereafter the 'make install' command proceeded without errors.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"\"make install\" fails on Windows","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Running the 'make install' command under Windows 8/MinGW produces an error. The full output of 'make install':\r\n\r\n{{{\r\n$ make install\r\n===--- building phase 0\r\nmake -r --no-print-directory -f ghc.mk phase=0 phase_0_builds\r\nmake[1]: Nothing to be done for `phase_0_builds'.\r\n===--- building phase 1\r\nmake -r --no-print-directory -f ghc.mk phase=1 phase_1_builds\r\nmake[1]: Nothing to be done for `phase_1_builds'.\r\n===--- building final phase\r\nmake -r --no-print-directory -f ghc.mk phase=final install\r\n/bin/install -c -m 755 -d \"/usr/local/lib\"\r\n/bin/install -c -m 755 driver/split/dist/ghc-split \"/usr/local/lib\"\r\ndriver/ghci/ghc.mk:56: *** removeFiles: Got leading slash: /usr/local/bin/ghcii.sh. Stop.\r\nmake: *** [install] Error 2\r\n}}}\r\n\r\nIt seems that the removeFiles function specifically disallows paths that start with a \"/\". Looking around at other places where removeFiles was being called with a rooted path, the path was also quoted. I added quotes to the path in the line mentioned in the error above (and one other place) and thereafter the 'make install' command proceeded without errors.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1thoughtpolicethoughtpolicehttps://gitlab.haskell.org/ghc/ghc/-/issues/7709ios patch no 7: Omit ghc-pwd from final stage when cross compiling2019-07-07T18:48:28ZStephenBlackheathios patch no 7: Omit ghc-pwd from final stage when cross compilingWithout this patch, we get this error when cross compiling:
```
"cp" -p utils/ghc-pwd/dist-install/build/tmp/ghc-pwd inplace/bin/ghc-pwd
cp: utils/ghc-pwd/dist-install/build/tmp/ghc-pwd: No such file or directory
make[1]: *** [inplace/b...Without this patch, we get this error when cross compiling:
```
"cp" -p utils/ghc-pwd/dist-install/build/tmp/ghc-pwd inplace/bin/ghc-pwd
cp: utils/ghc-pwd/dist-install/build/tmp/ghc-pwd: No such file or directory
make[1]: *** [inplace/bin/ghc-pwd] Error 1
make: *** [all] Error 2
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ios patch no 7: Omit ghc-pwd from final stage when cross compiling","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Without this patch, we get this error when cross compiling:\r\n\r\n{{{\r\n\"cp\" -p utils/ghc-pwd/dist-install/build/tmp/ghc-pwd inplace/bin/ghc-pwd\r\ncp: utils/ghc-pwd/dist-install/build/tmp/ghc-pwd: No such file or directory\r\nmake[1]: *** [inplace/bin/ghc-pwd] Error 1\r\nmake: *** [all] Error 2\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>