GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:44:40Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/8527The ordering of -I directives should be consistent with the ordering of -pack...2019-07-07T18:44:40ZparcsThe ordering of -I directives should be consistent with the ordering of -package directivesHere's a reduced test case:
## cpp.hs
```haskell
{-# LANGUAGE CPP #-}
#include "Typeable.h"
main = return ()
```
## command line
```
$ ghc-stage2 -c -package base cpp.hs
In file included from cpp.hs:4:0:
/home/patrick/code/ghc/li...Here's a reduced test case:
## cpp.hs
```haskell
{-# LANGUAGE CPP #-}
#include "Typeable.h"
main = return ()
```
## command line
```
$ ghc-stage2 -c -package base cpp.hs
In file included from cpp.hs:4:0:
/home/patrick/code/ghc/libraries/base/include/Typeable.h:17:2:
warning: #warning <Typeable.h> is obsolete and will be removed in GHC 7.10 [-Wcpp]
#warning <Typeable.h> is obsolete and will be removed in GHC 7.10
^
compilation IS NOT required
$ ghc-stage2 -c -package base -package containers cpp.hs
compilation IS NOT required
$ ghc-stage2 -c -package containers -package base cpp.hs
```
Notice that if I pass `-package containers` to ghc, the cpp warning from Typeable.h (from the base library) doesn't appear. This is because containers also has a Typeable.h in its include path, and in the invocation of the preprocessor, containers' include path precedes base's no matter how I order the `-package` directives.
This behavior is unintuitive and limiting. To fix this, I think that the ordering of -I directives passed to the preprocessor should be consistent with the ordering of -package directives passed to ghc. For example, in the above test case, a warning should be shown in the 1st and 2nd invocations of ghc but not the 3rd, because in the 3rd invocation containers precedes base.
Does this sound okay?parcsparcshttps://gitlab.haskell.org/ghc/ghc/-/issues/8442Cabal-install internal error with any use2019-07-07T18:45:03ZsenkCabal-install internal error with any useAny attempt to use cabal-install fails with an internal error.
Used FreeBSD (9.1) port hs-haskell-platform and built with hs-colour support, LLVM (3.2) backend, and profiling enabled. Warnings were given that the version of LLVM used wa...Any attempt to use cabal-install fails with an internal error.
Used FreeBSD (9.1) port hs-haskell-platform and built with hs-colour support, LLVM (3.2) backend, and profiling enabled. Warnings were given that the version of LLVM used was untested, but no issues were apparent when compiling.
```
cabal install hakyll
cabal-install: internal error: evacuate(static): strange closure type -385875968
(GHC version 7.6.3 for x86_64_portbld_freebsd)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Abort trap
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| 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":"Cabal-install internal error with any use","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":"Bug","description":"Any attempt to use cabal-install fails with an internal error.\r\n\r\nUsed FreeBSD (9.1) port hs-haskell-platform and built with hs-colour support, LLVM (3.2) backend, and profiling enabled. Warnings were given that the version of LLVM used was untested, but no issues were apparent when compiling.\r\n\r\n{{{\r\ncabal install hakyll\r\ncabal-install: internal error: evacuate(static): strange closure type -385875968\r\n (GHC version 7.6.3 for x86_64_portbld_freebsd)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nAbort trap\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->pgjpgjhttps://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/7990ghc-pkg warning shows the wrong command2019-07-07T18:47:09Zmcandreghc-pkg warning shows the wrong commandWhen ghc-pkg observes your cache is out of date, it displays a helpful warning, recommending "ghc-pkg recache". However, sometimes running this command does not fix the problem, because it targets the wrong cache.
For out of date global...When ghc-pkg observes your cache is out of date, it displays a helpful warning, recommending "ghc-pkg recache". However, sometimes running this command does not fix the problem, because it targets the wrong cache.
For out of date global caches, "ghc-pkg --global recache" successfully clears the warning. For out of date user caches, "ghc-pkg --user recache" clears the warning.
In the future, could ghc-pkg display the command more specific to the problem?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| 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 warning shows the wrong command","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":"Bug","description":"When ghc-pkg observes your cache is out of date, it displays a helpful warning, recommending \"ghc-pkg recache\". However, sometimes running this command does not fix the problem, because it targets the wrong cache.\r\n\r\nFor out of date global caches, \"ghc-pkg --global recache\" successfully clears the warning. For out of date user caches, \"ghc-pkg --user recache\" clears the warning.\r\n\r\nIn the future, could ghc-pkg display the command more specific to the problem?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7531after manualy installing array-0.4.0.12019-07-07T18:49:20Zguestafter manualy installing array-0.4.0.1After manually installing array-0.4.0.1 installation manually of Cabal -1.16.0.3 print:
```
c:\download\archive\Cabal\1.16.0.3\Cabal-1.16.0.3>runghc Setup.hs install
ghc: panic! (the 'impossible' happened)
(GHC version 7.4.2 for i386-...After manually installing array-0.4.0.1 installation manually of Cabal -1.16.0.3 print:
```
c:\download\archive\Cabal\1.16.0.3\Cabal-1.16.0.3>runghc Setup.hs install
ghc: panic! (the 'impossible' happened)
(GHC version 7.4.2 for i386-unknown-mingw32):
interactiveUI:setBuffering2
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```7.8.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/7324GHC 7.6.1 ships with a buggy Cabal2019-07-07T18:50:15Ztd123GHC 7.6.1 ships with a buggy CabalUsing ghc 7.6.1
$ rm -rf \~/.cabal \# To force a new default config being written
$ cabal update \# To write default config
Config file path source is default config file.
Config file /home/bardur/.cabal/config not found.
Writing defaul...Using ghc 7.6.1
$ rm -rf \~/.cabal \# To force a new default config being written
$ cabal update \# To write default config
Config file path source is default config file.
Config file /home/bardur/.cabal/config not found.
Writing default configuration to /home/bardur/.cabal/config
Downloading the latest package list from hackage.haskell.org
$ cabal install foo
cabal: Command.optionToFieldDescr: feature not implemented
related bug report: https://bugs.archlinux.org/task/31864
Although this particular bug doesn't seem to be severe since once you remove the incorrect jobs line in the .cabal/config file it starts working again, it is quite annoying.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.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":"GHC 7.6.1 ships with a buggy Cabal","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Using ghc 7.6.1\r\n\r\n$ rm -rf ~/.cabal # To force a new default config being written\r\n$ cabal update # To write default config\r\nConfig file path source is default config file.\r\nConfig file /home/bardur/.cabal/config not found.\r\nWriting default configuration to /home/bardur/.cabal/config\r\nDownloading the latest package list from hackage.haskell.org\r\n$ cabal install foo\r\ncabal: Command.optionToFieldDescr: feature not implemented\r\n\r\nrelated bug report: https://bugs.archlinux.org/task/31864\r\n\r\nAlthough this particular bug doesn't seem to be severe since once you remove the incorrect jobs line in the .cabal/config file it starts working again, it is quite annoying.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5907Crashed loading package Safe2019-07-07T18:53:03ZguestCrashed loading package Safe```
Loading package array-0.3.0.2 ... linking ... done.
Loading package containers-0.4.0.0 ... linking ... done.
Loading package safe-0.3.3 ... ghc: panic! (the 'impossible' happened)
(GHC version 7.0.3 for i386-unknown-mingw32):
load...```
Loading package array-0.3.0.2 ... linking ... done.
Loading package containers-0.4.0.0 ... linking ... done.
Loading package safe-0.3.3 ... ghc: panic! (the 'impossible' happened)
(GHC version 7.0.3 for i386-unknown-mingw32):
loadObj "C:\\Documents and Settings\\\1042\1083\1072\1076\1099\1082\1072\\Application Data\\cabal\\safe-0.3.3\\ghc-7.0.3\\HSsafe-0.3.3.o": failed
```
Before that I installed package Safe using cabal.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/5709ghc-7.2 cannot find libraries in non-standard locations2019-07-07T18:53:56ZAndres Löhghc-7.2 cannot find libraries in non-standard locationsThe following is what I perceive to be a regression from ghc-7.0.4 to ghc-7.2.1 and ghc-7.2.2.
On NixOS, all packages are installed into separate directories in the Nix store. With ghc-7.0.4, the following works:
```
$ ghc -package zli...The following is what I perceive to be a regression from ghc-7.0.4 to ghc-7.2.1 and ghc-7.2.2.
On NixOS, all packages are installed into separate directories in the Nix store. With ghc-7.0.4, the following works:
```
$ ghc -package zlib -e "print ()"
()
$ ghc-pkg describe zlib | grep library-dirs -A 1
library-dirs: /nix/store/vnflri0w0fadiqwv1j6w6gxw00paav6a-haskell-zlib-ghc7.0.4-0.5.3.1-profiling/lib/zlib-0.5.3.1/ghc-7.0.4
/nix/store/0jmzlnayh2p06vlgmiiyaj3xppc6l9lr-zlib-1.2.5/lib
$ strace ghc -package zlib -e "print ()" 2>&1 | grep libz.so
stat64("/nix/store/vnflri0w0fadiqwv1j6w6gxw00paav6a-haskell-zlib-ghc7.0.4-0.5.3.1-profiling/lib/zlib-0.5.3.1/ghc-7.0.4/libz.so", 0xb5e94490) = -1 ENOENT (No such file or directory)
stat64("/nix/store/0jmzlnayh2p06vlgmiiyaj3xppc6l9lr-zlib-1.2.5/lib/libz.so", {st_mode=S_IFREG|0555, st_size=91092, ...}) = 0
open("/nix/store/0jmzlnayh2p06vlgmiiyaj3xppc6l9lr-zlib-1.2.5/lib/libz.so", O_RDONLY) = 7
```
However, if I try exactly the same with ghc-7.2.1, I get:
```
$ ghc -package zlib -e "print ()"
<command line>: can't load .so/.DLL for: libz.so (libz.so: cannot open shared object file: No such file or directory)
$ ghc-pkg describe zlib | grep library-dirs -A 1
library-dirs: /nix/store/6zjd86g35dpxl5r6zrr67nnmf00qalkr-haskell-zlib-ghc7.2.1-0.5.3.1-profiling/lib/zlib-0.5.3.1/ghc-7.2.1
/nix/store/0jmzlnayh2p06vlgmiiyaj3xppc6l9lr-zlib-1.2.5/lib
$ strace ghc -package zlib -e "print ()" 2>&1 | grep libz.so
open("/nix/store/ri2nlzb1lsi0d1y7nb8dkhzhsnyd08k4-gmp-4.3.2/lib/libz.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/nix/store/nmliqd429c0s4sdlbk0394zdfx86gvf9-ncurses-5.7/lib/libz.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/nix/store/m9p1r0p6qlaw5wy5hnwpii323la3s8j3-glibc-2.12.2/lib/libz.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/nix/store/m9p1r0p6qlaw5wy5hnwpii323la3s8j3-glibc-2.12.2/lib/libz.so", O_RDONLY) = -1 ENOENT (No such file or directory)
```
The directories listed by strace seem to be the ones used for building GHC itself. The directories in the package configuration file seem to be ignored.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.2.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":"ghc-7.2 cannot find libraries in non-standard locations","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following is what I perceive to be a regression from ghc-7.0.4 to ghc-7.2.1 and ghc-7.2.2.\r\n\r\nOn NixOS, all packages are installed into separate directories in the Nix store. With ghc-7.0.4, the following works:\r\n{{{\r\n$ ghc -package zlib -e \"print ()\"\r\n()\r\n$ ghc-pkg describe zlib | grep library-dirs -A 1\r\nlibrary-dirs: /nix/store/vnflri0w0fadiqwv1j6w6gxw00paav6a-haskell-zlib-ghc7.0.4-0.5.3.1-profiling/lib/zlib-0.5.3.1/ghc-7.0.4\r\n /nix/store/0jmzlnayh2p06vlgmiiyaj3xppc6l9lr-zlib-1.2.5/lib\r\n$ strace ghc -package zlib -e \"print ()\" 2>&1 | grep libz.so\r\nstat64(\"/nix/store/vnflri0w0fadiqwv1j6w6gxw00paav6a-haskell-zlib-ghc7.0.4-0.5.3.1-profiling/lib/zlib-0.5.3.1/ghc-7.0.4/libz.so\", 0xb5e94490) = -1 ENOENT (No such file or directory)\r\nstat64(\"/nix/store/0jmzlnayh2p06vlgmiiyaj3xppc6l9lr-zlib-1.2.5/lib/libz.so\", {st_mode=S_IFREG|0555, st_size=91092, ...}) = 0\r\nopen(\"/nix/store/0jmzlnayh2p06vlgmiiyaj3xppc6l9lr-zlib-1.2.5/lib/libz.so\", O_RDONLY) = 7\r\n}}}\r\n\r\nHowever, if I try exactly the same with ghc-7.2.1, I get:\r\n{{{\r\n$ ghc -package zlib -e \"print ()\"\r\n<command line>: can't load .so/.DLL for: libz.so (libz.so: cannot open shared object file: No such file or directory)\r\n$ ghc-pkg describe zlib | grep library-dirs -A 1\r\nlibrary-dirs: /nix/store/6zjd86g35dpxl5r6zrr67nnmf00qalkr-haskell-zlib-ghc7.2.1-0.5.3.1-profiling/lib/zlib-0.5.3.1/ghc-7.2.1\r\n /nix/store/0jmzlnayh2p06vlgmiiyaj3xppc6l9lr-zlib-1.2.5/lib\r\n$ strace ghc -package zlib -e \"print ()\" 2>&1 | grep libz.so\r\nopen(\"/nix/store/ri2nlzb1lsi0d1y7nb8dkhzhsnyd08k4-gmp-4.3.2/lib/libz.so\", O_RDONLY) = -1 ENOENT (No such file or directory)\r\nopen(\"/nix/store/nmliqd429c0s4sdlbk0394zdfx86gvf9-ncurses-5.7/lib/libz.so\", O_RDONLY) = -1 ENOENT (No such file or directory)\r\nopen(\"/nix/store/m9p1r0p6qlaw5wy5hnwpii323la3s8j3-glibc-2.12.2/lib/libz.so\", O_RDONLY) = -1 ENOENT (No such file or directory)\r\nopen(\"/nix/store/m9p1r0p6qlaw5wy5hnwpii323la3s8j3-glibc-2.12.2/lib/libz.so\", O_RDONLY) = -1 ENOENT (No such file or directory)\r\n}}}\r\nThe directories listed by strace seem to be the ones used for building GHC itself. The directories in the package configuration file seem to be ignored.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1https://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/5521Allow unknown fields in .cabal with X- at front2019-07-07T18:54:55Zzzo38Allow unknown fields in .cabal with X- at frontI have suggestion allowing unknown fields in a .cabal file, and if they are named with X- at front, they will not have warning message, and will be ignored if they are not understand.
<details><summary>Trac metadata</summary>
| Trac fi...I have suggestion allowing unknown fields in a .cabal file, and if they are named with X- at front, they will not have warning message, and will be ignored if they are not understand.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.2.1 |
| 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":"Allow unknown fields in .cabal with X- at front","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"I have suggestion allowing unknown fields in a .cabal file, and if they are named with X- at front, they will not have warning message, and will be ignored if they are not understand.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5511-package should take priority over modules in the filesystem2019-07-07T18:54:57Zpeteg-package should take priority over modules in the filesystemImagine I have a GHC package called P. I build it using Cabal and a directory structure like so:
```
P/ -- project root, containing P.cabal etc.
P/Code/M.hs
P/Tests/T.hs
```
I build P and install it.
In P/ I want to say:
```
ghci -pa...Imagine I have a GHC package called P. I build it using Cabal and a directory structure like so:
```
P/ -- project root, containing P.cabal etc.
P/Code/M.hs
P/Tests/T.hs
```
I build P and install it.
In P/ I want to say:
```
ghci -package P Tests/T.hs
```
but ghci insists on loading Code/M.hs rather than using P - it seems to ignore the -package flag.
cheers
peter
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.3 |
| 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":"-package should take priority over modules in the filesystem","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Imagine I have a GHC package called P. I build it using Cabal and a directory structure like so:\r\n\r\n{{{\r\nP/ -- project root, containing P.cabal etc.\r\nP/Code/M.hs\r\nP/Tests/T.hs\r\n}}}\r\n\r\nI build P and install it.\r\n\r\nIn P/ I want to say:\r\n\r\n{{{\r\nghci -package P Tests/T.hs\r\n}}}\r\n\r\nbut ghci insists on loading Code/M.hs rather than using P - it seems to ignore the -package flag.\r\n\r\ncheers\r\npeter","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5216Haskell Platform 2011.2.0.1 Setup2019-07-07T18:56:23ZguestHaskell Platform 2011.2.0.1 Setup"Could not write updated PATH to HKLM"
This message was given three times when I installed Haskell Platform 2011.2.0.1 on my brand new Windows 7 Enterprise (with Service Pack 1) computer. (btw, a version I downloaded three months ago di..."Could not write updated PATH to HKLM"
This message was given three times when I installed Haskell Platform 2011.2.0.1 on my brand new Windows 7 Enterprise (with Service Pack 1) computer. (btw, a version I downloaded three months ago did exactly the same)
After inserting the path by hand in the environment variables, ghc was found from the command prompt.
The fact that this message was given three times, and I just resolved one path, suggests that I am missing two other paths. Could you let me know which ones?
Thanks,
Stef Joosten
stef.joosten\@ou.nl
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 7.0.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | stef.joosten@ou.nl |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Haskell Platform 2011.2.0.1 Setup","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":["\"windows","7\"","setup"],"differentials":[],"test_case":"","architecture":"","cc":["stef.joosten@ou.nl"],"type":"Bug","description":"\"Could not write updated PATH to HKLM\"\r\n\r\nThis message was given three times when I installed Haskell Platform 2011.2.0.1 on my brand new Windows 7 Enterprise (with Service Pack 1) computer. (btw, a version I downloaded three months ago did exactly the same)\r\n\r\nAfter inserting the path by hand in the environment variables, ghc was found from the command prompt.\r\n\r\nThe fact that this message was given three times, and I just resolved one path, suggests that I am missing two other paths. Could you let me know which ones?\r\nThanks,\r\nStef Joosten\r\nstef.joosten@ou.nl","type_of_failure":"OtherFailure","blocking":[]} -->https://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/4354OS X installer deletes old versions, breaks symlinks2019-07-07T18:59:22ZelaforgeOS X installer deletes old versions, breaks symlinksThe .pkg installer for ghc removes previous versions of ghc and leaves broken
stale symlinks in /usr/bin
The symlink issue can be fixed with a new create-links script, included. The
old script links through the Current symlink, which is...The .pkg installer for ghc removes previous versions of ghc and leaves broken
stale symlinks in /usr/bin
The symlink issue can be fixed with a new create-links script, included. The
old script links through the Current symlink, which is updated to point to
the latest version. So every new install breaks the symlinks for the old
one. The new script links through the version directory, so it doesn't get
broken when Current changes.
There are other binaries which are unversioned, like hsc2hs and haddock.
I guess this was a conscious decision so I didn't try to make versioned
symlinks to those, they just get overwritten with the last installed version.
I also changed create-links to put a version on /usr/share/doc/ghc. I left
the man pages unversioned because 'man ghc' should work.
The deletion problem is due to the fact that the OS X installer always wants
to delete an old version when installing a new one. It makes more sense for
a compiler to allow multiple concurrent versions. The way around this is to
append the version to the package name (the python installer does this).
Unfortunately, there are lots of places you can set the "bundle ID" and
as far as I can tell no documentation for it. So based on trial and error,
I appended the version to distrib/MacOS/Info.plist and the -i flag to
packagemaker. Both seem to be necessary. I use the PackageVersionInt, so
reinstalling a ghc with the same major and minor version but a different
patchelevel will overwrite it, as before, which seems reasonable.
This means the Uninstaller isn't so useful, since it's designed to only work
with a single installed version. I did a bit of work to extend it to remove
a certain version, but decided it's not really worth it. OS X programmers
don't generally have installers. The old uninstaller was also removing the
incorrect package receipt (it removes
org.haskell.glasgowHaskellCompiler.ghc.pkg.bom, which on my machine, is what
1. 12.1 used, but not anything newer).
I reckon the simplest thing is to just remove the uninstaller (and update the
doc in the installer to not mention it). If there are people who really like
it, I can finish off my fancy uninstall one version thing.
I left the uninstaller but can remove it in a separate patch if people agree.
I also changed occurrences of 'org.haskell.glasgowHaskellCompiler.ghc.pkg' to 'org.haskell.ghc.pkg'. It doesn't seem to have any effect, but older versions named the package glasgowHaskellCompiler.ghc and it seems messy and confusing to have multiple versions of the same identifier around.
I tested these changes on my machine, and they seem to work fine, but it would
be good to get a few more people to try it on their macs. After the changes,
installing the new .pkg should create
/Library/Receipts/boms/org.haskell.ghc.700.bom, and of course a Versions/700
and not overwrite any previous versions. GHC packages going forward should no
longer overwrite each other.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.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":"OS X installer deletes old versions, breaks symlinks","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The .pkg installer for ghc removes previous versions of ghc and leaves broken\r\nstale symlinks in /usr/bin\r\n\r\nThe symlink issue can be fixed with a new create-links script, included. The\r\nold script links through the Current symlink, which is updated to point to\r\nthe latest version. So every new install breaks the symlinks for the old\r\none. The new script links through the version directory, so it doesn't get\r\nbroken when Current changes.\r\n\r\nThere are other binaries which are unversioned, like hsc2hs and haddock.\r\nI guess this was a conscious decision so I didn't try to make versioned\r\nsymlinks to those, they just get overwritten with the last installed version.\r\n\r\nI also changed create-links to put a version on /usr/share/doc/ghc. I left\r\nthe man pages unversioned because 'man ghc' should work.\r\n\r\nThe deletion problem is due to the fact that the OS X installer always wants\r\nto delete an old version when installing a new one. It makes more sense for\r\na compiler to allow multiple concurrent versions. The way around this is to\r\nappend the version to the package name (the python installer does this).\r\nUnfortunately, there are lots of places you can set the \"bundle ID\" and\r\nas far as I can tell no documentation for it. So based on trial and error,\r\nI appended the version to distrib/MacOS/Info.plist and the -i flag to\r\npackagemaker. Both seem to be necessary. I use the PackageVersionInt, so\r\nreinstalling a ghc with the same major and minor version but a different\r\npatchelevel will overwrite it, as before, which seems reasonable.\r\n\r\nThis means the Uninstaller isn't so useful, since it's designed to only work\r\nwith a single installed version. I did a bit of work to extend it to remove\r\na certain version, but decided it's not really worth it. OS X programmers\r\ndon't generally have installers. The old uninstaller was also removing the\r\nincorrect package receipt (it removes\r\norg.haskell.glasgowHaskellCompiler.ghc.pkg.bom, which on my machine, is what\r\n6.12.1 used, but not anything newer).\r\n\r\nI reckon the simplest thing is to just remove the uninstaller (and update the\r\ndoc in the installer to not mention it). If there are people who really like\r\nit, I can finish off my fancy uninstall one version thing.\r\n\r\nI left the uninstaller but can remove it in a separate patch if people agree.\r\n\r\nI also changed occurrences of 'org.haskell.glasgowHaskellCompiler.ghc.pkg' to 'org.haskell.ghc.pkg'. It doesn't seem to have any effect, but older versions named the package glasgowHaskellCompiler.ghc and it seems messy and confusing to have multiple versions of the same identifier around.\r\n\r\nI tested these changes on my machine, and they seem to work fine, but it would \r\nbe good to get a few more people to try it on their macs. After the changes,\r\ninstalling the new .pkg should create \r\n/Library/Receipts/boms/org.haskell.ghc.700.bom, and of course a Versions/700\r\nand not overwrite any previous versions. GHC packages going forward should no\r\nlonger overwrite each other.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4260GHC Mac installer Perl path2019-07-07T18:59:48ZdonsGHC Mac installer Perl pathSee HP bug http://trac.haskell.org/haskell-platform/ticket/138
Perl executable path on the Mac installer for GHC creates unnec. dependency on Perl from MacPorts, making GHC harder to install.
HP can patch and work around, but it would ...See HP bug http://trac.haskell.org/haskell-platform/ticket/138
Perl executable path on the Mac installer for GHC creates unnec. dependency on Perl from MacPorts, making GHC harder to install.
HP can patch and work around, but it would be better to fix upstream.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.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":"GHC Mac installer Perl path","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"See HP bug http://trac.haskell.org/haskell-platform/ticket/138 \r\n\r\nPerl executable path on the Mac installer for GHC creates unnec. dependency on Perl from MacPorts, making GHC harder to install.\r\n\r\nHP can patch and work around, but it would be better to fix upstream.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4158Non-ASCII author name breaks ghc-pkg recache2019-07-07T19:00:21ZAnders KaseorgNon-ASCII author name breaks ghc-pkg recache```
$ cabal install binary-shared
Resolving dependencies...
Configuring binary-shared-0.8...
Preprocessing library binary-shared-0.8...
Building binary-shared-0.8...
[1 of 1] Compiling Data.Binary.Shared ( src/Data/Binary/Shared.hs,
dist...```
$ cabal install binary-shared
Resolving dependencies...
Configuring binary-shared-0.8...
Preprocessing library binary-shared-0.8...
Building binary-shared-0.8...
[1 of 1] Compiling Data.Binary.Shared ( src/Data/Binary/Shared.hs,
dist/build/Data/Binary/Shared.o )
Registering binary-shared-0.8...
Installing library in /home/anders/.cabal/lib/binary-shared-0.8/ghc-6.12.1
Registering binary-shared-0.8...
$ ghc-pkg recache
ghc-pkg: /home/anders/.ghc/x86_64-linux-6.12.1/package.conf.d/binary-shared-0.8-00180db675f2ea73ce16a4820071cd80.conf:
hGetContents: invalid argument (invalid UTF-8 byte sequence)
```
The author’s name, Jürgen Nicklisch-Franken, is written in UTF-8 in binary-shared.cabal. It is translated to Haskell \\decimal-escaped Unicode syntax in package.conf.inplace, which is passed to ghc-pkg update. But the resulting .conf file contains the name in ISO-8859-1. This breaks ghc-pkg recache.
I’m using ghc6 6.12.1-13 on Ubuntu maverick amd64.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.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":"Non-ASCII author name breaks ghc-pkg recache","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n$ cabal install binary-shared\r\nResolving dependencies...\r\nConfiguring binary-shared-0.8...\r\nPreprocessing library binary-shared-0.8...\r\nBuilding binary-shared-0.8...\r\n[1 of 1] Compiling Data.Binary.Shared ( src/Data/Binary/Shared.hs,\r\ndist/build/Data/Binary/Shared.o )\r\nRegistering binary-shared-0.8...\r\nInstalling library in /home/anders/.cabal/lib/binary-shared-0.8/ghc-6.12.1\r\nRegistering binary-shared-0.8...\r\n$ ghc-pkg recache\r\nghc-pkg: /home/anders/.ghc/x86_64-linux-6.12.1/package.conf.d/binary-shared-0.8-00180db675f2ea73ce16a4820071cd80.conf:\r\nhGetContents: invalid argument (invalid UTF-8 byte sequence)\r\n}}}\r\n\r\nThe author’s name, Jürgen Nicklisch-Franken, is written in UTF-8 in binary-shared.cabal. It is translated to Haskell \\decimal-escaped Unicode syntax in package.conf.inplace, which is passed to ghc-pkg update. But the resulting .conf file contains the name in ISO-8859-1. This breaks ghc-pkg recache.\r\n\r\nI’m using ghc6 6.12.1-13 on Ubuntu maverick amd64.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://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":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4072Local package DB doesn't take preference over global DB2019-07-07T19:00:49ZtibbeLocal package DB doesn't take preference over global DBI sometime find myself wanting to compile some small test program (say `Test.hs`) against a locally built Cabal package. Here's what I do:
```
ghc -c Test.hs -package-conf dist/package.conf.inplace
```
This doesn't work
```
Test.hs:4:...I sometime find myself wanting to compile some small test program (say `Test.hs`) against a locally built Cabal package. Here's what I do:
```
ghc -c Test.hs -package-conf dist/package.conf.inplace
```
This doesn't work
```
Test.hs:4:0:
Failed to load interface for `Data.Text.Lazy.Builder':
Use -v to see a list of the files searched for.
```
The global version of `text` gets picked instead of the local one (and in this case the global version lacks the `Data.Text.Lazy.Builder` module). I expect the package given on the command line to take preference.
Workaround: Bump the version number of the local package.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.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":"Local package DB doesn't take preference over global DB","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I sometime find myself wanting to compile some small test program (say `Test.hs`) against a locally built Cabal package. Here's what I do:\r\n\r\n{{{\r\nghc -c Test.hs -package-conf dist/package.conf.inplace\r\n}}}\r\n\r\nThis doesn't work\r\n\r\n{{{\r\nTest.hs:4:0:\r\n Failed to load interface for `Data.Text.Lazy.Builder':\r\n Use -v to see a list of the files searched for.\r\n}}}\r\n\r\nThe global version of `text` gets picked instead of the local one (and in this case the global version lacks the `Data.Text.Lazy.Builder` module). I expect the package given on the command line to take preference.\r\n\r\nWorkaround: Bump the version number of the local package.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.3Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/4048ghc-pkg should check for existence of extra-libraries2019-07-07T19:00:58ZSimon Marlowghc-pkg should check for existence of extra-librariesIn #3930 we decided that all `extra-libraries` should be found either on the system search path or the paths in the package's `library-dirs` field. We should make `ghc-pkg` check this when registering a package - it can use `gcc -print-s...In #3930 we decided that all `extra-libraries` should be found either on the system search path or the paths in the package's `library-dirs` field. We should make `ghc-pkg` check this when registering a package - it can use `gcc -print-search-dirs` to get the system search path.
<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 should check for existence of extra-libraries","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"7.0.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In #3930 we decided that all `extra-libraries` should be found either on the system search path or the paths in the package's `library-dirs` field. We should make `ghc-pkg` check this when registering a package - it can use `gcc -print-search-dirs` to get the system search path.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1