GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2022-03-29T16:17:37Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/8591Concurrent executions of ghc-pkg can cause inconstant package.cache files2022-03-29T16:17:37ZjanmConcurrent executions of ghc-pkg can cause inconstant package.cache filesI am doing 24 way parallel builds of system images, including all packages on a system. This includes ghc and multiple ghc packages.
I am seeing intermittent dependency failure from the ghc packaging system. From examining Main.hs in gh...I am doing 24 way parallel builds of system images, including all packages on a system. This includes ghc and multiple ghc packages.
I am seeing intermittent dependency failure from the ghc packaging system. From examining Main.hs in ghc-pkg, I see the function withFileAtomic write to a temporary file in package.conf.d and then atomically rename on top of a target file, package.cache in the case. With parallel execution the last rename would win, leading to lost entries in package.cache.
In my case, the following things happened: ("Building" indicates a start, "Built" indicates completion, "Installing" is setup in a separate chroot'd environment and is isolated)
The FreeBSD ports system is used to drive the Haskell build system.
The process works single threaded and fails intermittently when done in parallel.
Building: devel/hs-data-default-instances-base
Building: devel/hs-data-default-instances-containers
Building: devel/hs-data-default-instances-old-locale
Built: devel/hs-dlist
Building: devel/hs-data-default-instances-dlist
Built: devel/hs-temporary
Built: jail-image-full
Installing: system-image__jail-image-full
Built: devel/hs-base64-bytestring
Built: archivers/hs-zlib
Building: security/hs-digest
Built: devel/hs-syb
Building: textproc/hs-hs-bibutils
Building: textproc/hs-pandoc-types
Built: devel/hs-utf8-string
Built: devel/hs-data-default-instances-old-locale
Built: devel/hs-data-default-instances-containers
Built: devel/hs-data-default-instances-base
Built: devel/hs-data-default-instances-dlist
Building: devel/hs-data-default
Built: devel/hs-random
Installed: system-image__lang/ghc
Installing: system-image__archivers/hs-zlib
Installing: system-image__devel/hs-utf8-string
Installing: system-image__devel/hs-syb
Installing: system-image__devel/hs-base64-bytestring
Installing: system-image__devel/hs-data-default-class
Installing: system-image__devel/hs-dlist
Installing: system-image__devel/hs-random
Installing: system-image__devel/hs-temporary
Installing: system-image__devel/hs-extensible-exceptions
Built: devel/hs-data-default FAILED
The error from the Haskell data-default build was:
setup: At least the following dependencies are missing:
data-default-instances-base -any
Looking in the in the package.conf.d directory shows that the data-default-instances-base-0.0.1-7bdf8678f0d8637e096e397e7910f82a.conf file was present, but running "ghc-pkg list" did not show data-default-instances-base
Running /usr/local/lib/cabal/ghc-7.6.3/data-default-instances-base-0.0.1/register.sh (which was also present) caused ghc-pkg to now show data-default-instances-base.
To me this looks like a race condition between multiple instances of ghc-pkg causing the cache to become inconsistent.
<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 | FreeBSD |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Concurrent executions of ghc-pkg can cause inconstant package.cache files","status":"New","operating_system":"FreeBSD","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":["ghc-pkg","race"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I am doing 24 way parallel builds of system images, including all packages on a system. This includes ghc and multiple ghc packages.\r\n\r\nI am seeing intermittent dependency failure from the ghc packaging system. From examining Main.hs in ghc-pkg, I see the function withFileAtomic write to a temporary file in package.conf.d and then atomically rename on top of a target file, package.cache in the case. With parallel execution the last rename would win, leading to lost entries in package.cache.\r\n\r\nIn my case, the following things happened: (\"Building\" indicates a start, \"Built\" indicates completion, \"Installing\" is setup in a separate chroot'd environment and is isolated)\r\n\r\nThe FreeBSD ports system is used to drive the Haskell build system.\r\n\r\nThe process works single threaded and fails intermittently when done in parallel.\r\n\r\nBuilding: devel/hs-data-default-instances-base\r\nBuilding: devel/hs-data-default-instances-containers\r\nBuilding: devel/hs-data-default-instances-old-locale\r\nBuilt: devel/hs-dlist \r\nBuilding: devel/hs-data-default-instances-dlist\r\nBuilt: devel/hs-temporary \r\nBuilt: jail-image-full \r\nInstalling: system-image__jail-image-full\r\nBuilt: devel/hs-base64-bytestring \r\nBuilt: archivers/hs-zlib \r\nBuilding: security/hs-digest\r\nBuilt: devel/hs-syb \r\nBuilding: textproc/hs-hs-bibutils\r\nBuilding: textproc/hs-pandoc-types\r\nBuilt: devel/hs-utf8-string \r\nBuilt: devel/hs-data-default-instances-old-locale \r\nBuilt: devel/hs-data-default-instances-containers \r\nBuilt: devel/hs-data-default-instances-base \r\nBuilt: devel/hs-data-default-instances-dlist \r\nBuilding: devel/hs-data-default\r\nBuilt: devel/hs-random \r\nInstalled: system-image__lang/ghc \r\nInstalling: system-image__archivers/hs-zlib\r\nInstalling: system-image__devel/hs-utf8-string\r\nInstalling: system-image__devel/hs-syb\r\nInstalling: system-image__devel/hs-base64-bytestring\r\nInstalling: system-image__devel/hs-data-default-class\r\nInstalling: system-image__devel/hs-dlist\r\nInstalling: system-image__devel/hs-random\r\nInstalling: system-image__devel/hs-temporary\r\nInstalling: system-image__devel/hs-extensible-exceptions\r\nBuilt: devel/hs-data-default FAILED\r\n\r\nThe error from the Haskell data-default build was:\r\n\r\nsetup: At least the following dependencies are missing:\r\ndata-default-instances-base -any\r\n\r\nLooking in the in the package.conf.d directory shows that the data-default-instances-base-0.0.1-7bdf8678f0d8637e096e397e7910f82a.conf file was present, but running \"ghc-pkg list\" did not show data-default-instances-base\r\n\r\nRunning /usr/local/lib/cabal/ghc-7.6.3/data-default-instances-base-0.0.1/register.sh (which was also present) caused ghc-pkg to now show data-default-instances-base.\r\n\r\nTo me this looks like a race condition between multiple instances of ghc-pkg causing the cache to become inconsistent.","type_of_failure":"OtherFailure","blocking":[]} -->pgjpgjhttps://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/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/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/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/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/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/3971FFI callback segfaults on PPC2019-07-07T19:01:18ZWolfram KahlFFI callback segfaults on PPCghc-pkg has been segfaulting ever since I installed ghc-6.12.1.20100330 on my G5 PowerPC running gentoo 32-bit userland; current state:
```
/usr/local/packages/ghc-6.12.1.20100330/lib/ghc-6.12.1.20100330/package.conf.d
Cabal-1.8.0.3
...ghc-pkg has been segfaulting ever since I installed ghc-6.12.1.20100330 on my G5 PowerPC running gentoo 32-bit userland; current state:
```
/usr/local/packages/ghc-6.12.1.20100330/lib/ghc-6.12.1.20100330/package.conf.d
Cabal-1.8.0.3
QuickCheck-2.1.0.3
array-0.3.0.0
base-3.0.3.2
base-4.2.0.1
bin-package-db-0.0.0.0
binary-0.5.0.2
bytestring-0.9.1.6
containers-0.3.0.0
directory-1.0.1.1
Segmentation fault
```
(Now, trying to install zlib, I also get:
```
./Setup configure --prefix=/usr/local/packages/ghc-6.12.1.20100330 -p
Configuring zlib-0.5.2.0...
Setup: failed to parse output of 'ghc-pkg dump'
```
although I can see nothing wrong with the output of 'ghc-pkg dump' — reported under [Bug 559 in the Cabal trac](http://hackage.haskell.org/trac/hackage/ticket/599).)
Wolfram
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.1 RC1 |
| 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 list segfaults in ghc-6.12.1.20100330","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1 RC1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"ghc-pkg has been segfaulting ever since I installed ghc-6.12.1.20100330 on my G5 PowerPC running gentoo 32-bit userland; current state:\r\n\r\n{{{\r\n/usr/local/packages/ghc-6.12.1.20100330/lib/ghc-6.12.1.20100330/package.conf.d\r\n Cabal-1.8.0.3\r\n QuickCheck-2.1.0.3\r\n array-0.3.0.0\r\n base-3.0.3.2\r\n base-4.2.0.1\r\n bin-package-db-0.0.0.0\r\n binary-0.5.0.2\r\n bytestring-0.9.1.6\r\n containers-0.3.0.0\r\n directory-1.0.1.1\r\n Segmentation fault\r\n}}}\r\n\r\n(Now, trying to install zlib, I also get:\r\n{{{\r\n ./Setup configure --prefix=/usr/local/packages/ghc-6.12.1.20100330 -p\r\nConfiguring zlib-0.5.2.0...\r\nSetup: failed to parse output of 'ghc-pkg dump'\r\n}}}\r\nalthough I can see nothing wrong with the output of 'ghc-pkg dump' — reported under [http://hackage.haskell.org/trac/hackage/ticket/599 Bug 559 in the Cabal trac].)\r\n\r\nWolfram","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3970ghc-pkg list segfaults in ghc-6.12.1.201003302019-07-07T19:01:18ZWolfram Kahlghc-pkg list segfaults in ghc-6.12.1.20100330ghc-pkg has been segfaulting ever since I installed ghc-6.12.1.20100330 on my G5 PowerPC running gentoo 32-bit userland; current state:
```
/usr/local/packages/ghc-6.12.1.20100330/lib/ghc-6.12.1.20100330/package.conf.d
Cabal-1.8.0.3
...ghc-pkg has been segfaulting ever since I installed ghc-6.12.1.20100330 on my G5 PowerPC running gentoo 32-bit userland; current state:
```
/usr/local/packages/ghc-6.12.1.20100330/lib/ghc-6.12.1.20100330/package.conf.d
Cabal-1.8.0.3
QuickCheck-2.1.0.3
array-0.3.0.0
base-3.0.3.2
base-4.2.0.1
bin-package-db-0.0.0.0
binary-0.5.0.2
bytestring-0.9.1.6
containers-0.3.0.0
directory-1.0.1.1
Segmentation fault
```
(Now, trying to install zlib, I also get:
```
./Setup configure --prefix=/usr/local/packages/ghc-6.12.1.20100330 -p
Configuring zlib-0.5.2.0...
Setup: failed to parse output of 'ghc-pkg dump'
```
although I can see nothing wrong with the output of 'ghc-pkg dump' — reported under [Bug 559 in the Cabal trac](http://hackage.haskell.org/trac/hackage/ticket/599).)
Wolfram
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.1 RC1 |
| 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 list segfaults in ghc-6.12.1.20100330","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1 RC1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"ghc-pkg has been segfaulting ever since I installed ghc-6.12.1.20100330 on my G5 PowerPC running gentoo 32-bit userland; current state:\r\n\r\n{{{\r\n/usr/local/packages/ghc-6.12.1.20100330/lib/ghc-6.12.1.20100330/package.conf.d\r\n Cabal-1.8.0.3\r\n QuickCheck-2.1.0.3\r\n array-0.3.0.0\r\n base-3.0.3.2\r\n base-4.2.0.1\r\n bin-package-db-0.0.0.0\r\n binary-0.5.0.2\r\n bytestring-0.9.1.6\r\n containers-0.3.0.0\r\n directory-1.0.1.1\r\n Segmentation fault\r\n}}}\r\n\r\n(Now, trying to install zlib, I also get:\r\n{{{\r\n ./Setup configure --prefix=/usr/local/packages/ghc-6.12.1.20100330 -p\r\nConfiguring zlib-0.5.2.0...\r\nSetup: failed to parse output of 'ghc-pkg dump'\r\n}}}\r\nalthough I can see nothing wrong with the output of 'ghc-pkg dump' — reported under [http://hackage.haskell.org/trac/hackage/ticket/599 Bug 559 in the Cabal trac].)\r\n\r\nWolfram","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3818ghc-pkg prints warnings to stdout instead of stderr2019-07-07T19:02:00ZJoachim Breitnermail@joachim-breitner.deghc-pkg prints warnings to stdout instead of stderrThe warning
```
WARNING: cache is out of date: /var/lib/ghc-6.12.1/package.conf.d/package.cache
use 'ghc-pkg recache' to fix.
```
is printed to stdout, which breaks scripts. It should be printed to stderr instead.
<details><summary>...The warning
```
WARNING: cache is out of date: /var/lib/ghc-6.12.1/package.conf.d/package.cache
use 'ghc-pkg recache' to fix.
```
is printed to stdout, which breaks scripts. It should be printed to stderr instead.
<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":"ghc-pkg prints warnings to stdout instead of stderr","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":"The warning\r\n{{{\r\nWARNING: cache is out of date: /var/lib/ghc-6.12.1/package.conf.d/package.cache\r\n use 'ghc-pkg recache' to fix.\r\n}}}\r\nis printed to stdout, which breaks scripts. It should be printed to stderr instead.","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3682shared libraries not installed executable2019-07-07T19:02:48ZJens Petersenshared libraries not installed executableWhen ghc-6.12.0 is built with --enable-shared,
libHS\*.so shared library object files are installed
with permission -rw-r--r-- (644) not -rwxr-xr-x (755)
as they should be. (This is true for 6.12.0.20091118
and I assume also for rc2.)
<...When ghc-6.12.0 is built with --enable-shared,
libHS\*.so shared library object files are installed
with permission -rw-r--r-- (644) not -rwxr-xr-x (755)
as they should be. (This is true for 6.12.0.20091118
and I assume also for rc2.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.1 RC1 |
| 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":"shared libraries not installed executable","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1 RC1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When ghc-6.12.0 is built with --enable-shared,\r\nlibHS*.so shared library object files are installed\r\nwith permission -rw-r--r-- (644) not -rwxr-xr-x (755)\r\nas they should be. (This is true for 6.12.0.20091118\r\nand I assume also for rc2.)","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3593Where has readline gone?2019-07-07T19:03:12ZspiveyWhere has readline gone?In going from 6.8.x to 6.10.x, I find that Readline has dissappeared. Apparently, it was replaced by Editline for a short time, and now by Haskeline. But the standard installation doesn't seem to have either one installed as a library I ...In going from 6.8.x to 6.10.x, I find that Readline has dissappeared. Apparently, it was replaced by Editline for a short time, and now by Haskeline. But the standard installation doesn't seem to have either one installed as a library I can use. Can we have one of them back, please?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.4 |
| 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":"Where has readline gone?","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In going from 6.8.x to 6.10.x, I find that Readline has dissappeared. Apparently, it was replaced by Editline for a short time, and now by Haskeline. But the standard installation doesn't seem to have either one installed as a library I can use. Can we have one of them back, please?","type_of_failure":"OtherFailure","blocking":[]} -->