GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:59:22Zhttps://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/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/3930ghci does not consider library-dirs of dependent packages for dlopen()2019-07-07T19:01:27Zduncanghci does not consider library-dirs of dependent packages for dlopen()On OSX, when ghci loads a package (eg `ghci -package gtk`) it uses dlopen on the .dynlib files specified in the package registration. However it appears to look only in the `library-dirs` of the package itself and not of the dependent pa...On OSX, when ghci loads a package (eg `ghci -package gtk`) it uses dlopen on the .dynlib files specified in the package registration. However it appears to look only in the `library-dirs` of the package itself and not of the dependent packages.
This shows up with gtk2hs on OSX when the glib and gtk C libs are in a non-standard location (/opt/local/lib). The glib package registration file uses `library-dirs: /opt/local/lib` and the gtk package depend on the glib package. The gtk package requires the C lib libgthread-2.0.dynlib. This exists in `/opt/local/lib` however when loading the gtk package in ghci, it does not look in `/opt/local/lib`. It only does so if we modify the gtk registration file to specify `library-dirs: /opt/local/lib`.
This behaviour of not using the lib dirs of dependent packages is inconsistent with the static linking case. I suspect this bad behaviour is specific to OSX, because I think this has always worked in the gtk2hs windows installers.
<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":"ghci does not consider library-dirs of dependent packages for dlopen()","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":"On OSX, when ghci loads a package (eg `ghci -package gtk`) it uses dlopen on the .dynlib files specified in the package registration. However it appears to look only in the `library-dirs` of the package itself and not of the dependent packages.\r\n\r\nThis shows up with gtk2hs on OSX when the glib and gtk C libs are in a non-standard location (/opt/local/lib). The glib package registration file uses `library-dirs: /opt/local/lib` and the gtk package depend on the glib package. The gtk package requires the C lib libgthread-2.0.dynlib. This exists in `/opt/local/lib` however when loading the gtk package in ghci, it does not look in `/opt/local/lib`. It only does so if we modify the gtk registration file to specify `library-dirs: /opt/local/lib`.\r\n\r\nThis behaviour of not using the lib dirs of dependent packages is inconsistent with the static linking case. I suspect this bad behaviour is specific to OSX, because I think this has always worked in the gtk2hs windows installers.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.3https://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":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3268implement the Cabal ${pkgroot} spec extension2019-07-07T19:04:40Zduncanimplement the Cabal ${pkgroot} spec extensionSee the proposal for relative paths in installed package descriptions:
http://www.haskell.org/pipermail/libraries/2009-May/011772.html
Basically it amounts to replacing ghc's current `$topdir` and `$httptopdir` with variables that are ...See the proposal for relative paths in installed package descriptions:
http://www.haskell.org/pipermail/libraries/2009-May/011772.html
Basically it amounts to replacing ghc's current `$topdir` and `$httptopdir` with variables that are interpreted relative to the package db file itself rather than relative to where ghc is installed (though for the global package db these coincide).
The open question is how tools discover the location of the package dbs. The proposed spec extension does not specify this, but perhaps it should specify an extension to (the hypothetical) `hc-pkg` system to discover the default set of package dbs and their paths.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.2 |
| 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":"implement the Cabal ${pkgroot} spec extension","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"See the proposal for relative paths in installed package descriptions:\r\n\r\nhttp://www.haskell.org/pipermail/libraries/2009-May/011772.html\r\n\r\nBasically it amounts to replacing ghc's current `$topdir` and `$httptopdir` with variables that are interpreted relative to the package db file itself rather than relative to where ghc is installed (though for the global package db these coincide).\r\n\r\nThe open question is how tools discover the location of the package dbs. The proposed spec extension does not specify this, but perhaps it should specify an extension to (the hypothetical) `hc-pkg` system to discover the default set of package dbs and their paths.","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/3249Unable to install Ghc packages by MacPorts2019-07-07T19:04:44ZsoopoUnable to install Ghc packages by MacPortsI was asked to send the following error here.
I am not sure where the bug is.
```
sudo port install hs-cabal hs-Crypto hs-libcabal ...I was asked to send the following error here.
I am not sure where the bug is.
```
sudo port install hs-cabal hs-Crypto hs-libcabal ~
Password:
---> Fetching hs-HTTP
---> Attempting to fetch HTTP-3001.1.4.tar.gz from http://trd.no.distfiles.macports.org/hs-HTTP
---> Verifying checksum(s) for hs-HTTP
---> Extracting hs-HTTP
---> Configuring hs-HTTP
---> Building hs-HTTP
---> Staging hs-HTTP into destroot
---> Installing hs-HTTP @3001.1.4_0
---> Activating hs-HTTP @3001.1.4_0
---> Cleaning hs-HTTP
---> Fetching hs-libcabal
---> Attempting to fetch Cabal-1.6.0.1.tar.gz from http://trd.no.distfiles.macports.org/hs-libcabal
---> Verifying checksum(s) for hs-libcabal
---> Extracting hs-libcabal
---> Configuring hs-libcabal
---> Building hs-libcabal
---> Staging hs-libcabal into destroot
---> Installing hs-libcabal @1.6.0.1_0
---> Activating hs-libcabal @1.6.0.1_0
---> Cleaning hs-libcabal
---> Fetching hs-zlib
---> Attempting to fetch zlib-0.5.0.0.tar.gz from http://trd.no.distfiles.macports.org/hs-zlib
---> Verifying checksum(s) for hs-zlib
---> Extracting hs-zlib
---> Configuring hs-zlib
---> Building hs-zlib
---> Staging hs-zlib into destroot
---> Installing hs-zlib @0.5.0.0_0
---> Activating hs-zlib @0.5.0.0_0
---> Cleaning hs-zlib
---> Fetching hs-cabal
---> Attempting to fetch cabal-install-0.6.0.tar.gz from http://trd.no.distfiles.macports.org/hs-cabal
---> Verifying checksum(s) for hs-cabal
---> Extracting hs-cabal
---> Configuring hs-cabal
---> Building hs-cabal
---> Staging hs-cabal into destroot
---> Installing hs-cabal @0.6.0_0
---> Activating hs-cabal @0.6.0_0
---> Cleaning hs-cabal
---> Fetching hs-Crypto
---> Attempting to fetch Crypto-4.1.0.tar.gz from http://trd.no.distfiles.macports.org/hs-Crypto
---> Verifying checksum(s) for hs-Crypto
---> Extracting hs-Crypto
---> Configuring hs-Crypto
---> Building hs-Crypto
Error: Target org.macports.build returned: shell command "cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_hs-Crypto/work/Crypto-4.1.0 && runhaskell Setup build -v" returned error 1
Command output: In the instance declaration for `Integral (LargeKey a b)'
Data/LargeWord.hs:137:9:
Warning: No explicit method nor default method for `toRational'
In the instance declaration for `Real (LargeKey a b)'
Data/LargeWord.hs:140:9:
Warning: No explicit method nor default method for `toEnum'
In the instance declaration for `Enum (LargeKey a b)'
Data/LargeWord.hs:140:9:
Warning: No explicit method nor default method for `fromEnum'
In the instance declaration for `Enum (LargeKey a b)'
[10 of 11] Compiling Codec.Encryption.AES ( Codec/Encryption/AES.hs, dist/build/SymmetricTest/SymmetricTest-tmp/Codec/Encryption/AES.o )
[11 of 11] Compiling Main ( SymmetricTest.hs, dist/build/SymmetricTest/SymmetricTest-tmp/Main.o )
Linking dist/build/SymmetricTest/SymmetricTest ...
Building executable: SHA1Test...
Creating dist/build/SHA1Test (and its parents)
Creating dist/build/SHA1Test/SHA1Test-tmp (and its parents)
/opt/local/bin/ghc -o dist/build/SHA1Test/SHA1Test --make -hide-all-packages -no-user-package-conf -i -idist/build/SHA1Test/SHA1Test-tmp -i. -idist/build/autogen -Idist/build/autogen -Idist/build/SHA1Test/SHA1Test-tmp -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build/SHA1Test/SHA1Test-tmp -hidir dist/build/SHA1Test/SHA1Test-tmp -stubdir dist/build/SHA1Test/SHA1Test-tmp -package HUnit-1.2.0.3 -package QuickCheck-1.2.0.0 -package array-0.2.0.0 -package base-4.0.0.0 -package pretty-1.0.1.0 -package random-1.0.0.1 -O ./SHA1Test.hs
[1 of 4] Compiling Codec.Utils ( Codec/Utils.hs, dist/build/SHA1Test/SHA1Test-tmp/Codec/Utils.o )
[2 of 4] Compiling Data.Digest.SHA1 ( Data/Digest/SHA1.hs, dist/build/SHA1Test/SHA1Test-tmp/Data/Digest/SHA1.o )
[3 of 4] Compiling Codec.Text.Raw ( Codec/Text/Raw.hs, dist/build/SHA1Test/SHA1Test-tmp/Codec/Text/Raw.o )
[4 of 4] Compiling Main ( SHA1Test.hs, dist/build/SHA1Test/SHA1Test-tmp/Main.o )
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for i386-apple-darwin):
RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs-graph
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Error: Status 1 encountered during processing.
[
```https://gitlab.haskell.org/ghc/ghc/-/issues/3204Binary package of GHC 6.10.2 fails to install on debian etch (amd64)2019-07-07T19:04:54ZsolBinary package of GHC 6.10.2 fails to install on debian etch (amd64)Released package http://www.haskell.org/ghc/dist/6.10.2/ghc-6.10.2-x86_64-unknown-linux-libedit2.tar.bz2 fails to install on Debian GNU/Linux 4.0 r3 with:
/usr/bin/strip: /home/sol/.install/ghc/ghc-6.10.2-inst/lib/ghc-6.10.2/ghc-pkg: Fi...Released package http://www.haskell.org/ghc/dist/6.10.2/ghc-6.10.2-x86_64-unknown-linux-libedit2.tar.bz2 fails to install on Debian GNU/Linux 4.0 r3 with:
/usr/bin/strip: /home/sol/.install/ghc/ghc-6.10.2-inst/lib/ghc-6.10.2/ghc-pkg: File format not recognized
`strip --version` gives:
```
GNU strip 2.17 Debian GNU/Linux
```
`uname -a` gives:
```
Linux gcc14 2.6.18-6-vserver-amd64 #1 SMP Fri Dec 12 06:15:44 UTC 2008 x86_64 GNU/Linux
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.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":"Binary package of GHC 6.10.2 fails to install on debian etch (amd64)","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Released package http://www.haskell.org/ghc/dist/6.10.2/ghc-6.10.2-x86_64-unknown-linux-libedit2.tar.bz2 fails to install on Debian GNU/Linux 4.0 r3 with:\r\n\r\n/usr/bin/strip: /home/sol/.install/ghc/ghc-6.10.2-inst/lib/ghc-6.10.2/ghc-pkg: File format not recognized\r\n\r\n\r\n{{{strip --version}}} gives:\r\n{{{\r\nGNU strip 2.17 Debian GNU/Linux\r\n}}}\r\n{{{uname -a}}} gives:\r\n{{{\r\nLinux gcc14 2.6.18-6-vserver-amd64 #1 SMP Fri Dec 12 06:15:44 UTC 2008 x86_64 GNU/Linux\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->