GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-01-19T11:48:16Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15397Linking Issue with libffi on Ubuntu and Fedora with Provided Bindists2024-01-19T11:48:16ZAra AdkinsLinking Issue with libffi on Ubuntu and Fedora with Provided BindistsIt appears that the bindists being given to both ubuntu and fedora users are subtly broken. When attempting to link a binary depending on libffi, the linker picks up the copy of `libffi.so.7` found in the rts folder of the distribution. ...It appears that the bindists being given to both ubuntu and fedora users are subtly broken. When attempting to link a binary depending on libffi, the linker picks up the copy of `libffi.so.7` found in the rts folder of the distribution. This means that at runtime, despite the systems in question having a copy of `libffi.so.6`, the binary can't find the correct shared library to link against.
This does not happen on Arch Linux or Gentoo, as `/usr/lib` or `/usr/lib64` are included in their linker invocations respectively, allowing the linker to pick up the correct version of the dependency.
You can reproduce the issue quickly by cloning [Luna Core](https://github.com/luna/luna-core) and executing the following commands. I suggest doing this on an Ubuntu or Fedora system as I know it fails on those two distros.
```
stack build luna-shell --fast
stack exec luna
```
You should see something along the lines of the following.
```
error while loading shared libraries: libffi.so.7: cannot open shared object file: No such file or directory
```
In essence, the reproduction steps are as follows:
1. Create a project depending on libffi using ghc-8.4.2
1. Build the project
1. Execute it
The *expected* result is that the binary links against the system copy of `libffi.so.6`, rather than the `libffi.so.7` provided in the ghc distribution.
I can't guarantee that Ubuntu and Fedora are the only affected systems, but I know that Arch Linux and Gentoo were both fine with the provided bindists. All tested systems were x64, so I cannot confirm if the issue affects x86 bindists.
The actual symptom appears to be a result of the linker never being given the path to the system library directory (e.g. `/usr/lib` or `/usr/lib64`), whereas on Arch and Gentoo, the linkline does contain that directory.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.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":"Linking Issue on Ubuntu and Fedora with Provided Bindists (GHC-8.4.2)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.4.4","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"It appears that the bindists being given to both ubuntu and fedora users are subtly broken. When attempting to link a binary depending on libffi, the linker picks up the copy of `libffi.so.7` found in the rts folder of the distribution. This means that at runtime, despite the systems in question having a copy of `libffi.so.6`, the binary can't find the correct shared library to link against.\r\n\r\nThis does not happen on Arch Linux or Gentoo, as `/usr/lib` or `/usr/lib64` are included in their linker invocations respectively, allowing the linker to pick up the correct version of the dependency.\r\n\r\nYou can reproduce the issue quickly by cloning [https://github.com/luna/luna-core Luna Core] and executing the following commands. I suggest doing this on an Ubuntu or Fedora system as I know it fails on those two distros.\r\n\r\n{{{\r\nstack build luna-shell --fast\r\nstack exec luna\r\n}}}\r\n\r\nYou should see something along the lines of the following. \r\n\r\n{{{\r\nerror while loading shared libraries: libffi.so.7: cannot open shared object file: No such file or directory\r\n}}}\r\n\r\nIn essence, the reproduction steps are as follows:\r\n\r\n1. Create a project depending on libffi using ghc-8.4.2\r\n2. Build the project\r\n3. Execute it\r\n\r\n\r\nThe ''expected'' result is that the binary links against the system copy of `libffi.so.6`, rather than the `libffi.so.7` provided in the ghc distribution. \r\n\r\nI can't guarantee that Ubuntu and Fedora are the only affected systems, but I know that Arch Linux and Gentoo were both fine with the provided bindists. All tested systems were x64, so I cannot confirm if the issue affects x86 bindists. \r\n\r\nThe actual symptom appears to be a result of the linker never being given the path to the system library directory (e.g. `/usr/lib` or `/usr/lib64`), whereas on Arch and Gentoo, the linkline does contain that directory. ","type_of_failure":"OtherFailure","blocking":[]} -->8.4.4https://gitlab.haskell.org/ghc/ghc/-/issues/15436Compile-time panic, Prelude.!!: negative index2019-07-07T18:04:54ZpbrisbinCompile-time panic, Prelude.!!: negative indexHere is a reproduction case:
- \*ghc-repro.cabal\*\*
```
name: ghc-repro
version: 0.0.0
build-type: Simple
cabal-version: >= 1.10
library
exposed-modules:
Lib
other-modules:
Paths_ghc_repro
hs-s...Here is a reproduction case:
- \*ghc-repro.cabal\*\*
```
name: ghc-repro
version: 0.0.0
build-type: Simple
cabal-version: >= 1.10
library
exposed-modules:
Lib
other-modules:
Paths_ghc_repro
hs-source-dirs:
src
build-depends:
base
default-language: Haskell2010
```
- \*src/Lib.hs\*\*
```hs
{-# OPTIONS_GHC -v4 #-}
module Lib where
import GHC.Enum
-- | At this many elements, it panics. One fewer, it works
data USState = AL | AK | AZ | AR | CA | CO | CT | DE | FL -- | GA
-- | HI | ID | IL | IN | IA | KS | KY | LA | ME | MD
-- | MA | MI | MN | MS | MO | MT | NE | NV | NH | NJ
-- | NM | NY | NC | ND | OH | OK | OR | PA | RI | SC
-- | SD | TN | TX | UT | VT | VA | WA | WV | WI | WY
-- | DC | PR | VI | AS | GU | MP | AA | AE | AP
deriving (Eq, Show, Ord, Bounded, Read, Enum)
data USStateOrIntl = International | US USState
instance Enum USStateOrIntl where
fromEnum International = 0
fromEnum (US s) = 1 + fromEnum s
enumFrom = boundedEnumFrom
enumFromThen = boundedEnumFromThen
toEnum 0 = International
toEnum i = US . toEnum $ i - 1
instance Bounded USStateOrIntl where
minBound = International
maxBound = US maxBound
```
- \*Results\*\*:
```
ghc-repro-0.0.0: build (lib)
Preprocessing library for ghc-repro-0.0.0..
Building library for ghc-repro-0.0.0..
Running phase HsPp HsSrcFile
compile: input file src/Lib.hs
*** Checking old interface for ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib (use -ddump-hi-diffs for more details):
[1 of 2] Compiling Lib ( src/Lib.hs, .stack-work/dist/x86_64-linux/Cabal-2.2.0.1/build/Lib.o )
*** Parser [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]:
!!! Parser [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: finished in 8.31 milliseconds, allocated 17.533 megabytes
*** Renamer/typechecker [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]:
!!! Renamer/typechecker [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: finished in 354.49 milliseconds, allocated 312.556 megabytes
*** Desugar [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]:
Result size of Desugar (after optimization)
= {terms: 752, types: 352, coercions: 33, joins: 1/4}
!!! Desugar [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: finished in 142.79 milliseconds, allocated 226.278 megabytes
*** Simplifier [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]:
Result size of Simplifier iteration=1
= {terms: 1,222, types: 790, coercions: 143, joins: 1/3}
Result size of Simplifier iteration=2
= {terms: 1,219, types: 788, coercions: 126, joins: 0/1}
Result size of Simplifier
= {terms: 1,217, types: 786, coercions: 123, joins: 0/1}
!!! Simplifier [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: finished in 374.08 milliseconds, allocated 587.256 megabytes
*** Specialise [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]:
Result size of Specialise
= {terms: 1,217, types: 786, coercions: 123, joins: 0/1}
!!! Specialise [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: finished in 154.05 milliseconds, allocated 235.323 megabytes
*** Float out(FOS {Lam = Just 0,
Consts = True,
OverSatApps = False}) [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]:
Result size of Float out(FOS {Lam = Just 0,
Consts = True,
OverSatApps = False})
= {terms: 1,551, types: 1,410, coercions: 123, joins: 0/0}
!!! Float out(FOS {Lam = Just 0,
Consts = True,
OverSatApps = False}) [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: finished in 6.24 milliseconds, allocated 5.556 megabytes
*** Simplifier [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]:
Result size of Simplifier iteration=1
= {terms: 1,667, types: 1,082, coercions: 123, joins: 7/19}
ghc: panic! (the 'impossible' happened)
(GHC version 8.4.3 for x86_64-unknown-linux):
Prelude.!!: negative index
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
The above output was produced through my normal tooling, so
```
stack build --resolver lts-12.2 --pedantic
```
To rule out stack, I was also able to reproduce the panic with plain cabal using this \*\*Dockerfile\*\*:
```
FROM haskell:8.4.3
RUN mkdir /src
WORKDIR /src
COPY ghc-repro.cabal /src/ghc-repo.cabal
COPY src/Lib.hs /src/src/Lib.hs
RUN cabal build
```
```
docker build --tag ghc-repro .
```
It still panics, but the output is different and much larger so I'll leave it here: https://8n1.org/13499/5c92
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| 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":"Compile-time panic, Prelude.!!: negative index","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Here is a reproduction case:\r\n\r\n**ghc-repro.cabal**\r\n\r\n{{{\r\nname: ghc-repro\r\nversion: 0.0.0\r\nbuild-type: Simple\r\ncabal-version: >= 1.10\r\n\r\nlibrary\r\n exposed-modules:\r\n Lib\r\n other-modules:\r\n Paths_ghc_repro\r\n hs-source-dirs:\r\n src\r\n build-depends:\r\n base\r\n default-language: Haskell2010\r\n}}}\r\n\r\n**src/Lib.hs**\r\n\r\n{{{#!hs\r\n{-# OPTIONS_GHC -v4 #-}\r\nmodule Lib where\r\n\r\nimport GHC.Enum\r\n\r\n-- | At this many elements, it panics. One fewer, it works\r\ndata USState = AL | AK | AZ | AR | CA | CO | CT | DE | FL -- | GA\r\n -- | HI | ID | IL | IN | IA | KS | KY | LA | ME | MD\r\n -- | MA | MI | MN | MS | MO | MT | NE | NV | NH | NJ\r\n -- | NM | NY | NC | ND | OH | OK | OR | PA | RI | SC\r\n -- | SD | TN | TX | UT | VT | VA | WA | WV | WI | WY\r\n -- | DC | PR | VI | AS | GU | MP | AA | AE | AP\r\n deriving (Eq, Show, Ord, Bounded, Read, Enum)\r\n\r\ndata USStateOrIntl = International | US USState\r\n\r\ninstance Enum USStateOrIntl where\r\n fromEnum International = 0\r\n fromEnum (US s) = 1 + fromEnum s\r\n enumFrom = boundedEnumFrom\r\n enumFromThen = boundedEnumFromThen\r\n toEnum 0 = International\r\n toEnum i = US . toEnum $ i - 1\r\n\r\ninstance Bounded USStateOrIntl where\r\n minBound = International\r\n maxBound = US maxBound\r\n}}}\r\n\r\n\r\n**Results**:\r\n\r\n{{{\r\nghc-repro-0.0.0: build (lib)\r\nPreprocessing library for ghc-repro-0.0.0..\r\nBuilding library for ghc-repro-0.0.0..\r\nRunning phase HsPp HsSrcFile\r\ncompile: input file src/Lib.hs\r\n*** Checking old interface for ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib (use -ddump-hi-diffs for more details):\r\n[1 of 2] Compiling Lib ( src/Lib.hs, .stack-work/dist/x86_64-linux/Cabal-2.2.0.1/build/Lib.o )\r\n*** Parser [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]:\r\n!!! Parser [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: finished in 8.31 milliseconds, allocated 17.533 megabytes\r\n*** Renamer/typechecker [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]:\r\n!!! Renamer/typechecker [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: finished in 354.49 milliseconds, allocated 312.556 megabytes\r\n*** Desugar [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]:\r\nResult size of Desugar (after optimization)\r\n = {terms: 752, types: 352, coercions: 33, joins: 1/4}\r\n!!! Desugar [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: finished in 142.79 milliseconds, allocated 226.278 megabytes\r\n*** Simplifier [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]:\r\nResult size of Simplifier iteration=1\r\n = {terms: 1,222, types: 790, coercions: 143, joins: 1/3}\r\nResult size of Simplifier iteration=2\r\n = {terms: 1,219, types: 788, coercions: 126, joins: 0/1}\r\nResult size of Simplifier\r\n = {terms: 1,217, types: 786, coercions: 123, joins: 0/1}\r\n!!! Simplifier [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: finished in 374.08 milliseconds, allocated 587.256 megabytes\r\n*** Specialise [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]:\r\nResult size of Specialise\r\n = {terms: 1,217, types: 786, coercions: 123, joins: 0/1}\r\n!!! Specialise [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: finished in 154.05 milliseconds, allocated 235.323 megabytes\r\n*** Float out(FOS {Lam = Just 0,\r\n Consts = True,\r\n OverSatApps = False}) [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]:\r\nResult size of Float out(FOS {Lam = Just 0,\r\n Consts = True,\r\n OverSatApps = False})\r\n = {terms: 1,551, types: 1,410, coercions: 123, joins: 0/0}\r\n!!! Float out(FOS {Lam = Just 0,\r\n Consts = True,\r\n OverSatApps = False}) [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: finished in 6.24 milliseconds, allocated 5.556 megabytes\r\n*** Simplifier [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]:\r\nResult size of Simplifier iteration=1\r\n = {terms: 1,667, types: 1,082, coercions: 123, joins: 7/19}\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.4.3 for x86_64-unknown-linux):\r\n\tPrelude.!!: negative index\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nThe above output was produced through my normal tooling, so\r\n\r\n{{{\r\nstack build --resolver lts-12.2 --pedantic\r\n}}}\r\n\r\nTo rule out stack, I was also able to reproduce the panic with plain cabal using this **Dockerfile**:\r\n\r\n{{{\r\nFROM haskell:8.4.3\r\nRUN mkdir /src\r\nWORKDIR /src\r\nCOPY ghc-repro.cabal /src/ghc-repo.cabal\r\nCOPY src/Lib.hs /src/src/Lib.hs\r\nRUN cabal build\r\n}}}\r\n\r\n{{{\r\ndocker build --tag ghc-repro .\r\n}}}\r\n\r\nIt still panics, but the output is different and much larger so I'll leave it here: https://8n1.org/13499/5c92","type_of_failure":"OtherFailure","blocking":[]} -->8.4.4https://gitlab.haskell.org/ghc/ghc/-/issues/15260Xmobar crashes with segmentation fault2019-07-07T18:13:35ZVoronweXmobar crashes with segmentation faultOS: Arch
Kernel version: 4.16.13-2-ARCH
Xmobar version: 0.26
ghc version: 8.4.3
Xmobar crashes after some time (1 sec or 1 day - very different each time).
And, as I see, reasons are different to:
1:
```
voronwe@sul ~> xmobar
Fields ...OS: Arch
Kernel version: 4.16.13-2-ARCH
Xmobar version: 0.26
ghc version: 8.4.3
Xmobar crashes after some time (1 sec or 1 day - very different each time).
And, as I see, reasons are different to:
1:
```
voronwe@sul ~> xmobar
Fields missing from config defaulted: additionalFonts,wmClass,wmName,border,borderColor,textOffset,iconOffset,iconRoot,alpha
xmobar: internal error: evacuate: strange closure type 4689
(GHC version 8.4.3 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
fish: 'xmobar' terminated by signal SIGABRT (Abort)
```
2:
```
voronwe@sul ~> xmobar
Fields missing from config defaulted: additionalFonts,wmClass,wmName,border,borderColor,textOffset,iconOffset,iconRoot,alpha
fish: 'xmobar' terminated by signal SIGSEGV (Address boundary error)
```
See my issue on xmobar github for details: https://github.com/jaor/xmobar/issues/354
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| 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":"Xmobar crashes with segmentation fault","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"OS: Arch\r\nKernel version: 4.16.13-2-ARCH\r\nXmobar version: 0.26\r\nghc version: 8.4.3\r\n\r\nXmobar crashes after some time (1 sec or 1 day - very different each time).\r\nAnd, as I see, reasons are different to:\r\n\r\n1:\r\n{{{\r\nvoronwe@sul ~> xmobar \r\nFields missing from config defaulted: additionalFonts,wmClass,wmName,border,borderColor,textOffset,iconOffset,iconRoot,alpha\r\nxmobar: internal error: evacuate: strange closure type 4689\r\n (GHC version 8.4.3 for x86_64_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nfish: 'xmobar' terminated by signal SIGABRT (Abort)\r\n}}}\r\n\r\n2:\r\n{{{\r\nvoronwe@sul ~> xmobar \r\nFields missing from config defaulted: additionalFonts,wmClass,wmName,border,borderColor,textOffset,iconOffset,iconRoot,alpha\r\nfish: 'xmobar' terminated by signal SIGSEGV (Address boundary error)\r\n}}}\r\nSee my issue on xmobar github for details: https://github.com/jaor/xmobar/issues/354","type_of_failure":"OtherFailure","blocking":[]} -->8.4.4https://gitlab.haskell.org/ghc/ghc/-/issues/15256GHCi check .ghci permission on WSL(Linux on Windows)2019-07-07T18:13:36ZyongjoonGHCi check .ghci permission on WSL(Linux on Windows)GHCi permission checking for .ghci conflicts with WSL(Linux on Windows) filesystem management.
You can reproduce this problem from 8.2.2.\~8.4.3 of GHC-WSL(https://launchpad.net/\~hvr/+archive/ubuntu/ghc-wsl).
I think GHCi of WSL would ...GHCi permission checking for .ghci conflicts with WSL(Linux on Windows) filesystem management.
You can reproduce this problem from 8.2.2.\~8.4.3 of GHC-WSL(https://launchpad.net/\~hvr/+archive/ubuntu/ghc-wsl).
I think GHCi of WSL would skip .ghci permission check.
I used GHCi(WSL) on some Haskell project synced by cloud storage which is placed on Windows filesystem.
However, when I try to load GHCi with .ghci config file, GHCI says it can't pass .ghci permission check.
As you know, chmod on WSL may ignore your command about many of file on NTFS filesystem in WSL. WSL shows permission of some files on Windows filesystems like 777.
Therefore, I think GHCi(WSL) may have an exceptional code not to check .ghci file as like as ghci warning message for MinTTY console.
P.S.
Is there any bug-report place only for GHC-WSL? I couldn't find it.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi check .ghci permission on WSL(Linux on Windows)","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHCi permission checking for .ghci conflicts with WSL(Linux on Windows) filesystem management.\r\nYou can reproduce this problem from 8.2.2.~8.4.3 of GHC-WSL(https://launchpad.net/~hvr/+archive/ubuntu/ghc-wsl).\r\n\r\nI think GHCi of WSL would skip .ghci permission check.\r\n\r\nI used GHCi(WSL) on some Haskell project synced by cloud storage which is placed on Windows filesystem.\r\n\r\nHowever, when I try to load GHCi with .ghci config file, GHCI says it can't pass .ghci permission check.\r\nAs you know, chmod on WSL may ignore your command about many of file on NTFS filesystem in WSL. WSL shows permission of some files on Windows filesystems like 777.\r\n\r\nTherefore, I think GHCi(WSL) may have an exceptional code not to check .ghci file as like as ghci warning message for MinTTY console.\r\n\r\nP.S.\r\nIs there any bug-report place only for GHC-WSL? I couldn't find it.","type_of_failure":"OtherFailure","blocking":[]} -->8.4.4https://gitlab.haskell.org/ghc/ghc/-/issues/15199Build fails on Debian armhf (armv7l-unknown-linux-gnueabihf)2022-12-24T19:01:46ZclintBuild fails on Debian armhf (armv7l-unknown-linux-gnueabihf)```
"inplace/bin/ghc-stage1" -static -H32m -O -lffi -optl-pthread -optl-B/usr/bin/ld.gold -D__ARM_PCS_VFP -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/bu...```
"inplace/bin/ghc-stage1" -static -H32m -O -lffi -optl-pthread -optl-B/usr/bin/ld.gold -D__ARM_PCS_VFP -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 8.4.2 for arm-unknown-linux):
Failed to lookup the datalayout for armv7l-unknown-linux-gnueabihf; available targets: ["i386-unknown-windows","i686-unknown-windows","x86_64-unknown-windows","arm-unknown-linux-gnueabihf","armv6-unknown-linux-gnueabihf","armv7-unknown-linux-gnueabihf","aarch64-unknown-linux-gnu","aarch64-unknown-linux","armv7a-unknown-linux-gnueabi","i386-unknown-linux-gnu","i386-unknown-linux","x86_64-unknown-linux-gnu","x86_64-unknown-linux","armv7-unknown-linux-androideabi","aarch64-unknown-linux-android","arm-unknown-nto-qnx-eabi","i386-apple-darwin","x86_64-apple-darwin","armv7-apple-ios","aarch64-apple-ios","i386-apple-ios","x86_64-apple-ios"]
CallStack (from HasCallStack):
error, called at compiler/llvmGen/LlvmCodeGen.hs:96:24 in ghc:LlvmCodeGen
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
rts/ghc.mk:295: recipe for target 'rts/dist/build/StgStartup.o' failed
```
https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armhf&ver=8.4.2-1&stamp=1525310160&raw=0
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.4.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":"Build fails on Debian armhf (armv7l-unknown-linux-gnueabihf)","status":"New","operating_system":"Unknown/Multiple","component":"Compiler","related":[],"milestone":"8.4.4","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown/Multiple","cc":[""],"type":"Bug","description":"{{{\r\n\"inplace/bin/ghc-stage1\" -static -H32m -O -lffi -optl-pthread -optl-B/usr/bin/ld.gold -D__ARM_PCS_VFP -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o\r\nghc-stage1: panic! (the 'impossible' happened)\r\n (GHC version 8.4.2 for arm-unknown-linux):\r\n\tFailed to lookup the datalayout for armv7l-unknown-linux-gnueabihf; available targets: [\"i386-unknown-windows\",\"i686-unknown-windows\",\"x86_64-unknown-windows\",\"arm-unknown-linux-gnueabihf\",\"armv6-unknown-linux-gnueabihf\",\"armv7-unknown-linux-gnueabihf\",\"aarch64-unknown-linux-gnu\",\"aarch64-unknown-linux\",\"armv7a-unknown-linux-gnueabi\",\"i386-unknown-linux-gnu\",\"i386-unknown-linux\",\"x86_64-unknown-linux-gnu\",\"x86_64-unknown-linux\",\"armv7-unknown-linux-androideabi\",\"aarch64-unknown-linux-android\",\"arm-unknown-nto-qnx-eabi\",\"i386-apple-darwin\",\"x86_64-apple-darwin\",\"armv7-apple-ios\",\"aarch64-apple-ios\",\"i386-apple-ios\",\"x86_64-apple-ios\"]\r\nCallStack (from HasCallStack):\r\n error, called at compiler/llvmGen/LlvmCodeGen.hs:96:24 in ghc:LlvmCodeGen\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\nrts/ghc.mk:295: recipe for target 'rts/dist/build/StgStartup.o' failed\r\n}}}\r\n\r\nhttps://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armhf&ver=8.4.2-1&stamp=1525310160&raw=0","type_of_failure":"OtherFailure","blocking":[]} -->8.4.4https://gitlab.haskell.org/ghc/ghc/-/issues/15198`Language.Haskell.TH.Syntax.reify` returns * rather than Constraint2019-07-07T18:13:50Zbenzrf`Language.Haskell.TH.Syntax.reify` returns * rather than ConstraintThis module is sufficient to demonstrate the mistake:
```hs
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE TemplateHaskell #-}
module Bug where
import Data.Kind
import Data.Pro...This module is sufficient to demonstrate the mistake:
```hs
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE TemplateHaskell #-}
module Bug where
import Data.Kind
import Data.Proxy
import Language.Haskell.TH
foo :: forall (k :: Constraint). Proxy k
foo = Proxy
return [] -- delimit declaration groups
main :: IO ()
main = putStrLn $(do
VarI _ ty _ <- reify 'foo
let p = pprint ty
[| p |])
```
Running this in GHC 8.0.2 correctly prints out `forall (k_0 :: Constraint) . Data.Proxy.Proxy k_0`, but GHC 8.2.2 and 8.4.2 both print `forall (k_0 :: *) . Data.Proxy.Proxy k_0`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.4.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":"`Language.Haskell.TH.Syntax.reify` returns * rather than Constraint","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"8.4.4","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.2","keywords":["constraint","constraintkinds","reify"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This module is sufficient to demonstrate the mistake:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE ConstraintKinds #-}\r\n{-# LANGUAGE KindSignatures #-}\r\n{-# LANGUAGE RankNTypes #-}\r\n{-# LANGUAGE TemplateHaskell #-}\r\nmodule Bug where\r\n\r\nimport Data.Kind\r\nimport Data.Proxy\r\nimport Language.Haskell.TH\r\n\r\nfoo :: forall (k :: Constraint). Proxy k\r\nfoo = Proxy\r\n\r\nreturn [] -- delimit declaration groups\r\n\r\nmain :: IO ()\r\nmain = putStrLn $(do\r\n VarI _ ty _ <- reify 'foo\r\n let p = pprint ty\r\n [| p |])\r\n}}}\r\n\r\nRunning this in GHC 8.0.2 correctly prints out `forall (k_0 :: Constraint) . Data.Proxy.Proxy k_0`, but GHC 8.2.2 and 8.4.2 both print `forall (k_0 :: *) . Data.Proxy.Proxy k_0`.","type_of_failure":"OtherFailure","blocking":[]} -->8.4.4https://gitlab.haskell.org/ghc/ghc/-/issues/15163non coercion variable in coVarKindsTypesRole2019-07-07T18:13:58ZAlp Mestanogullarinon coercion variable in coVarKindsTypesRoleIt is triggered by T14732... in the `profasm` way, and only that one.
```sh
$ make fulltest TEST="T14732" THREADS=4
=====> T14732(profasm) 1 of 1 [0, 0, 0]
cd "./typecheck/should_compile/T14732.run" && "/home/alp/WT/ghc-slow-validate/i...It is triggered by T14732... in the `profasm` way, and only that one.
```sh
$ make fulltest TEST="T14732" THREADS=4
=====> T14732(profasm) 1 of 1 [0, 0, 0]
cd "./typecheck/should_compile/T14732.run" && "/home/alp/WT/ghc-slow-validate/inplace/test spaces/ghc-stage2" -c T14732.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -fno-warn-incomplete-patterns -O -prof -static -fprof-auto
Compile failed (exit code 1) errors were:
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.5.20180511 for x86_64-unknown-linux):
coVarKindsTypesRole, non coercion variable
as_atY
Vector a_a2sO
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1162:37 in ghc:Outputable
pprPanic, called at compiler/types/Coercion.hs:376:16 in ghc:Coercion
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
*** unexpected failure for T14732(profasm)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.5 |
| 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":"non coercion variable in coVarKindsTypesRole","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"It is triggered by T14732... in the `profasm` way, and only that one.\r\n\r\n{{{#!sh\r\n$ make fulltest TEST=\"T14732\" THREADS=4\r\n=====> T14732(profasm) 1 of 1 [0, 0, 0]\r\ncd \"./typecheck/should_compile/T14732.run\" && \"/home/alp/WT/ghc-slow-validate/inplace/test spaces/ghc-stage2\" -c T14732.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -fno-warn-incomplete-patterns -O -prof -static -fprof-auto \r\nCompile failed (exit code 1) errors were:\r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 8.5.20180511 for x86_64-unknown-linux):\r\n\tcoVarKindsTypesRole, non coercion variable\r\n as_atY\r\n Vector a_a2sO\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler/utils/Outputable.hs:1162:37 in ghc:Outputable\r\n pprPanic, called at compiler/types/Coercion.hs:376:16 in ghc:Coercion\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n\r\n*** unexpected failure for T14732(profasm)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.4.4https://gitlab.haskell.org/ghc/ghc/-/issues/14381Consider making ghc-pkg fill in abi-depends based on depends2019-07-07T18:17:14ZEdward Z. YangConsider making ghc-pkg fill in abi-depends based on dependsIn GHC 8.2, we introduced `abi-depends` to solve #12485. Following the same pattern as all ghc-pkg fields, this field is to be fllled by whoever is performing the registration.
I now suspect designing it this way was a mistake. In https...In GHC 8.2, we introduced `abi-depends` to solve #12485. Following the same pattern as all ghc-pkg fields, this field is to be fllled by whoever is performing the registration.
I now suspect designing it this way was a mistake. In https://github.com/haskell/cabal/issues/4728 we have a bug where Cabal is writing nonsense data for `abi-depends`, `ghc-pkg` isn't noticing it, and GHC is rejecting the package (with a "shadow" warning) when it gets to the end. The problem is the Cabal aggressively caches the contents of the package database (ostensibly because it is expensive to query `ghc-pkg`); this means that it is easy to get into a situation where its understanding of the ABIs of its dependencies is out-of-date (because it is not re-reading the database in order to get newer information).
The insult to the injury is, in most cases, ghc-pkg already knows what the ABIs are supposed to be: they're whatever the ABIs of the packages pointed at by 'depends' already in the database are. So ghc-pkg could have computed the abi dependency itself, and prevented this stale data situation from ever happening. This sounds quite attractive to me.
What do people think? Here is one possible proposal (but it is just one in the space):
- `ghc-pkg` will be modified to ignore the `abi-depends` field (perhaps with a warning), to prevent itself from being poisoned by buggy versions of Cabal which are giving bad ABI information
- Instead, `ghc-pkg` generates the `abi-depends` field by looking up dependency IDs from the database. If an ID is not found, it omits the dep from `abi-depends` (this is equivalent to suspending ABI checking in GHC, so this won't break anything; it will just make ABI checking less robust)
- Possibly, introduce a new "virtual" field, which can be used to override `ghc-pkg` default
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | ghc-pkg |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Consider making ghc-pkg fill in abi-depends based on depends","status":"New","operating_system":"","component":"ghc-pkg","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In GHC 8.2, we introduced `abi-depends` to solve #12485. Following the same pattern as all ghc-pkg fields, this field is to be fllled by whoever is performing the registration.\r\n\r\nI now suspect designing it this way was a mistake. In https://github.com/haskell/cabal/issues/4728 we have a bug where Cabal is writing nonsense data for `abi-depends`, `ghc-pkg` isn't noticing it, and GHC is rejecting the package (with a \"shadow\" warning) when it gets to the end. The problem is the Cabal aggressively caches the contents of the package database (ostensibly because it is expensive to query `ghc-pkg`); this means that it is easy to get into a situation where its understanding of the ABIs of its dependencies is out-of-date (because it is not re-reading the database in order to get newer information).\r\n\r\nThe insult to the injury is, in most cases, ghc-pkg already knows what the ABIs are supposed to be: they're whatever the ABIs of the packages pointed at by 'depends' already in the database are. So ghc-pkg could have computed the abi dependency itself, and prevented this stale data situation from ever happening. This sounds quite attractive to me.\r\n\r\nWhat do people think? Here is one possible proposal (but it is just one in the space):\r\n\r\n* `ghc-pkg` will be modified to ignore the `abi-depends` field (perhaps with a warning), to prevent itself from being poisoned by buggy versions of Cabal which are giving bad ABI information\r\n\r\n* Instead, `ghc-pkg` generates the `abi-depends` field by looking up dependency IDs from the database. If an ID is not found, it omits the dep from `abi-depends` (this is equivalent to suspending ABI checking in GHC, so this won't break anything; it will just make ABI checking less robust)\r\n\r\n* Possibly, introduce a new \"virtual\" field, which can be used to override `ghc-pkg` default","type_of_failure":"OtherFailure","blocking":[]} -->8.4.4Tobias Dammerstdammers@gmail.comTobias Dammerstdammers@gmail.com