GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:02:09Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15985`pprint EqualityT` infinitely loops2019-07-07T18:02:09ZRyan Scott`pprint EqualityT` infinitely loopsI was very surprised to discover that this program loops infinitely:
```hs
module Main where
import Language.Haskell.TH
main :: IO ()
main = print $ pprint EqualityT
```
Let's not do that. Patch incoming.
<details><summary>Trac meta...I was very surprised to discover that this program loops infinitely:
```hs
module Main where
import Language.Haskell.TH
main :: IO ()
main = print $ pprint EqualityT
```
Let's not do that. Patch incoming.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"`pprint EqualityT` infinitely loops","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I was very surprised to discover that this program loops infinitely:\r\n\r\n{{{#!hs\r\nmodule Main where\r\n\r\nimport Language.Haskell.TH\r\n\r\nmain :: IO ()\r\nmain = print $ pprint EqualityT\r\n}}}\r\n\r\nLet's not do that. Patch incoming.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15982Hadrian's `--configure` flag is broken on Windows2019-09-20T23:34:40ZAndrey MokhovHadrian's `--configure` flag is broken on WindowsFor some reason I can no longer use Hadrian's `--configure` flag. When I use it, the configuration step fails with the following obscure error:
```
rm: cannot remove '.MTREE': No such file or directory
```
This is certainly caused by t...For some reason I can no longer use Hadrian's `--configure` flag. When I use it, the configuration step fails with the following obscure error:
```
rm: cannot remove '.MTREE': No such file or directory
```
This is certainly caused by this line in `configure.ac`:
https://github.com/ghc/ghc/blob/93e86d6103757b43017535c92bc6970e9e2315a5/configure.ac\#L358
It's unclear what should be done in this case.
Here is the command line I use to invoke Hadrian:
```
hadrian\build --configure -j --flavour=quickest --integer-simple
```
When I run the configure script manually from the MinGW shell, it works fine.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System (Hadrian) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Hadrian's `--configure` flag is broken on Windows","status":"New","operating_system":"Unknown/Multiple","component":"Build System (Hadrian)","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"For some reason I can no longer use Hadrian's `--configure` flag. When I use it, the configuration step fails with the following obscure error:\r\n\r\n{{{\r\nrm: cannot remove '.MTREE': No such file or directory\r\n}}}\r\n\r\nThis is certainly caused by this line in `configure.ac`:\r\n\r\nhttps://github.com/ghc/ghc/blob/93e86d6103757b43017535c92bc6970e9e2315a5/configure.ac#L358\r\n\r\nIt's unclear what should be done in this case.\r\n\r\n\r\nHere is the command line I use to invoke Hadrian:\r\n\r\n{{{\r\nhadrian\\build --configure -j --flavour=quickest --integer-simple\r\n}}}\r\n\r\nWhen I run the configure script manually from the MinGW shell, it works fine.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15971Hadrian fails Shake's linter on Windows2020-02-28T10:49:42ZBen GamariHadrian fails Shake's linter on WindowsWhile trying to bring up a Hadrian builder on Windows I found the [following](https://gitlab.staging.haskell.org/ghc/ghc/-/jobs/440/raw); excerpting:
```
shakeArgsWith 0.001s 0%
Funct...While trying to bring up a Hadrian builder on Windows I found the [following](https://gitlab.staging.haskell.org/ghc/ghc/-/jobs/440/raw); excerpting:
```
shakeArgsWith 0.001s 0%
Function shake 0.407s 0%
Database read 0.001s 0%
With database 0.000s 0%
Running rules 3065.940s 99% =========================
Pool finished (2932 threads, 4 max) 0.002s 0%
Lint checking 1.810s 0%
Total 3068.160s 100%
Lint checking error - 520 values have changed since being depended upon:
Key: _build/stage1/gmp/objs/zero_p.o
Old: (Just File {mod=0x6D312A39,size=0x2EA,digest=0xACFF03E6} recomputed,"")
New: File {mod=0x7475B8F5,size=0x2EA,digest=0xACFF03E6}
Key: _build/stage1/gmp/objs/zero.o
Old: (Just File {mod=0x6DA1AAD9,size=0x2F8,digest=0x586B32DC} recomputed,"")
New: File {mod=0x74B61957,size=0x2F8,digest=0x586B32DC}
Key: _build/stage1/gmp/objs/xor_n.o
Old: (Just File {mod=0x6D9D3378,size=0x1DF,digest=0xFBB5353} recomputed,"")
New: File {mod=0x74B2AAEC,size=0x1DF,digest=0xFBB5353}
```
It looks like all of the gmp objects were somehow touched during the build, but their contents are unchanged. Strangely, none of these filenames appear elsewhere in the log, so it's unclear when they could have been touched.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Hadrian fails Shake's linter on Windows","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"While trying to bring up a Hadrian builder on Windows I found the [[https://gitlab.staging.haskell.org/ghc/ghc/-/jobs/440/raw|following]]; excerpting:\r\n{{{\r\nshakeArgsWith 0.001s 0% \r\nFunction shake 0.407s 0% \r\nDatabase read 0.001s 0% \r\nWith database 0.000s 0% \r\nRunning rules 3065.940s 99% =========================\r\nPool finished (2932 threads, 4 max) 0.002s 0% \r\nLint checking 1.810s 0% \r\nTotal 3068.160s 100% \r\nLint checking error - 520 values have changed since being depended upon:\r\n Key: _build/stage1/gmp/objs/zero_p.o\r\n Old: (Just File {mod=0x6D312A39,size=0x2EA,digest=0xACFF03E6} recomputed,\"\")\r\n New: File {mod=0x7475B8F5,size=0x2EA,digest=0xACFF03E6}\r\n \r\n Key: _build/stage1/gmp/objs/zero.o\r\n Old: (Just File {mod=0x6DA1AAD9,size=0x2F8,digest=0x586B32DC} recomputed,\"\")\r\n New: File {mod=0x74B61957,size=0x2F8,digest=0x586B32DC}\r\n \r\n Key: _build/stage1/gmp/objs/xor_n.o\r\n Old: (Just File {mod=0x6D9D3378,size=0x1DF,digest=0xFBB5353} recomputed,\"\")\r\n New: File {mod=0x74B2AAEC,size=0x1DF,digest=0xFBB5353}\r\n}}}\r\n\r\nIt looks like all of the gmp objects were somehow touched during the build, but their contents are unchanged. Strangely, none of these filenames appear elsewhere in the log, so it's unclear when they could have been touched.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15968configure doesn't error out when --enable-dwarf-unwind is given but libdw can...2021-07-05T17:20:36ZNiklas Hambüchenmail@nh2.meconfigure doesn't error out when --enable-dwarf-unwind is given but libdw cannot be foundAgainst expectations, the GHC bindist supposedly having DWARF support provided at
> https://downloads.haskell.org/\~ghc/8.4.4/ghc-8.4.4-x86_64-deb9-linux-dwarf.tar.xz
doesn't actually have DWARF support.
According to bgamari, this is...Against expectations, the GHC bindist supposedly having DWARF support provided at
> https://downloads.haskell.org/\~ghc/8.4.4/ghc-8.4.4-x86_64-deb9-linux-dwarf.tar.xz
doesn't actually have DWARF support.
According to bgamari, this is because `./configure --enable-dwarf-unwind` doesn't actually complain when the required dependency `libdw` isn't found; instead, it continues silently.
Most programs I know will barf out when something isn't found but also \*explicitly\* requested via the command line; for the cases where this wasn't, the project maintainers did consider this a bug.
GHC's `./configure` suite should fail hard when `--enable-dwarf-unwind` is given but `libdw` cannot be found.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------- |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System (make) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | bgamari, nh2 |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"configure doesn't error out when --enable-dwarf-unwind is given but libdw cannot be found","status":"New","operating_system":"","component":"Build System (make)","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["bgamari","nh2"],"type":"Bug","description":"Against expectations, the GHC bindist supposedly having DWARF support provided at\r\n\r\n https://downloads.haskell.org/~ghc/8.4.4/ghc-8.4.4-x86_64-deb9-linux-dwarf.tar.xz\r\n\r\ndoesn't actually have DWARF support.\r\n\r\nAccording to bgamari, this is because `./configure --enable-dwarf-unwind` doesn't actually complain when the required dependency `libdw` isn't found; instead, it continues silently.\r\n\r\nMost programs I know will barf out when something isn't found but also *explicitly* requested via the command line; for the cases where this wasn't, the project maintainers did consider this a bug.\r\n\r\nGHC's `./configure` suite should fail hard when `--enable-dwarf-unwind` is given but `libdw` cannot be found.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15962Type family & typeclass interaction suppresses errors2019-07-07T18:02:16ZmadgenType family & typeclass interaction suppresses errorsThe following program despite having a hole and an undefined variable `iDontExist` \*quietly\* fails to compile on 8.4.3 and 8.4.4. It produces errors as expected on 8.6.1 and 8.6.2.
By quietly failing, I mean it fails on CLI but withou...The following program despite having a hole and an undefined variable `iDontExist` \*quietly\* fails to compile on 8.4.3 and 8.4.4. It produces errors as expected on 8.6.1 and 8.6.2.
By quietly failing, I mean it fails on CLI but without producing any error messages and in GHCI. It just says "Failed, no modules loaded."
```hs
{-# LANGUAGE GADTs #-}
{-# LANGUAGE TypeInType #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeOperators #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE FlexibleInstances #-}
module Bug where
import Data.Kind (Type)
type Exp a = a -> Type
type family Eval (e :: Exp a) :: a
data OpKind = Conjunction
data Dual (k :: OpKind) :: Exp OpKind
data Map :: (a -> Exp b) -> [ a ] -> Exp [ b ]
type instance Eval (Map f (a ': as)) = Eval (f a) ': Eval (Map f as)
data Big :: [ OpKind ] -> Type where
Big :: [ Big ks ] -> Big ('Conjunction ': ks)
dualBig :: Big ks -> Big (Eval (Map Dual ks))
dualBig = _
instance Semigroup (Big a) where
Big xs <> Big ys = Big (xs <> ys)
instance Monoid (Big ('Conjunction ': ks)) where
mempty = iDontExist
flatten :: Monoid (Big ks) => Big (k ': k ': ks) -> Big ks
flatten = undefined
```
Sorry, the example is a bit big but almost any change causes the errors to appear again including the `Monoid` constraint on `flatten`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Type family & typeclass interaction suppresses errors","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"⊥","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["error","family,","message","type","typeclass,"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following program despite having a hole and an undefined variable `iDontExist` *quietly* fails to compile on 8.4.3 and 8.4.4. It produces errors as expected on 8.6.1 and 8.6.2.\r\n\r\nBy quietly failing, I mean it fails on CLI but without producing any error messages and in GHCI. It just says \"Failed, no modules loaded.\"\r\n\r\n{{{#!hs\r\n{-# LANGUAGE GADTs #-}\r\n{-# LANGUAGE TypeInType #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\n{-# LANGUAGE TypeOperators #-}\r\n{-# LANGUAGE FlexibleContexts #-}\r\n{-# LANGUAGE FlexibleInstances #-}\r\n\r\nmodule Bug where\r\n\r\nimport Data.Kind (Type)\r\n\r\ntype Exp a = a -> Type\r\ntype family Eval (e :: Exp a) :: a\r\n\r\ndata OpKind = Conjunction\r\n\r\ndata Dual (k :: OpKind) :: Exp OpKind\r\n\r\ndata Map :: (a -> Exp b) -> [ a ] -> Exp [ b ]\r\n\r\ntype instance Eval (Map f (a ': as)) = Eval (f a) ': Eval (Map f as)\r\n\r\ndata Big :: [ OpKind ] -> Type where\r\n Big :: [ Big ks ] -> Big ('Conjunction ': ks)\r\n\r\ndualBig :: Big ks -> Big (Eval (Map Dual ks))\r\ndualBig = _\r\n\r\ninstance Semigroup (Big a) where\r\n Big xs <> Big ys = Big (xs <> ys)\r\n\r\ninstance Monoid (Big ('Conjunction ': ks)) where\r\n mempty = iDontExist\r\n\r\nflatten :: Monoid (Big ks) => Big (k ': k ': ks) -> Big ks\r\nflatten = undefined\r\n}}} \r\n\r\nSorry, the example is a bit big but almost any change causes the errors to appear again including the `Monoid` constraint on `flatten`.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15961TH 'Lift' instance for 'NonEmpty'2019-07-07T18:02:16Zfr33domloverTH 'Lift' instance for 'NonEmpty'I was using `deriving Lift` on a data type and the `DeriveLift` extension:
```hs
import Data.List.NonEmpty
import Language.Haskell.TH
data T = T (NonEmpty String) Int deriving Lift
```
and I noticed I couldn't get an automatic instanc...I was using `deriving Lift` on a data type and the `DeriveLift` extension:
```hs
import Data.List.NonEmpty
import Language.Haskell.TH
data T = T (NonEmpty String) Int deriving Lift
```
and I noticed I couldn't get an automatic instance because `NonEmpty` doesn't have a `Lift` instance. I'm wondering if an instance can be added to the `template-haskell` package (or elsewhere if that isn't the right place? I'm assuming it is because `NonEmpty` is in `base` now)
Since `NonEmpty` has a `Data` instance, I suppose the following would be enough?
```hs
instance Data a => Lift (NonEmpty a)
```
And without using `Data` it could be:
```hs
nonemptyConName :: Name
nonemptyConName = mkNameG DataName "base" "Data.List.NonEmpty" ":|"
instance Lift a => Lift (NonEmpty a) where
lift (x :| xs) = do
x' <- lift x
xs' <- traverse lift xs
return $ ConE nonemptyConName `AppE` x' `AppE` xs'
```8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15956Linker error building `runghc`2019-07-07T18:02:17ZAlec TheriaultLinker error building `runghc`I'm on MacOS trying to build `master`. Hadrian fails where `make` succeeds. I'm not doing anything fancy either..
```
ghc$ git rev-parse HEAD
df570d920fa66db631f936fa377e598fe92bd2a1
ghc$ ./boot && ./configure
ghc$ make -j V=0 ...I'm on MacOS trying to build `master`. Hadrian fails where `make` succeeds. I'm not doing anything fancy either..
```
ghc$ git rev-parse HEAD
df570d920fa66db631f936fa377e598fe92bd2a1
ghc$ ./boot && ./configure
ghc$ make -j V=0 # succeeds
ghc$ ./hadrian/build.sh -c --build-root="_build2" > out.log 2> err.log # fails
```
Hadrian fails when trying to link `runghc`:
```
Error when running Shake build system:
at src/Rules.hs:(34,19)-(47,17):
at src/Rules.hs:47:5-17:
* Depends on: _build2/stage1/bin/runghc
* Raised the exception:
user error (Development.Shake.cmd, system command failed
Command: _build2/stage0/bin/ghc -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-db _build2/stage1/lib/package.conf.d' '-package-id base-4.12.0.0' '-package-id directory-1.3.3.1' '-package-id filepath-1.4.2.1' '-package-id process-1.6.3.0' '-package-id unix-2.7.2.2' -i -i_build2/stage1/utils/runghc/build -i_build2/stage1/utils/runghc/build/runghc/autogen -iutils/runghc/. -Iincludes -I_build2/generated -I_build2/stage1/utils/runghc/build -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx-ghc-8.7.20181126/process-1.6.3.0/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx-ghc-8.7.20181126/unix-2.7.2.2/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx-ghc-8.7.20181126/time-1.9.2/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx-ghc-8.7.20181126/bytestring-0.10.9.0/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx-ghc-8.7.20181126/base-4.12.0.0/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx-ghc-8.7.20181126/integer-gmp-1.0.2.0/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx-ghc-8.7.20181126/rts-1.0/include -I_build2/generated -optc-I_build2/generated -optP-include -optP_build2/stage1/utils/runghc/build/runghc/autogen/cabal_macros.h -optc-fno-stack-protector -odir _build2/stage1/utils/runghc/build -hidir _build2/stage1/utils/runghc/build -stubdir _build2/stage1/utils/runghc/build -no-auto-link-packages -rtsopts -optl-lgmp -Wnoncanonical-monad-instances -optc-Wno-unknown-pragmas _build2/stage1/utils/runghc/build/Main.o -o _build2/stage1/bin/runghc -O2 -H32m -XHaskell2010 -ghcversion-file=/Users/atheriault/Code/ghc/_build2/generated/ghcversion.h
Exit code: 1
Stderr:
Undefined symbols for architecture x86_64:
"_findPtr", referenced from:
-u command line option
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
`gcc' failed in phase `Linker'. (Exit code: 1)
)
```
This must be a recent regression, since I was successfully building with Hadrian as recently as last week. I'll try to bisect, although the failure occurs so late in the compilation pipeline that I expect progress to be quite slow.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System (Hadrian) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Linker error buidling `runghc`","status":"New","operating_system":"","component":"Build System (Hadrian)","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I'm on MacOS trying to build `master`. Hadrian fails where `make` succeeds. I'm not doing anything fancy either..\r\n\r\n{{{\r\nghc$ git rev-parse HEAD\r\ndf570d920fa66db631f936fa377e598fe92bd2a1\r\nghc$ ./boot && ./configure\r\nghc$ make -j V=0 # succeeds\r\nghc$ ./hadrian/build.sh -c --build-root=\"_build2\" > out.log 2> err.log # fails\r\n}}}\r\n\r\nHadrian fails when trying to link `runghc`:\r\n\r\n{{{\r\nError when running Shake build system:\r\n at src/Rules.hs:(34,19)-(47,17):\r\n at src/Rules.hs:47:5-17:\r\n* Depends on: _build2/stage1/bin/runghc\r\n* Raised the exception:\r\nuser error (Development.Shake.cmd, system command failed\r\nCommand: _build2/stage0/bin/ghc -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-db _build2/stage1/lib/package.conf.d' '-package-id base-4.12.0.0' '-package-id directory-1.3.3.1' '-package-id filepath-1.4.2.1' '-package-id process-1.6.3.0' '-package-id unix-2.7.2.2' -i -i_build2/stage1/utils/runghc/build -i_build2/stage1/utils/runghc/build/runghc/autogen -iutils/runghc/. -Iincludes -I_build2/generated -I_build2/stage1/utils/runghc/build -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx-ghc-8.7.20181126/process-1.6.3.0/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx-ghc-8.7.20181126/unix-2.7.2.2/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx-ghc-8.7.20181126/time-1.9.2/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx-ghc-8.7.20181126/bytestring-0.10.9.0/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx-ghc-8.7.20181126/base-4.12.0.0/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx-ghc-8.7.20181126/integer-gmp-1.0.2.0/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx-ghc-8.7.20181126/rts-1.0/include -I_build2/generated -optc-I_build2/generated -optP-include -optP_build2/stage1/utils/runghc/build/runghc/autogen/cabal_macros.h -optc-fno-stack-protector -odir _build2/stage1/utils/runghc/build -hidir _build2/stage1/utils/runghc/build -stubdir _build2/stage1/utils/runghc/build -no-auto-link-packages -rtsopts -optl-lgmp -Wnoncanonical-monad-instances -optc-Wno-unknown-pragmas _build2/stage1/utils/runghc/build/Main.o -o _build2/stage1/bin/runghc -O2 -H32m -XHaskell2010 -ghcversion-file=/Users/atheriault/Code/ghc/_build2/generated/ghcversion.h\r\nExit code: 1\r\nStderr:\r\nUndefined symbols for architecture x86_64:\r\n \"_findPtr\", referenced from:\r\n -u command line option\r\nld: symbol(s) not found for architecture x86_64\r\nclang: error: linker command failed with exit code 1 (use -v to see invocation)\r\n`gcc' failed in phase `Linker'. (Exit code: 1)\r\n)\r\n}}}\r\n\r\n\r\nThis must be a recent regression, since I was successfully building with Hadrian as recently as last week. I'll try to bisect, although the failure occurs so late in the compilation pipeline that I expect progress to be quite slow.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Alec TheriaultAlec Theriaulthttps://gitlab.haskell.org/ghc/ghc/-/issues/15955Cannot get debugging symbols for compiled c-sources2019-07-07T18:02:17ZNiklas Hambüchenmail@nh2.meCannot get debugging symbols for compiled c-sourcesI cannot for my life figure out how to pass `-g` to some cabal-file `c-sources`'s compilation.
I've tried putting various combinations into `ghc-options`, but for the cases where compilation runs through, debugging symbols are not prese...I cannot for my life figure out how to pass `-g` to some cabal-file `c-sources`'s compilation.
I've tried putting various combinations into `ghc-options`, but for the cases where compilation runs through, debugging symbols are not present, and for all other cases the assembler crashes, with the message as shown in my little survey of flags and whether they end up at `as` (as determined via `strace`):
```
Using ghc-8.2.2
-g -optc-g -opta-g -optc-Wa,-g -opta-Wa,-g
passes -g to as
-g -optc-g -opta-g -optc-Wa,-g
does not pass -g to as
-g -optc-g -opta-g -opta-Wa,-g
passes -g to as
-optc-g -opta-g -opta-Wa,-g
does not pass -g to as
-g -opta-g -opta-Wa,-g
passes --gdwarf2 and -g to as
-g -opta-Wa,-g
passes -g to as (and no --gdwarf2)
-g -opta-g
passes --gdwarf2 to as, but no -g
However, in all the last 3 cases above where some form of -g is passed, the build fails with
/tmp/ghc6595_0/ghc_4.s:444:0: error:
Error: file number 1 already allocated
|
444 | .file 1 "src/Codec/Compression/LZ4/Conduit.hsc"
| ^
`gcc' failed in phase `Assembler'. (Exit code: 1)
```
(copied from https://gist.github.com/nh2/b57ed4c419f7b13d7cc299caa335f3ab)8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15954LiberalTypeSynonyms unsaturation check doesn't kick in2019-07-07T18:02:18ZRyan ScottLiberalTypeSynonyms unsaturation check doesn't kick inGHC accepts this program:
```hs
{-# LANGUAGE ImpredicativeTypes #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE RankNTypes #-}
module Bug where
import GHC.Exts (Any)
type KindOf (a :: k) = k
type A a = (Any :: a)
type KA = KindOf A
```
B...GHC accepts this program:
```hs
{-# LANGUAGE ImpredicativeTypes #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE RankNTypes #-}
module Bug where
import GHC.Exts (Any)
type KindOf (a :: k) = k
type A a = (Any :: a)
type KA = KindOf A
```
But it really oughtn't to. After all, we have an unsaturated use of `A` in `KindOf A`, and we don't have `LiberalTypeSynonyms` enabled!
What's even stranger is that there seems to be something about this exact setup that sneaks by `LiberalTypeSynonyms`' validity checks. If I add another argument to `A`:
```hs
type A x a = (Any :: a)
```
Then it //does// error:
```
$ /opt/ghc/8.6.2/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:10:1: error:
• Illegal polymorphic type: forall a -> a
Perhaps you intended to use LiberalTypeSynonyms
• In the type synonym declaration for ‘KA’
|
10 | type KA = KindOf A
| ^^^^^^^^^^^^^^^^^^
```
Similarly, if I use something besides `KindOf`:
```hs
{-# LANGUAGE ImpredicativeTypes #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE RankNTypes #-}
module Bug where
import GHC.Exts (Any)
type A a = (Any :: a)
type B a = Int
type C = B A
```
Then I also get the same `Illegal polymorphic type: forall a -> a` error.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"LiberalTypeSynonyms unsaturation check doesn't kick in","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC accepts this program:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE ImpredicativeTypes #-}\r\n{-# LANGUAGE PolyKinds #-}\r\n{-# LANGUAGE RankNTypes #-}\r\nmodule Bug where\r\n\r\nimport GHC.Exts (Any)\r\n\r\ntype KindOf (a :: k) = k\r\ntype A a = (Any :: a)\r\ntype KA = KindOf A\r\n}}}\r\n\r\nBut it really oughtn't to. After all, we have an unsaturated use of `A` in `KindOf A`, and we don't have `LiberalTypeSynonyms` enabled!\r\n\r\nWhat's even stranger is that there seems to be something about this exact setup that sneaks by `LiberalTypeSynonyms`' validity checks. If I add another argument to `A`:\r\n\r\n{{{#!hs\r\ntype A x a = (Any :: a)\r\n}}}\r\n\r\nThen it //does// error:\r\n\r\n{{{\r\n$ /opt/ghc/8.6.2/bin/ghc Bug.hs\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\n\r\nBug.hs:10:1: error:\r\n • Illegal polymorphic type: forall a -> a\r\n Perhaps you intended to use LiberalTypeSynonyms\r\n • In the type synonym declaration for ‘KA’\r\n |\r\n10 | type KA = KindOf A\r\n | ^^^^^^^^^^^^^^^^^^\r\n}}}\r\n\r\nSimilarly, if I use something besides `KindOf`:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE ImpredicativeTypes #-}\r\n{-# LANGUAGE PolyKinds #-}\r\n{-# LANGUAGE RankNTypes #-}\r\nmodule Bug where\r\n\r\nimport GHC.Exts (Any)\r\n\r\ntype A a = (Any :: a)\r\ntype B a = Int\r\ntype C = B A\r\n}}}\r\n\r\nThen I also get the same `Illegal polymorphic type: forall a -> a` error.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15953GHC always dumps the output of -ddump-hpc to STDOUT2019-07-07T18:02:18ZChaitanya Koparkarckoparkar@gmail.comGHC always dumps the output of -ddump-hpc to STDOUTInstead, it should write the output to a file if `-ddump-to-file` is enabled.
`-ddump-core-stats` also has a similar problem. But given that it always prints just one line, maybe it should continue to print to `STDOUT`.
<details><summa...Instead, it should write the output to a file if `-ddump-to-file` is enabled.
`-ddump-core-stats` also has a similar problem. But given that it always prints just one line, maybe it should continue to print to `STDOUT`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ckoparkar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC always dumps the output of -ddump-hpc to STDOUT","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ckoparkar"],"type":"Bug","description":"Instead, it should write the output to a file if `-ddump-to-file` is enabled.\r\n\r\n`-ddump-core-stats` also has a similar problem. But given that it always prints just one line, maybe it should continue to print to `STDOUT`.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15951Hadrian test doesn't show testsuite output by default2019-07-07T18:02:19ZBen GamariHadrian test doesn't show testsuite output by defaultWhen running `hadrian test` the user sees no indication that the build system is actually doing anything beyond the furious whirring of their CPU fan. Once the testsuite finishes Hadrian kindly informs the user that the testsuite passed ...When running `hadrian test` the user sees no indication that the build system is actually doing anything beyond the furious whirring of their CPU fan. Once the testsuite finishes Hadrian kindly informs the user that the testsuite passed or failed, but provides no additional feedback on what failed or where the output can be found.
We should just print all testsuite output to stdout, as the `make` build system does.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System (Hadrian) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | alpmestan, snowleopard |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Hadrian test doesn't show testsuite output by default","status":"New","operating_system":"","component":"Build System (Hadrian)","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["alpmestan","snowleopard"],"type":"Bug","description":"When running `hadrian test` the user sees no indication that the build system is actually doing anything beyond the furious whirring of their CPU fan. Once the testsuite finishes Hadrian kindly informs the user that the testsuite passed or failed, but provides no additional feedback on what failed or where the output can be found.\r\n\r\nWe should just print all testsuite output to stdout, as the `make` build system does.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15950Hadrian build fails on Windows2019-07-07T18:02:19ZBen GamariHadrian build fails on WindowsAs of 509d5be69c7507ba5d0a5f39ffd1613a59e73eea,
```
$ hadrian/build.cabal.sh -j5 --flavour=Quick
...
$ hadrian/build.cabal.sh -j5 --flavour=Quick
| ContextData oracle: resolving data for 'iserv' (Stage1, v)...
| Configure package 'iser...As of 509d5be69c7507ba5d0a5f39ffd1613a59e73eea,
```
$ hadrian/build.cabal.sh -j5 --flavour=Quick
...
$ hadrian/build.cabal.sh -j5 --flavour=Quick
| ContextData oracle: resolving data for 'iserv' (Stage1, v)...
| Configure package 'iserv'
Configuring iserv-8.7.1...
creating
C:\msys64\home\ben\ghc\builds\0\project-0\_build\stage1\utils\iserv\build
"C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" "--numeric-version"
]0;1s (99%)C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe is version
8.7.20181126
"C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc-pkg.exe" "--version"
C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc-pkg.exe is
version 8.7.20181126
"C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" "--supported-languages"
"C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" "--info"
Reading installed packages...
"C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc-pkg.exe" "dump" "--global" "-v0" "--global-package-db=C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage1/lib/package.conf.d"
"C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" "--print-libdir" "-ghcversion-file=C:/msys64/home/ben/ghc/builds/0/project-0/_build/generated/ghcversion.h"
CallStack (from HasCallStack):
die', called at .\Distribution\Simple\Configure.hs:969:20 in Cabal-2.5.0.0-inplace:Distribution.Simple.Configure
configureFinalizedPackage, called at .\Distribution\Simple\Configure.hs:467:12 in Cabal-2.5.0.0-inplace:Distribution.Simple.Configure
configure, called at .\Distribution\Simple.hs:596:20 in Cabal-2.5.0.0-inplace:Distribution.Simple
confHook, called at .\Distribution\Simple\UserHooks.hs:67:5 in Cabal-2.5.0.0-inplace:Distribution.Simple.UserHooks
configureAction, called at .\Distribution\Simple.hs:178:19 in Cabal-2.5.0.0-inplace:Distribution.Simple
defaultMainHelper, called at .\Distribution\Simple.hs:148:3 in Cabal-2.5.0.0-inplace:Distribution.Simple
defaultMainWithHooksNoReadArgs, called at src\Hadrian\Haskell\Cabal\Parse.hs:145:14 in main:Hadrian.Haskell.Cabal.Parse
hadrian.exe: Encountered missing dependencies:
libiserv ==8.7.*
]0;FinishedshakeArgsWith 0.003s 0%
Function shake 0.442s 2%
Database read 0.851s 3% =
With database 0.033s 0%
Running rules 20.749s 93% =========================
Total 22.079s 100%
Error when running Shake build system:
at src/Main.hs:58:30-42:
* Depends on: test
at src/Rules/Test.hs:109:5-9:
* Depends on: _build/stage1/lib/bin/ghc-iserv.exe
at src/Development/Shake/Internal/Rules/Oracle.hs:157:43-68:
* Depends on: OracleQ (ContextDataKey (Context {stage = Stage1, package = Package {pkgType = Program, pkgName = "iserv", pkgPath = "utils/iserv"}, way = v}))
at src/Hadrian/Haskell/Cabal/Parse.hs:202:5-36:
* Depends on: _build/stage1/utils/iserv/setup-config
* Raised the exception:
ExitFailure 1
```
(Ignore garbage characters due to Window's broken ANSI console support).
This seems to only be reproducible on Windows.8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15949Hadrian needs more convenient build target names2019-07-07T18:02:19ZBen GamariHadrian needs more convenient build target namesWith the `make` build system one can easily build a particular library or executable by `cd`ing into the relevant directory and typing `make`. With `hadrian` there appears to be no convenient way to replicate this. Instead, you need to k...With the `make` build system one can easily build a particular library or executable by `cd`ing into the relevant directory and typing `make`. With `hadrian` there appears to be no convenient way to replicate this. Instead, you need to know the name of the final target which the build will produce which may contain version numbers, platform triples, and all sorts of other ugliness.
I suggest we introduce a set of convenience targets to make this easier. For instance one could run:
```
$ hadrian stage1:lib:ghc
```
to build the stage1 `ghc` library or
```
$ hadrian stage2:exe:hp2ps
```
to build `hp2ps`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.6.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | alpmestan, snowleopard |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Hadrian needs more convenient build target names","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["alpmestan","snowleopard"],"type":"FeatureRequest","description":"With the `make` build system one can easily build a particular library or executable by `cd`ing into the relevant directory and typing `make`. With `hadrian` there appears to be no convenient way to replicate this. Instead, you need to know the name of the final target which the build will produce which may contain version numbers, platform triples, and all sorts of other ugliness.\r\n\r\nI suggest we introduce a set of convenience targets to make this easier. For instance one could run:\r\n{{{\r\n$ hadrian stage1:lib:ghc\r\n}}}\r\nto build the stage1 `ghc` library or\r\n{{{\r\n$ hadrian stage2:exe:hp2ps\r\n}}}\r\nto build `hp2ps`.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Alp MestanogullariAlp Mestanogullarihttps://gitlab.haskell.org/ghc/ghc/-/issues/15948Hadrian build fails on Windows when invoked without --configure flag2021-08-02T08:17:30ZBen GamariHadrian build fails on Windows when invoked without --configure flagThe Hadrian build on Windows currently fails with
```
'C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe' exited
ghc.exe: could not detect mingw toolchain
```
when trying to build the RTS.
I strongly suspect that the...The Hadrian build on Windows currently fails with
```
'C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe' exited
ghc.exe: could not detect mingw toolchain
```
when trying to build the RTS.
I strongly suspect that the problem is that the stage1 toolchain built by Hadrian lives in `_build/stage0/bin/ghc` whereas the mingw tarballs were extracted to `inplace/mingw`. It's quite unclear to me how this ever worked.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Build System (Hadrian) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | alpmestan, snowleopard |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Hadrian cannot build on Windows","status":"New","operating_system":"","component":"Build System (Hadrian)","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["alpmestan","snowleopard"],"type":"Bug","description":"The Hadrian build on Windows currently fails with\r\n{{{\r\n'C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe' exited\r\nghc.exe: could not detect mingw toolchain\r\n}}}\r\nwhen trying to build the RTS.\r\n\r\nI strongly suspect that the problem is that the stage1 toolchain built by Hadrian lives in `_build/stage0/bin/ghc` whereas the mingw tarballs were extracted to `inplace/mingw`. It's quite unclear to me how this ever worked.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15946configure script makes use of ln -v flag which is not supported in OpenBSD2019-07-07T18:02:20Zklomeliconfigure script makes use of ln -v flag which is not supported in OpenBSDAfter some head-scratching, I found that the configure script makes use of \*\*ln\*\*'s \*\*-v\*\* verbose flag. This flag does not exist in OpenBSD's version of \*\*ln\*\*. It was causing the build process to fail due to some files not ...After some head-scratching, I found that the configure script makes use of \*\*ln\*\*'s \*\*-v\*\* verbose flag. This flag does not exist in OpenBSD's version of \*\*ln\*\*. It was causing the build process to fail due to some files not existing during the compilation process.
I'm getting around this by removing all \*\*-v\*\* occurrences as a pre-compilation step:
```
find . -type f | xargs sed -i -e 's|^ln -f -v |ln -f |'
```
To make the process a little smoother for other folks, perhaps creating an alias that is conditional based OS type at the header of the script along the lines of would be best:
```
case "$build_os" in
openbsd*)
alias mksymlnk="ln -f"
;;
*)
alias mksymlnk="ln -f -v"
;;
esac
...
mksymlnk utils/fs/fs.* utils/lndir/
...
```8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15945Unable to compile GHC from source: redefinition of '_DYNAMIC' as different ki...2019-07-07T18:02:21ZklomeliUnable to compile GHC from source: redefinition of '_DYNAMIC' as different kind of symbolI am running the following script to build GHC from sources (ghc-8.6.2-src.tar.xz) on OpenBSD (-CURRENT):
{{{
\#! /bin/sh
set -e
BUILD_DIR=/usr/local/tmp-build-ghc
export AUTOCONF_VERSION=2.69
export AUTOMAKE_VERSION=1.16
if \[ ! -n ...I am running the following script to build GHC from sources (ghc-8.6.2-src.tar.xz) on OpenBSD (-CURRENT):
{{{
\#! /bin/sh
set -e
BUILD_DIR=/usr/local/tmp-build-ghc
export AUTOCONF_VERSION=2.69
export AUTOMAKE_VERSION=1.16
if \[ ! -n "$1" \]; then
echo "ERROR: Provide path for ghc source."
> exit 1
fi
echo "Extracting ghc source files from ${1} to ${BUILD_DIR} ..."
mkdir -p $BUILD_DIR
cd $BUILD_DIR
xzcat $1 \| tar xvf -
GHC_DIR=`ls | grep ghc`
cd $GHC_DIR
echo "Cleaning up OpenBSD-incompatible commands..."
find . -type f \| xargs sed -i -e 's\|\^ln -f -v \|ln -f \|'
echo "Building GHC... "
export CC=/usr/bin/clang
1. /boot
1. /configure --with-iconv-libraries=/usr/local/lib \\
--with-iconv-includes=/usr/local/include \\
--with-gmp-libraries=/usr/local/lib \\
--with-gmp-includes=/usr/local/include \\
--with-ffi-libraries=/usr/local/lib \\
--with-ffi-includes=/usr/local/include \\
> --with-system-libffi
gmake
}}}
I have filed a separate bug report for the \*\*ln\*\* incompatibility with the unsupported \*\*-v\*\* flag.
When compiling GHC, I get the following error:
```
...
"inplace/bin/ghc-stage1" -optc-fno-stack-protector -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-Wundef -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-DFS_NAMESPACE=rts -optc-fno-strict-aliasing -optc-fno-common -optc-Irts/dist/build/./autogen -optc-Wno-unknown-pragmas -optc-O2 -optc-fomit-frame-pointer -optc-g -optc-DRtsWay=\"rts_v\" -optc-ffunction-sections -optc-fdata-sections -static -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/RtsSymbols.c -o rts/dist/build/RtsSymbols.o
rts/RtsSymbols.c:990:1: error:
error: redefinition of '_DYNAMIC' as different kind of symbol
|
990 | RTS_OPENBSD_ONLY_SYMBOLS
| ^
RTS_OPENBSD_ONLY_SYMBOLS
^
rts/RtsSymbols.c:283:22: error:
note: expanded from macro 'RTS_OPENBSD_ONLY_SYMBOLS'
SymE_NeedsProto(_DYNAMIC)
^
|
283 | SymE_NeedsProto(_DYNAMIC)
| ^
/usr/include/sys/exec_elf.h:765:17: error:
note: previous definition is here
|
765 | extern Elf_Dyn _DYNAMIC[];
| ^
extern Elf_Dyn _DYNAMIC[];
^
1 error generated.
`clang' failed in phase `C Compiler'. (Exit code: 1)
gmake[1]: *** [rts/ghc.mk:315: rts/dist/build/RtsSymbols.o] Error 1
gmake: *** [Makefile:127: all] Error 2
```
Any suggestions appreciated. Thanks!8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15941Pretty-printing of invisible arguments to (->)2019-07-07T18:02:21ZKrzysztof GogolewskiPretty-printing of invisible arguments to (->)The invisible arguments to `(->)` are currently printed as:
```
λ> :set -XKindSignatures -fprint-explicit-runtime-reps -fprint-explicit-kinds
λ> type T = ((->) :: * -> * -> *)
λ> :i T
type T =
@{'GHC.Types.LiftedRep} -> @{'GHC.Types.L...The invisible arguments to `(->)` are currently printed as:
```
λ> :set -XKindSignatures -fprint-explicit-runtime-reps -fprint-explicit-kinds
λ> type T = ((->) :: * -> * -> *)
λ> :i T
type T =
@{'GHC.Types.LiftedRep} -> @{'GHC.Types.LiftedRep} :: * -> * -> *
```
I'd expect
```
type T = (->) @{'GHC.Types.LiftedRep} @{'GHC.Types.LiftedRep} :: * -> * -> *
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.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":"Pretty-printing of invisible arguments to (->)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The invisible arguments to `(->)` are currently printed as:\r\n\r\n{{{\r\nλ> :set -XKindSignatures -fprint-explicit-runtime-reps -fprint-explicit-kinds\r\nλ> type T = ((->) :: * -> * -> *)\r\nλ> :i T\r\ntype T =\r\n @{'GHC.Types.LiftedRep} -> @{'GHC.Types.LiftedRep} :: * -> * -> *\r\n}}}\r\n\r\nI'd expect\r\n{{{\r\ntype T = (->) @{'GHC.Types.LiftedRep} @{'GHC.Types.LiftedRep} :: * -> * -> *\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Ryan ScottRyan Scotthttps://gitlab.haskell.org/ghc/ghc/-/issues/15938Hadrian's recompilation check is extremely slow2019-07-07T18:02:22ZBen GamariHadrian's recompilation check is extremely slowI just Ctrl-C'd hadrian while it was building `libraries/base`, having noticed that I forgot to start it with `-j`. I then immediately restarted it and noticed that Hadrian needed to think for 45 seconds before it started even a single b...I just Ctrl-C'd hadrian while it was building `libraries/base`, having noticed that I forgot to start it with `-j`. I then immediately restarted it and noticed that Hadrian needed to think for 45 seconds before it started even a single build. This is orders of magnitude worse than `make` so something must be wrong.
I'm setting this at high priority since 45 seconds is longer than many complete `make` rebuilds.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Build System (Hadrian) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Hadrian's recompilation check is extremely slow","status":"New","operating_system":"","component":"Build System (Hadrian)","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I just Ctrl-C'd hadrian while it was building `libraries/base`, having noticed that I forgot to start it with `-j`. I then immediately restarted it and noticed that Hadrian needed to think for 45 seconds before it started even a single build. This is orders of magnitude worse than `make` so something must be wrong.\r\n\r\nI'm setting this at high priority since 45 seconds is longer than many complete `make` rebuilds.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Alp MestanogullariAlp Mestanogullarihttps://gitlab.haskell.org/ghc/ghc/-/issues/15934Building ghc with profiling libraries fails on windows.2022-07-13T14:44:18ZAndreas KlebingerBuilding ghc with profiling libraries fails on windows.I've initially only hit this when enabling -g, but now I've run into the same issue without a customized build.mk file.
----
Seems like we create too many sections in a single file on windows.
```
C://ghc//msys64//home//Andi//ghc_head...I've initially only hit this when enabling -g, but now I've run into the same issue without a customized build.mk file.
----
Seems like we create too many sections in a single file on windows.
```
C://ghc//msys64//home//Andi//ghc_head//inplace//mingw//bin/as.exe: C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_6.p_o: too many sections (32801)
C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_1.s: Assembler messages:
C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_1.s: Fatal error: can't write 4 bytes to section .rdata$c1w2b_str of C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_6.p_o because: 'File too big'
C://ghc//msys64//home//Andi//ghc_head//inplace//mingw//bin/as.exe: C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_6.p_o: too many sections (32801)
C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_1.s: Fatal error: can't close C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_6.p_o: File too big
`gcc.exe' failed in phase `Assembler'. (Exit code: 1)
make[1]: *** [libraries/template-haskell/ghc.mk:4: libraries/template-haskell/dist-install/build/Language/Haskell/TH/Syntax.p_o] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [Makefile:128: all] Error 2
```
build.mk
```
ifneq "$(BuildFlavour)" ""
include mk/flavours/$(BuildFlavour).mk
endif
GhcLibHcOpts += -g1
GhcRtsHcOpts += -g1
# GhcStage2HcOpts += -g3
BUILD_PROF_LIBS=YES
# Don't strip debug and other unneeded symbols from libraries and executables.
STRIP_CMD = :
HADDOCK_DOCS = NO
BUILD_SPHINX_HTML = NO
BUILD_SPHINX_PDF = NO
BUILD_MAN = NO
```8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15930Add @since-annotations to the Foldable methods2019-07-07T18:02:24ZSimon JakobiAdd @since-annotations to the Foldable methodsMethods like `sum` were added some time after `Foldable`'s inception. It would be nice to know when exactly.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------...Methods like `sum` were added some time after `Foldable`'s inception. It would be nice to know when exactly.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.6.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add @since-annotations to the Foldable methods","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Methods like `sum` were added some time after `Foldable`'s inception. It would be nice to know when exactly.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1