GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2023-04-04T08:09:40Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/20253Hadrian binary distributions ship `settings`2023-04-04T08:09:40ZBen GamariHadrian binary distributions ship `settings`The binary distributions produced by Hadrian do not make any attempt to generate the `settings` file from the information about the host deduced by the bindist `configure` script. This is wrong. In particular, this was noticed on an olde...The binary distributions produced by Hadrian do not make any attempt to generate the `settings` file from the information about the host deduced by the bindist `configure` script. This is wrong. In particular, this was noticed on an older Darwin machine where the build environment's `cc` supported `-no-pie` but the installation host did not. Consequently, the installed compiler attempted to use `-no-pie` and was broken.9.2.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/13354Package database locking patch broke ghc-pkg with non-existent database2019-07-07T18:22:18ZBen GamariPackage database locking patch broke ghc-pkg with non-existent databaseIt seems that [D3090](https://phabricator.haskell.org/D3090) (#13194) broke `ghc-pkg`'s behavior in the face of non-existent package databases. Namely, `cabal install` fails during registration with,
```
Creating package registration fi...It seems that [D3090](https://phabricator.haskell.org/D3090) (#13194) broke `ghc-pkg`'s behavior in the face of non-existent package databases. Namely, `cabal install` fails during registration with,
```
Creating package registration file: /tmp/pkgConf-compact-0.1.0.1-13684/pkgConf
("/opt/exp/ghc/roots/master/bin/ghc-pkg",["update","-","--global","--user","-v2"])
/opt/exp/ghc/roots/master/bin/ghc-pkg returned ExitFailure 1 with error
message:
ghc-pkg: Couldn't open database
/home/ben/.ghc/x86_64-linux-8.1.20170227/package.conf.d for modification:
/home/ben/.ghc/x86_64-linux-8.1.20170227/package.conf.d.lock: openBinaryFile:
does not exist (No such file or directory)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Package database locking patch broke ghc-pkg with non-existent database","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"It seems that Phab:D3090 (#13194) broke `ghc-pkg`'s behavior in the face of non-existent package databases. Namely, `cabal install` fails during registration with,\r\n{{{\r\nCreating package registration file: /tmp/pkgConf-compact-0.1.0.1-13684/pkgConf\r\n(\"/opt/exp/ghc/roots/master/bin/ghc-pkg\",[\"update\",\"-\",\"--global\",\"--user\",\"-v2\"])\r\n/opt/exp/ghc/roots/master/bin/ghc-pkg returned ExitFailure 1 with error\r\nmessage:\r\nghc-pkg: Couldn't open database\r\n/home/ben/.ghc/x86_64-linux-8.1.20170227/package.conf.d for modification:\r\n/home/ben/.ghc/x86_64-linux-8.1.20170227/package.conf.d.lock: openBinaryFile:\r\ndoes not exist (No such file or directory)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/11558Using Cabal 1.22 against GHC 8.0 results in unhelpful errors2019-07-07T18:29:49ZBen GamariUsing Cabal 1.22 against GHC 8.0 results in unhelpful errorsGHC 8.0 will require Cabal \>1.22 due to a variety of interface changes (see #10714, [D1780](https://phabricator.haskell.org/D1780), https://mail.haskell.org/pipermail/ghc-devs/2016-January/010978.html). Unfortunately things currently bl...GHC 8.0 will require Cabal \>1.22 due to a variety of interface changes (see #10714, [D1780](https://phabricator.haskell.org/D1780), https://mail.haskell.org/pipermail/ghc-devs/2016-January/010978.html). Unfortunately things currently blow up late in compilation with a seemingly unrelated error when this requirement isn't met. Namely, we complain about bad interface files for dependencies. For instance,
```
Text/Parsec/Prim.hs:85:1: error:
Bad interface file: /root/.cabal/lib/x86_64-linux-ghc-8.0.0.20160204/mtl-2.2.1-9wMhzcfsAXi7cNtl9n7svO/Control/Monad/Cont/Class.hi
Something is amiss; requested module mtl-2.2.1@mtl-2.2.1-1af5dabd2d7abb688f2145aec87badc4:Control.Monad.Cont.Class differs from name found in the interface file mtl_9wMhzcfsAXi7cNtl9n7svO:Control.Monad.Cont.Class
```
# For users seeing this error
The solution here is to install `Cabal` 1.23 or later and a `cabal-install` linking against it. Currently this requires installing `Cabal` and `cabal-install` from git. This is most easily done using GHC 7.10. Finally, you need to clear your package database.
This can be done with,
```
$ git clone git://github.com/haskell/cabal
$ cd cabal
$ cabal update
$ cabal install Cabal/ cabal-install/
$ rm -R $HOME/.ghc/*-8.0.0*
```8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/10099cabal install broken with ghc 7.10.1-rc22019-07-07T18:37:30ZPeter Trommlerptrommler@acm.orgcabal install broken with ghc 7.10.1-rc2Trying to install a package with cabal-install and Cabal from ghc 7.10-rc2
consistently gives this error message (`primitive` is just an example):
```
peter@montebre:~> cabal install primitive
Resolving dependencies...
Configuring primi...Trying to install a package with cabal-install and Cabal from ghc 7.10-rc2
consistently gives this error message (`primitive` is just an example):
```
peter@montebre:~> cabal install primitive
Resolving dependencies...
Configuring primitive-0.5.4.0...
cabal: Distribution/Client/Config.hs:(246,37)-(299,9): Missing field in record construction configProf
```
This is my package database:
```
peter@montebre:~> ghc-pkg list
/usr/lib64/ghc-7.10.0.20150123/package.conf.d
Cabal-1.22.1.0
HTTP-4000.2.19
array-0.5.0.1
base-4.8.0.0
bin-package-db-0.0.0.0
binary-0.7.3.0
bytestring-0.10.6.0
containers-0.5.6.2
deepseq-1.4.0.0
directory-1.2.2.0
filepath-1.3.1.0
ghc-7.10.0.20150123
ghc-prim-0.3.1.0
haskeline-0.7.2.0
hoopl-3.10.0.2
hpc-0.6.0.2
integer-gmp-1.0.0.0
mtl-2.2.1
network-2.4.2.3
old-locale-1.0.0.7
old-time-1.1.0.3
parsec-3.1.8
pretty-1.1.2.0
process-1.2.2.0
random-1.0.1.1
rts-1.0
stm-2.4.2
syb-0.4.4
template-haskell-2.10.0.0
terminfo-0.4.0.1
text-1.2.0.4
th-desugar-1.5
th-lift-0.7
time-1.5.0.1
transformers-0.4.2.0
unix-2.7.1.0
xhtml-3000.2.1
zlib-0.5.4.2
```
I updated only those packages (from their versions in Haskell Platform) that would not compile with 7.101-rc2.
I am setting this to highest as this issue would be very annoying for everyone.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"cabal install broken with ghc 7.10.1-rc2","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Trying to install a package with cabal-install and Cabal from ghc 7.10-rc2\r\nconsistently gives this error message (`primitive` is just an example):\r\n{{{\r\npeter@montebre:~> cabal install primitive\r\nResolving dependencies...\r\nConfiguring primitive-0.5.4.0...\r\ncabal: Distribution/Client/Config.hs:(246,37)-(299,9): Missing field in record construction configProf\r\n}}}\r\n\r\nThis is my package database:\r\n{{{\r\npeter@montebre:~> ghc-pkg list\r\n/usr/lib64/ghc-7.10.0.20150123/package.conf.d\r\n Cabal-1.22.1.0\r\n HTTP-4000.2.19\r\n array-0.5.0.1\r\n base-4.8.0.0\r\n bin-package-db-0.0.0.0\r\n binary-0.7.3.0\r\n bytestring-0.10.6.0\r\n containers-0.5.6.2\r\n deepseq-1.4.0.0\r\n directory-1.2.2.0\r\n filepath-1.3.1.0\r\n ghc-7.10.0.20150123\r\n ghc-prim-0.3.1.0\r\n haskeline-0.7.2.0\r\n hoopl-3.10.0.2\r\n hpc-0.6.0.2\r\n integer-gmp-1.0.0.0\r\n mtl-2.2.1\r\n network-2.4.2.3\r\n old-locale-1.0.0.7\r\n old-time-1.1.0.3\r\n parsec-3.1.8\r\n pretty-1.1.2.0\r\n process-1.2.2.0\r\n random-1.0.1.1\r\n rts-1.0\r\n stm-2.4.2\r\n syb-0.4.4\r\n template-haskell-2.10.0.0\r\n terminfo-0.4.0.1\r\n text-1.2.0.4\r\n th-desugar-1.5\r\n th-lift-0.7\r\n time-1.5.0.1\r\n transformers-0.4.2.0\r\n unix-2.7.1.0\r\n xhtml-3000.2.1\r\n zlib-0.5.4.2\r\n}}}\r\nI updated only those packages (from their versions in Haskell Platform) that would not compile with 7.101-rc2.\r\n\r\nI am setting this to highest as this issue would be very annoying for everyone.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/5754Cabal cannot register a package in a directory with Unicode chars2019-07-07T18:53:44ZSimon MarlowCabal cannot register a package in a directory with Unicode charsWhile fixing #5697, I tried building and registering a package in a directory with Unicode chars, and cabal-install fails to register it.
This appears to be a regression since 7.0, as it first fails with 7.2 and is still failing in 7.4....While fixing #5697, I tried building and registering a package in a directory with Unicode chars, and cabal-install fails to register it.
This appears to be a regression since 7.0, as it first fails with 7.2 and is still failing in 7.4.
I'm not sure who's fault this is, but since it is GHC-version dependent it could well be ours.
```
c:\simonmar\scratch\áéóíúúíáλ>cabal register --inplace -v
c:\simonmar\ghc-validate\inplace\bin\ghc-stage2.exe --abi-hash -package-name par
allel-3.2.0.0 -hide-all-packages -fbuilding-cabal-package -i -idist\build -i. -i
dist\build\autogen -Idist\build\autogen -Idist\build -optP-include -optPdist\bui
ld\autogen\cabal_macros.h -odir dist\build -hidir dist\build -stubdir dist\build
-package-id array-0.3.0.3-inplace -package-id base-4.4.0.0-inplace -package-id
containers-0.4.2.0-inplace -package-id deepseq-1.2.0.1-inplace -O -feager-blackh
oling -Wall -XCPP -XBangPatterns Control.Seq Control.Parallel Control.Parallel.S
trategies
Registering parallel-3.2.0.0...
c:\simonmar\ghc-validate\inplace\bin\ghc-pkg.exe update - --global --user
cabal: fd:5: hGetContents: invalid argument (invalid UTF-8 byte sequence)
cabal: fd:5: invalid argument
```
I tried with cabal-install 0.8 and 0.10:
```
c:\simonmar\scratch\áéóíúúíáλ>cabal --version
cabal-install version 0.10.2
using version 1.10.2.0 of the Cabal library
c:\simonmar\scratch\áéóíúúíáλ>cabal +RTS --info
[("GHC RTS", "YES")
,("GHC version", "7.0.4")
,("RTS way", "rts_v")
,("Build platform", "i386-unknown-mingw32")
,("Build architecture", "i386")
,("Build OS", "mingw32")
,("Build vendor", "unknown")
,("Host platform", "i386-unknown-mingw32")
,("Host architecture", "i386")
,("Host OS", "mingw32")
,("Host vendor", "unknown")
,("Target platform", "i386-unknown-mingw32")
,("Target architecture", "i386")
,("Target OS", "mingw32")
,("Target vendor", "unknown")
,("Word size", "32")
,("Compiler unregisterised", "NO")
,("Tables next to code", "YES")
]
```
I haven't tried building cabal-install with 7.2 yet.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | duncan |
| Operating system | Unknown/Multiple |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Cabal cannot register a package in a directory with Unicode chars","status":"New","operating_system":"Unknown/Multiple","component":"Package system","related":[],"milestone":"7.4.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["duncan"],"type":"Bug","description":"While fixing #5697, I tried building and registering a package in a directory with Unicode chars, and cabal-install fails to register it.\r\n\r\nThis appears to be a regression since 7.0, as it first fails with 7.2 and is still failing in 7.4.\r\n\r\nI'm not sure who's fault this is, but since it is GHC-version dependent it could well be ours.\r\n\r\n{{{\r\nc:\\simonmar\\scratch\\áéóíúúíáλ>cabal register --inplace -v\r\nc:\\simonmar\\ghc-validate\\inplace\\bin\\ghc-stage2.exe --abi-hash -package-name par\r\nallel-3.2.0.0 -hide-all-packages -fbuilding-cabal-package -i -idist\\build -i. -i\r\ndist\\build\\autogen -Idist\\build\\autogen -Idist\\build -optP-include -optPdist\\bui\r\nld\\autogen\\cabal_macros.h -odir dist\\build -hidir dist\\build -stubdir dist\\build\r\n -package-id array-0.3.0.3-inplace -package-id base-4.4.0.0-inplace -package-id\r\ncontainers-0.4.2.0-inplace -package-id deepseq-1.2.0.1-inplace -O -feager-blackh\r\noling -Wall -XCPP -XBangPatterns Control.Seq Control.Parallel Control.Parallel.S\r\ntrategies\r\nRegistering parallel-3.2.0.0...\r\nc:\\simonmar\\ghc-validate\\inplace\\bin\\ghc-pkg.exe update - --global --user\r\ncabal: fd:5: hGetContents: invalid argument (invalid UTF-8 byte sequence)\r\ncabal: fd:5: invalid argument\r\n}}}\r\n\r\nI tried with cabal-install 0.8 and 0.10:\r\n\r\n{{{\r\nc:\\simonmar\\scratch\\áéóíúúíáλ>cabal --version\r\ncabal-install version 0.10.2\r\nusing version 1.10.2.0 of the Cabal library\r\n\r\nc:\\simonmar\\scratch\\áéóíúúíáλ>cabal +RTS --info\r\n [(\"GHC RTS\", \"YES\")\r\n ,(\"GHC version\", \"7.0.4\")\r\n ,(\"RTS way\", \"rts_v\")\r\n ,(\"Build platform\", \"i386-unknown-mingw32\")\r\n ,(\"Build architecture\", \"i386\")\r\n ,(\"Build OS\", \"mingw32\")\r\n ,(\"Build vendor\", \"unknown\")\r\n ,(\"Host platform\", \"i386-unknown-mingw32\")\r\n ,(\"Host architecture\", \"i386\")\r\n ,(\"Host OS\", \"mingw32\")\r\n ,(\"Host vendor\", \"unknown\")\r\n ,(\"Target platform\", \"i386-unknown-mingw32\")\r\n ,(\"Target architecture\", \"i386\")\r\n ,(\"Target OS\", \"mingw32\")\r\n ,(\"Target vendor\", \"unknown\")\r\n ,(\"Word size\", \"32\")\r\n ,(\"Compiler unregisterised\", \"NO\")\r\n ,(\"Tables next to code\", \"YES\")\r\n ]\r\n}}}\r\n\r\nI haven't tried building cabal-install with 7.2 yet.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/4843"include" directory missing in the ghc 7.0.1 windows installer2019-07-07T18:58:15Znsch"include" directory missing in the ghc 7.0.1 windows installerThe current windows installer from http://www.haskell.org/ghc/download_ghc_7_0_1\#windows is missing the "include" directory in its root directory.
For example this build fails because it cannot find **HsFFI.h**, which is located in `C:...The current windows installer from http://www.haskell.org/ghc/download_ghc_7_0_1\#windows is missing the "include" directory in its root directory.
For example this build fails because it cannot find **HsFFI.h**, which is located in `C:\Haskell\ghc-7.0.1\lib\include` and not in `C:\\Haskell\\ghc-7.0.1/include`, where GHC is looking for it:
```
configure: creating ./config.status
config.status: creating include/HsDirectoryConfig.h
config.status: include/HsDirectoryConfig.h is unchanged
("C:\\Haskell\\ghc-7.0.1\\mingw\\bin\\gcc.exe",["C:\\Users\\Nils\\AppData\\Local\\Temp\\3048.c","-o","C:\\Users\\Nils\\AppData\\Local\\Temp\
\3048","-D__GLASGOW_HASKELL__=700","-Iinclude","-I.","-IC:\\Haskell\\ghc-7.0.1\\old-time-1.0.0.6\\include","-IC:\\Haskell\\ghc-7.0.1\\Win32-
2.2.0.1\\include","-IC:\\Haskell\\ghc-7.0.1\\bytestring-0.9.1.8\\include","-IC:\\Haskell\\ghc-7.0.1\\base-4.3.0.0\\include","-IC:\\Haskell\\
ghc-7.0.1/include","-IC:\\Haskell\\ghc-7.0.1/include","-LC:\\Haskell\\ghc-7.0.1\\old-time-1.0.0.6","-LC:\\Haskell\\ghc-7.0.1\\old-locale-1.0
.0.2","-LC:\\Haskell\\ghc-7.0.1\\filepath-1.2.0.0","-LC:\\Haskell\\ghc-7.0.1\\Win32-2.2.0.1","-LC:\\Haskell\\ghc-7.0.1\\bytestring-0.9.1.8",
"-LC:\\Haskell\\ghc-7.0.1\\base-4.3.0.0","-LC:\\Haskell\\ghc-7.0.1\\integer-gmp-0.2.0.2","-LC:\\Haskell\\ghc-7.0.1\\ghc-prim-0.2.0.0","-LC:\
\Haskell\\ghc-7.0.1","-LC:\\Haskell\\ghc-7.0.1"])
C:\Haskell\ghc-7.0.1\mingw\bin\gcc.exe returned ExitFailure 1 with error
message:
In file included from C:\Users\Nils\AppData\Local\Temp\3048.c:1:0:
include/HsDirectory.h:19:19: fatal error: HsFFI.h: No such file or directory
compilation terminated.
```
You have to pass `--extra-include-dirs=C:/Haskell/ghc-7.0.1/lib/include` to get it to compile.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"\"include\" directory missing in the ghc 7.0.1 windows installer","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The current windows installer from http://www.haskell.org/ghc/download_ghc_7_0_1#windows is missing the \"include\" directory in its root directory.\r\n\r\nFor example this build fails because it cannot find '''HsFFI.h''', which is located in `C:\\Haskell\\ghc-7.0.1\\lib\\include` and not in `C:\\\\Haskell\\\\ghc-7.0.1/include`, where GHC is looking for it:\r\n\r\n{{{\r\nconfigure: creating ./config.status\r\nconfig.status: creating include/HsDirectoryConfig.h\r\nconfig.status: include/HsDirectoryConfig.h is unchanged\r\n(\"C:\\\\Haskell\\\\ghc-7.0.1\\\\mingw\\\\bin\\\\gcc.exe\",[\"C:\\\\Users\\\\Nils\\\\AppData\\\\Local\\\\Temp\\\\3048.c\",\"-o\",\"C:\\\\Users\\\\Nils\\\\AppData\\\\Local\\\\Temp\\\r\n\\3048\",\"-D__GLASGOW_HASKELL__=700\",\"-Iinclude\",\"-I.\",\"-IC:\\\\Haskell\\\\ghc-7.0.1\\\\old-time-1.0.0.6\\\\include\",\"-IC:\\\\Haskell\\\\ghc-7.0.1\\\\Win32-\r\n2.2.0.1\\\\include\",\"-IC:\\\\Haskell\\\\ghc-7.0.1\\\\bytestring-0.9.1.8\\\\include\",\"-IC:\\\\Haskell\\\\ghc-7.0.1\\\\base-4.3.0.0\\\\include\",\"-IC:\\\\Haskell\\\\\r\nghc-7.0.1/include\",\"-IC:\\\\Haskell\\\\ghc-7.0.1/include\",\"-LC:\\\\Haskell\\\\ghc-7.0.1\\\\old-time-1.0.0.6\",\"-LC:\\\\Haskell\\\\ghc-7.0.1\\\\old-locale-1.0\r\n.0.2\",\"-LC:\\\\Haskell\\\\ghc-7.0.1\\\\filepath-1.2.0.0\",\"-LC:\\\\Haskell\\\\ghc-7.0.1\\\\Win32-2.2.0.1\",\"-LC:\\\\Haskell\\\\ghc-7.0.1\\\\bytestring-0.9.1.8\",\r\n\"-LC:\\\\Haskell\\\\ghc-7.0.1\\\\base-4.3.0.0\",\"-LC:\\\\Haskell\\\\ghc-7.0.1\\\\integer-gmp-0.2.0.2\",\"-LC:\\\\Haskell\\\\ghc-7.0.1\\\\ghc-prim-0.2.0.0\",\"-LC:\\\r\n\\Haskell\\\\ghc-7.0.1\",\"-LC:\\\\Haskell\\\\ghc-7.0.1\"])\r\nC:\\Haskell\\ghc-7.0.1\\mingw\\bin\\gcc.exe returned ExitFailure 1 with error\r\nmessage:\r\nIn file included from C:\\Users\\Nils\\AppData\\Local\\Temp\\3048.c:1:0:\r\ninclude/HsDirectory.h:19:19: fatal error: HsFFI.h: No such file or directory\r\ncompilation terminated.\r\n}}}\r\n\r\nYou have to pass `--extra-include-dirs=C:/Haskell/ghc-7.0.1/lib/include` to get it to compile.","type_of_failure":"OtherFailure","blocking":[]} -->7.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/22333GHC 9.4.2/Cabal 3.8.1.0: `PackageImports` with `reexported-modules`, problem2022-12-15T18:48:30ZMike PilgremGHC 9.4.2/Cabal 3.8.1.0: `PackageImports` with `reexported-modules`, problem## Summary
I have reported the same [issue](https://github.com/haskell/cabal/issues/8548) in the repository of Cabal (the library) and it has been suggested there that it may be a bug in GHC 9.4.2. The problem has been reproduced with S...## Summary
I have reported the same [issue](https://github.com/haskell/cabal/issues/8548) in the repository of Cabal (the library) and it has been suggested there that it may be a bug in GHC 9.4.2. The problem has been reproduced with Stack and Cabal (the tool). The problem is most easily described by the steps to produce it, below.
## Steps to reproduce
I have a library in package `my-package-B` which exposes module `LibB`. I have a library in package `my-package-A` which `build-depends` on `my-package-B` and has `reexported-modules` `LibB`.
Finally, I have an executable in package `my-package-C` which `build-depends` on `my-package-A` (only), and has `Main.hs`:
~~~haskell
{-# LANGUAGE PackageImports #-}
module Main (main) where
import "my-package-A" LibB (someFuncB)
main :: IO ()
main = print someFuncB
~~~
With `stack --resolver ghc-9.2.4 build`, it all builds as expected.
However, with `stack --resolver ghc-9.4.2 build`, and all else equal, the build fails with Cabal message:
~~~text
my-package-C> app\Main.hs:6:1: error:
my-package-C> Could not find module ‘LibB’
my-package-C> Perhaps you meant
my-package-C> LibB (from my-package-A-0.1.0.0, reexporting LibB)
my-package-C> LibA (from my-package-A-0.1.0.0)
my-package-C> |
my-package-C> 6 | import "my-package-A" LibB (someFuncB)
my-package-C> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
~~~
I can't make sense of the error message. I've requested `LibB` be imported from package `my-package-A` and I'm told it can't be found but perhaps I mean `LibB` reexported by `my-package-A`?
However, if I change (only) `Main.hs` to (no package-qualified import):
~~~haskell
module Main (main) where
import LibB (someFuncB)
main :: IO ()
main = print someFuncB
~~~
`stack --resolver ghc-9.4.2 build` now works! That is why I think it is a bug.
## Environment
* GHC 9.4.2
* Windows 11
* x86_649.4.4Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/21931v3.8.1.0 checkout of cabal supports GHC 9.4 and is ready for assimilation int...2022-08-31T22:27:23ZMikolaj Konarskiv3.8.1.0 checkout of cabal supports GHC 9.4 and is ready for assimilation into GHC (or if it's not, we'd love your feedback)The tag is https://github.com/haskell/cabal/tree/Cabal-v3.8.1.0.
Contact point is Mikolaj Konarski, but feel free to also open tickets in the cabal repo.
The actual cabal release is planned in a week or two, after some more of (yours, ...The tag is https://github.com/haskell/cabal/tree/Cabal-v3.8.1.0.
Contact point is Mikolaj Konarski, but feel free to also open tickets in the cabal repo.
The actual cabal release is planned in a week or two, after some more of (yours, among others) feedback. Either exactly the tag is going to be released or, if changes are needed, a new tag, e.g., 3.8.2.0. Current hackage candidates are at https://hackage.haskell.org/package/Cabal-3.8.1.0/candidate https://hackage.haskell.org/package/Cabal-syntax-3.8.1.0/candidate https://hackage.haskell.org/package/cabal-install-3.8.1.0/candidate https://hackage.haskell.org/package/cabal-install-solver-3.8.1.0/candidate9.4.1Douglas Wilsondouglas@well-typed.comDouglas Wilsondouglas@well-typed.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/19650ghci readily resets package state2021-12-14T15:49:44ZNeil Mitchellghci readily resets package state## Summary
Using GHC 9.0.1 and Cabal 3.4.0.0, a lot of "changes" will cause GHC to forget which modules were loaded in ghci. With GHC 8.10 it was a lot more robust. The frequent loss of loaded modules means tools like `ghcid` are a lot ...## Summary
Using GHC 9.0.1 and Cabal 3.4.0.0, a lot of "changes" will cause GHC to forget which modules were loaded in ghci. With GHC 8.10 it was a lot more robust. The frequent loss of loaded modules means tools like `ghcid` are a lot less useful.
## Steps to reproduce
```
$ cabal init
$ cabal repl
```
Now create an empty file `Foo.hs`, and a file `.ghci` with the contents:
```
:load Foo.hs
:set -DMAGIC
```
Using GHC 8.10.3, running `cabal exec ghci` leaves me with a GHCi session with `Foo.hs` loaded. However, with GHC 9.0.1:
```
C:\Neil\temp\ghci-bug>cabal exec ghci
Warning: The package list for 'hackage.haskell.org' is 22 days old.
Run 'cabal update' to get the latest list of available packages.
Resolving dependencies...
Loaded package environment from C:\Neil\temp\ghci-bug\dist-newstyle\tmp\environment.-11172\.ghc.environment.x86_64-mingw32-9.0.1
GHCi, version 9.0.1: https://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( Foo.hs, interpreted )
Ok, one module loaded.
Loaded package environment from C:\Neil\temp\ghci-bug\dist-newstyle\tmp\environment.-11172\.ghc.environment.x86_64-mingw32-9.0.1
Loaded package environment from C:\Neil\temp\ghci-bug\dist-newstyle\tmp\environment.-11172\.ghc.environment.x86_64-mingw32-9.0.1
package flags have changed, resetting and loading new packages...
Loaded GHCi configuration from C:\Neil\temp\ghci-bug\.ghci
ghci> :show modules
ghci>
```
So something about the environment changed, so it threw away all my loaded modules. In practice, a lot of things seem to make the environment change - turning on/off exceptions on breakpoints does it too. This makes `ghci` a whole lot less useful.
Using `ghci` alone it doesn't seem to reset the modules. However, in practice, using `ghci` alone is now very difficult as it no longer allows global installs. There are also magic environment files which are hard to avoid, so alas, this bug report is in the intersection - but given keeping Cabal constant and changing GHC causes the bug, reporting for GHC 9.0.1.
## Expected behavior
Don't throw away the loaded modules so freely.
## Environment
* GHC version used: GHC 9.0.1
* Operating System: Windows
* System Architecture: x86_649.0.2Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/18070GHC 8.10's API can load interfaces with the wrong package identifier when loo...2020-08-13T22:22:56ZquasicomputationalGHC 8.10's API can load interfaces with the wrong package identifier when looking for pluginsOriginally a doctest bug report: https://github.com/sol/doctest/issues/264
I inlined the relevant code from doctest into the provided reproducer, producing [this reduced reproducer](https://github.com/quasicomputational/test-doctest). R...Originally a doctest bug report: https://github.com/sol/doctest/issues/264
I inlined the relevant code from doctest into the provided reproducer, producing [this reduced reproducer](https://github.com/quasicomputational/test-doctest). Run with `./run-test.sh`.
On my machine, I get an error that looks like this:
```
test-doctest: Bad interface file: [..]/dist-newstyle/build/x86_64-linux/ghc-8.10.1/dummy-plugin-0.1.0.0/build/DummyDefs.hi
Something is amiss; requested module dummy-plugin-0.1.0.0:DummyDefs differs from name found in the interface file ghc-compact-0.1.0.0:DummyDefs (if these names look the same, try again with -dppr-debug)
```
Where does that `ghc-compact` come from? I have no idea. Even more puzzlingly, if I turn up GHC's verbosity, that turns into `process`!
[`test-doctest.hs`](https://github.com/quasicomputational/test-doctest/blob/master/test-doctest.hs) is the (now misleadingly-named) code driving GHC, and as far as I can tell it's not doing anything exotic or bizarre.
[`Haddock.Interface`](https://github.com/haskell/haddock/blob/8c6532636e6bd572455dfcf0b0d6e05f7033d110/haddock-api/src/Haddock/Interface.hs) is the roughly corresponding code in Haddock, which seems to mostly do the same thing - and yet Haddock works and doctest doesn't. I have no idea what the difference is, except that it might be something to do with order-sensitivity in how modules are loaded.
The error doesn't happen on GHC 8.8. I couldn't find anything in the release notes warning me about any changes here, so this is a regression.https://gitlab.haskell.org/ghc/ghc/-/issues/17467Hadrian does not track package.conf.d/package.cache2022-08-06T18:35:03ZAlp MestanogullariHadrian does not track package.conf.d/package.cacheWhile @nh2 and @bgamari were discussing a problem, they ended up realizing that deleting `_build/stage0/lib/package.conf.d/package.cache` and issuing a hadrian command to rebuild it and resume the build where it was previously failing re...While @nh2 and @bgamari were discussing a problem, they ended up realizing that deleting `_build/stage0/lib/package.conf.d/package.cache` and issuing a hadrian command to rebuild it and resume the build where it was previously failing results in:
```
ghc: there is no package.cache in _build/stage0/lib/package.conf.d even though package database is not empty
```
It's probably safe to assume that Hadrian does not track the package db cache in any way (not even using `traceWrite` or anything like that). It'd be nice to teach Hadrian enough about those caches for it to be able to regenerate them when needed.9.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/14297make bindist packages the wrong binaries for cross compilers2021-07-21T08:18:04ZMoritz Angermannmake bindist packages the wrong binaries for cross compilersWhen building binary distributions via `make binary-dist`, the resulting binaries in the package end up being compiled for the target instead of the host when cross compiling.
E.g. building a cross compiler for iOS on macOS yields:
```...When building binary distributions via `make binary-dist`, the resulting binaries in the package end up being compiled for the target instead of the host when cross compiling.
E.g. building a cross compiler for iOS on macOS yields:
```
./inplace/bin/ghc-cabal: Mach-O 64-bit executable x86_64
./utils/ghc-cabal/dist/build/tmp/ghc-cabal: Mach-O 64-bit executable x86_64
./utils/ghc-cabal/dist-install/build/tmp/ghc-cabal: Mach-O 64-bit executable arm64
./inplace/lib/bin/hsc2hs: Mach-O 64-bit executable x86_64
./utils/hsc2hs/dist/build/tmp/hsc2hs: Mach-O 64-bit executable x86_64
./utils/hsc2hs/dist-install/build/tmp/hsc2hs: Mach-O 64-bit executable arm64
```
to just name `ghc-cabal` and `hsc2hs`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | bgamari |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"make bindist packages the wrong binaries for cross compilers","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"8.4.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["bgamari"],"type":"Bug","description":"When building binary distributions via `make binary-dist`, the resulting binaries in the package end up being compiled for the target instead of the host when cross compiling.\r\n\r\nE.g. building a cross compiler for iOS on macOS yields:\r\n{{{\r\n./inplace/bin/ghc-cabal: Mach-O 64-bit executable x86_64\r\n./utils/ghc-cabal/dist/build/tmp/ghc-cabal: Mach-O 64-bit executable x86_64\r\n./utils/ghc-cabal/dist-install/build/tmp/ghc-cabal: Mach-O 64-bit executable arm64\r\n./inplace/lib/bin/hsc2hs: Mach-O 64-bit executable x86_64\r\n./utils/hsc2hs/dist/build/tmp/hsc2hs: Mach-O 64-bit executable x86_64\r\n./utils/hsc2hs/dist-install/build/tmp/hsc2hs: Mach-O 64-bit executable arm64\r\n}}}\r\nto just name `ghc-cabal` and `hsc2hs`.","type_of_failure":"OtherFailure","blocking":[]} -->8.4.1Moritz AngermannMoritz Angermannhttps://gitlab.haskell.org/ghc/ghc/-/issues/14017"make install" with non-standard umask causes bad permission on package.cache2022-02-11T00:19:09Zdjf"make install" with non-standard umask causes bad permission on package.cacheUsing Debian 8 binary package ghc-8.2.1-x86_64-deb8-linux.tar.xz to install with `configure` and then `su` and `make install`.
If your umask is 0027 rather than the default 0022, a file doesn't get made world-readable. (Other files in t...Using Debian 8 binary package ghc-8.2.1-x86_64-deb8-linux.tar.xz to install with `configure` and then `su` and `make install`.
If your umask is 0027 rather than the default 0022, a file doesn't get made world-readable. (Other files in this directory do though.)
```
$ ls -l /usr/local/lib/ghc-8.2.1/package.conf.d/package.cache
-rw-r----- 1 root staff 161490 Jul 23 10:02 /usr/local/lib/ghc-8.2.1/package.conf.d/package.cache
```
It results in this message when trying to use ghc or ghci:
```
$ ghci
GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help
/usr/local/lib/ghc-8.2.1/package.conf.d/package.cache: openBinaryFile: permission denied (Permission denied)
```
(n.b. I have set the version field in this bug to 8.2.1-rc3 for now because 8.2.1 isn't in the list yet.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1-rc3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"\"make install\" with non-standard umask causes bad permission on package.cache","status":"New","operating_system":"","component":"None","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1-rc3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Using Debian 8 binary package ghc-8.2.1-x86_64-deb8-linux.tar.xz to install with `configure` and then `su` and `make install`.\r\n\r\nIf your umask is 0027 rather than the default 0022, a file doesn't get made world-readable. (Other files in this directory do though.)\r\n\r\n{{{\r\n$ ls -l /usr/local/lib/ghc-8.2.1/package.conf.d/package.cache\r\n-rw-r----- 1 root staff 161490 Jul 23 10:02 /usr/local/lib/ghc-8.2.1/package.conf.d/package.cache\r\n}}}\r\n\r\nIt results in this message when trying to use ghc or ghci:\r\n\r\n{{{\r\n$ ghci\r\nGHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help\r\n/usr/local/lib/ghc-8.2.1/package.conf.d/package.cache: openBinaryFile: permission denied (Permission denied)\r\n}}}\r\n\r\n(n.b. I have set the version field in this bug to 8.2.1-rc3 for now because 8.2.1 isn't in the list yet.)","type_of_failure":"OtherFailure","blocking":[]} -->8.2.3Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/11587Place shared objects in LIBDIR2020-12-20T18:22:52ZBen GamariPlace shared objects in LIBDIRIf one compiles a program with `-dynamic`, the resulting executable includes in its `rpath` the library directory of every Haskell package that the program links against. This causes a significant number of excess system calls at program...If one compiles a program with `-dynamic`, the resulting executable includes in its `rpath` the library directory of every Haskell package that the program links against. This causes a significant number of excess system calls at program start-up. For instance, in the case of a dynamically linked `ghc` executable on Debian 8, compiling a trivial "hello world" application produces over 800 `open` calls, the majority of which originate from the dynamic linker. e.g.,
```
$ strace -f -e open ghc-7.10.3 -c -fforce-recomp Test.hs 2>&1 | grep open
...
open("/usr/lib/ghc/bin/../haske_GGvi737nHHfG6zm2y7Rimi/tls/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/ghc/bin/../haske_GGvi737nHHfG6zm2y7Rimi/tls/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/ghc/bin/../haske_GGvi737nHHfG6zm2y7Rimi/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/ghc/bin/../haske_GGvi737nHHfG6zm2y7Rimi/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/ghc/bin/../termi_6iVf4EBnOgfIaaOCLRs8jl/tls/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/ghc/bin/../termi_6iVf4EBnOgfIaaOCLRs8jl/tls/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/ghc/bin/../termi_6iVf4EBnOgfIaaOCLRs8jl/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/ghc/bin/../termi_6iVf4EBnOgfIaaOCLRs8jl/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/ghc/bin/../ghc_0AG9TOjDEtx4Ji3wSwHOBe/tls/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/ghc/bin/../ghc_0AG9TOjDEtx4Ji3wSwHOBe/tls/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/ghc/bin/../ghc_0AG9TOjDEtx4Ji3wSwHOBe/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
...
```
The dynamic linker must look in nearly 25 Haskell library directories to locate every system library! This is madness.
Instead of placing each shared library in its own directory, `$LIBDIR/$PKG_KEY/lib$PKG_KEY.so` as we do currently, why not just place them in `$LIBDIR`, e.g. `$LIBDIR/lib$PKG_KEY.so`. This would mean that we need to include only one directory, `$LIBDIR`, in `rpath`.8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/11025Per-database shadowing2019-07-07T18:32:34ZEdward Z. YangPer-database shadowingIn `5b0191f74ab05b187f81ea037623338a615b1619`, I eliminated shadowing, on the justification that we should never pick the same component ID (previously installed package ID) for two distinct packages unless the ABIs of the packages were ...In `5b0191f74ab05b187f81ea037623338a615b1619`, I eliminated shadowing, on the justification that we should never pick the same component ID (previously installed package ID) for two distinct packages unless the ABIs of the packages were the same, so we could just globally assume that component IDs are unique.
However, I've recently come across some cases where we can't easily actually make this be the case. Here are a few of them:
1. GHC's build system assumes that the ghc package will always be a library name of the form HSghc-7.11.a (i.e. that its component ID is ghc-7.11). It's a bit nontrivial to change this assumption, because there are stage1 shenanigans which are rewriting the version number to one without the date. But obviously if you are bootstrapping GHC with itself, the component ID of the GHC you are building will conflict with the component ID of the host GHC.
1. A similar situation exist for bootstrapping packages. When compiling GHC, we want to pick fairly deterministic component IDs for it in order to avoid needless rebuilding. But then if you turn around and use one of these builds to bootstrap GHC, if you use the same deterministic scheme you will end up with conflicting component IDs.
1. More generally, if you are building a package which is already in the global database (and thus not easily removable), it is sometimes VERY CONVENIENT to be able to pick whatever component ID you want, even if it's in the global database. (1) and (2) are cases of this.
So I think what we want to do is bring back shadowing, but have it operate on a PER-DATABASE basis. For example, if we have the following databases:
```
pkg.conf.1
foo-0.1-XXX
bar-0.2-YYY (depends on foo-0.1-XXX)
pkg.conf.2
foo-0.1-XXX
baz-0.3-ZZZ (depends on foo-0.1-XXX)
```
If we stack pkg.conf.2 on top of pkg.conf.1, we invalidate foo-0.1-XXX FROM pkg.conf.1 (which simply means any packages from pkg.conf.1 which refer to it.)
It also occurs to me that we should also be recording the ABIs of packages we depend on, to ensure consistency. Consider:
```
pkg.conf.1
foo-0.1-XXX (abi is AAA)
pkg.conf.2
foo-0.1-XXX (abi is BBB)
pkg.conf.3
bar-0.1-YYY (depends on foo-0.1-XXX)
```
Which is the correct database to use `pkg.conf.3` with? We have no way of telling today! Sure, `pkg.conf.3` is incomplete, but this is a supported mode of operation.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Per-database shadowing","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"8.0.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ezyang"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In `5b0191f74ab05b187f81ea037623338a615b1619`, I eliminated shadowing, on the justification that we should never pick the same component ID (previously installed package ID) for two distinct packages unless the ABIs of the packages were the same, so we could just globally assume that component IDs are unique.\r\n\r\nHowever, I've recently come across some cases where we can't easily actually make this be the case. Here are a few of them:\r\n\r\n1. GHC's build system assumes that the ghc package will always be a library name of the form HSghc-7.11.a (i.e. that its component ID is ghc-7.11). It's a bit nontrivial to change this assumption, because there are stage1 shenanigans which are rewriting the version number to one without the date. But obviously if you are bootstrapping GHC with itself, the component ID of the GHC you are building will conflict with the component ID of the host GHC.\r\n\r\n2. A similar situation exist for bootstrapping packages. When compiling GHC, we want to pick fairly deterministic component IDs for it in order to avoid needless rebuilding. But then if you turn around and use one of these builds to bootstrap GHC, if you use the same deterministic scheme you will end up with conflicting component IDs.\r\n\r\n3. More generally, if you are building a package which is already in the global database (and thus not easily removable), it is sometimes VERY CONVENIENT to be able to pick whatever component ID you want, even if it's in the global database. (1) and (2) are cases of this.\r\n\r\nSo I think what we want to do is bring back shadowing, but have it operate on a PER-DATABASE basis. For example, if we have the following databases:\r\n\r\n{{{\r\npkg.conf.1\r\n foo-0.1-XXX\r\n bar-0.2-YYY (depends on foo-0.1-XXX)\r\npkg.conf.2\r\n foo-0.1-XXX\r\n baz-0.3-ZZZ (depends on foo-0.1-XXX)\r\n}}}\r\n\r\nIf we stack pkg.conf.2 on top of pkg.conf.1, we invalidate foo-0.1-XXX FROM pkg.conf.1 (which simply means any packages from pkg.conf.1 which refer to it.)\r\n\r\nIt also occurs to me that we should also be recording the ABIs of packages we depend on, to ensure consistency. Consider:\r\n\r\n{{{\r\npkg.conf.1\r\n foo-0.1-XXX (abi is AAA)\r\npkg.conf.2\r\n foo-0.1-XXX (abi is BBB)\r\npkg.conf.3\r\n bar-0.1-YYY (depends on foo-0.1-XXX)\r\n}}}\r\n\r\nWhich is the correct database to use `pkg.conf.3` with? We have no way of telling today! Sure, `pkg.conf.3` is incomplete, but this is a supported mode of operation.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/10479Make GHC install libraries to, e.g. xhtml-3000.2.1-0ACfOp3hebWD9jGWE4v4Gh2019-07-07T18:35:45ZEdward Z. YangMake GHC install libraries to, e.g. xhtml-3000.2.1-0ACfOp3hebWD9jGWE4v4GhThe GHC version of https://github.com/haskell/cabal/issues/2437 ; we need to adapt ghc-cabal to use the correct install paths. I have an in-flight patch, see the Phabricator. However, applying the change to HEAD is blocked by https://git...The GHC version of https://github.com/haskell/cabal/issues/2437 ; we need to adapt ghc-cabal to use the correct install paths. I have an in-flight patch, see the Phabricator. However, applying the change to HEAD is blocked by https://github.com/haskell/cabal/issues/2638 since there are some Cabal changes, which necessitate updating to Cabal head.
Cabal maintainers have expressed interest in this being merged into 7.10. To do this, we first have to merge the Cabal change into the 7.10 branch of Cabal, and apply the differential to GHC 7.10. (We shouldn't be blocked by the Cabal HEAD changes as those are not on the 7.10 branch.) If 7.10 release managers agree to let this patch in I volunteer to coordinate the changes.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Make GHC install libraries to, e.g. xhtml-3000.2.1-0ACfOp3hebWD9jGWE4v4Gh","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"7.10.2","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ezyang"},"version":"7.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The GHC version of https://github.com/haskell/cabal/issues/2437 ; we need to adapt ghc-cabal to use the correct install paths. I have an in-flight patch, see the Phabricator. However, applying the change to HEAD is blocked by https://github.com/haskell/cabal/issues/2638 since there are some Cabal changes, which necessitate updating to Cabal head.\r\n\r\nCabal maintainers have expressed interest in this being merged into 7.10. To do this, we first have to merge the Cabal change into the 7.10 branch of Cabal, and apply the differential to GHC 7.10. (We shouldn't be blocked by the Cabal HEAD changes as those are not on the 7.10 branch.) If 7.10 release managers agree to let this patch in I volunteer to coordinate the changes.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.2Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/9265Create PackageKey to replace PackageId, including version dependency information2019-07-07T18:41:08ZEdward Z. YangCreate PackageKey to replace PackageId, including version dependency information[Multipleinstalledinstancesofapackage](commentary/packages/multi-instances) has been a long sought after feature to alleviate Cabal hell, and was the subject of an [GSoC project](wiki:Commentary/GSoCMultipleInstances) that ultimately nev...[Multipleinstalledinstancesofapackage](commentary/packages/multi-instances) has been a long sought after feature to alleviate Cabal hell, and was the subject of an [GSoC project](wiki:Commentary/GSoCMultipleInstances) that ultimately never got merged into HEAD.
This ticket is our latest attack on the problem, summarized as: add a version dependency hash to the `PackageId` (NOT the `InstalledPackageId`) associated with packages in the database. This approach is distinguished from the prior attempts as follows:
- We make no attempt to support multiple installations of different ways or ABI-compatible versions of a library (e.g. with/without optimizations.) This corresponds to supporting multiple InstalledPackageIds in a database; in our case, we're supporting multiple `PackageId`.
- We do not have to deal with conflicting "instances" in GHC's package resolver: multiple instances can be simultaneously loaded and used in a single compiled program. This is because PackageIds are baked into the exported linker symbols, so different versions will have different names and can peacefully coexist.
- We do not have to deal with the delicate ordering problem of calculating an ABI hash when configuring a package, which is prior to when we actually know it (ABI hash is only known after compilation), because our hash is based ONLY on dependency resolution choice.
- In absence of preference for previously installed packages, our Cabal dependency resolution stays exactly the same: Cabal picks versions, and from these choices we calculate the dependency hashes. With preference, we will have to do a little more work.
- We do not attempt to garbage collect old packages. Because we are not dependent on ABI, there is not an explosion of installed pacakges from package development; new installed packages only occur when version numbers are bumped up, or packages are installed in a combinatorially different fashion.7.10.1Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/8407Module re-exports at the package level2019-07-07T18:45:11ZJoachim Breitnermail@joachim-breitner.deModule re-exports at the package levelFor various package reorganization purposes, especially for possibly turning `base` into a shim package that re-exports some modules from more specialized packages, good support for module re-exports would be nice.
I wrote up a design s...For various package reorganization purposes, especially for possibly turning `base` into a shim package that re-exports some modules from more specialized packages, good support for module re-exports would be nice.
I wrote up a design spec at ModuleReexports; this bug is to track the progress.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Module re-exports at the package level","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"For various package reorganization purposes, especially for possibly turning `base` into a shim package that re-exports some modules from more specialized packages, good support for module re-exports would be nice.\r\n\r\nI wrote up a design spec at ModuleReexports; this bug is to track the progress.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/5704Bug in the handling of wired-in packages (like template-haskell)2019-07-07T18:53:58ZSimon MarlowBug in the handling of wired-in packages (like template-haskell)If you install an older version of a wired-in package (e.g. template-haskell) and then try to use it, GHC will use the newer one as the "wired-in" package rather than the older one.
This happened when trying to build `aeson-0.4.0.0` wit...If you install an older version of a wired-in package (e.g. template-haskell) and then try to use it, GHC will use the newer one as the "wired-in" package rather than the older one.
This happened when trying to build `aeson-0.4.0.0` with ghc 7.4: `aeson` requires `template-haskell-2.6.0.0`, but GHC ships with 2.7.0.0. Cabal installed `template-haskell-2.6.0.0`, but while building `aeson` against it we get:
```
Data/Aeson/TH.hs:181:1:
Bad interface file: /Users/tibbe/.cabal/lib/template-haskell-2.6.0.0/ghc-7.4.0.20111213/Language/Haskell/TH.hi
Something is amiss; requested module template-haskell-2.6.0.0:Language.Haskell.TH differs from name found in the interface file template-haskell:Language.Haskell.TH
```
the bug is that `findWiredInPackage` has picked `template-haskell-2.7.0.0` to be the wired-in package:
```
wired-in package template-haskell mapped to template-haskell-2.7.0.0-inplace
```
whereas we wanted to use `template-haskell-2.6.0.0`.
Not immediately obvious what the fix should be, so I'm making a ticket for this. The workaround is to update the dependency in `aeson` to allow `template-haskell-2.7.0.0`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Bug in the handling of wired-in packages (like template-haskell)","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"7.4.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If you install an older version of a wired-in package (e.g. template-haskell) and then try to use it, GHC will use the newer one as the \"wired-in\" package rather than the older one.\r\n\r\nThis happened when trying to build `aeson-0.4.0.0` with ghc 7.4: `aeson` requires `template-haskell-2.6.0.0`, but GHC ships with 2.7.0.0. Cabal installed `template-haskell-2.6.0.0`, but while building `aeson` against it we get:\r\n\r\n{{{\r\nData/Aeson/TH.hs:181:1:\r\n Bad interface file: /Users/tibbe/.cabal/lib/template-haskell-2.6.0.0/ghc-7.4.0.20111213/Language/Haskell/TH.hi\r\n Something is amiss; requested module template-haskell-2.6.0.0:Language.Haskell.TH differs from name found in the interface file template-haskell:Language.Haskell.TH\r\n}}}\r\n\r\nthe bug is that `findWiredInPackage` has picked `template-haskell-2.7.0.0` to be the wired-in package:\r\n\r\n{{{\r\nwired-in package template-haskell mapped to template-haskell-2.7.0.0-inplace\r\n}}}\r\n\r\nwhereas we wanted to use `template-haskell-2.6.0.0`.\r\n\r\nNot immediately obvious what the fix should be, so I'm making a ticket for this. The workaround is to update the dependency in `aeson` to allow `template-haskell-2.7.0.0`.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/4104ghc-pkg refuses to register packages if some include directories don't exist2019-07-07T19:00:32ZMaxime Henrion <mux@FreeBSD.org>ghc-pkg refuses to register packages if some include directories don't existWhen registering a package, ghc-pkg fails with an error if any of the include directories do not exist. This is fine in general, but causes installation failures with gtk2hs. This is because the gtk2hs build tools will add all the direct...When registering a package, ghc-pkg fails with an error if any of the include directories do not exist. This is fine in general, but causes installation failures with gtk2hs. This is because the gtk2hs build tools will add all the directories given by "pkg-config --cflags gtk+-2.0", which typically contains lots of redundant and possibly non-existent directories, depending on your operating system.
Maybe ghc-pkg should just warn instead?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc-pkg refuses to register packages if some include directories don't exist","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When registering a package, ghc-pkg fails with an error if any of the include directories do not exist. This is fine in general, but causes installation failures with gtk2hs. This is because the gtk2hs build tools will add all the directories given by \"pkg-config --cflags gtk+-2.0\", which typically contains lots of redundant and possibly non-existent directories, depending on your operating system.\r\n\r\nMaybe ghc-pkg should just warn instead?","type_of_failure":"OtherFailure","blocking":[]} -->