GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2021-12-09T20:47:10Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/19286ghc and ghci don't read the default package environment file on Windows2021-12-09T20:47:10Zdanidiazghc and ghci don't read the default package environment file on Windows## Summary
According to the [package environments section](https://downloads.haskell.org/ghc/latest/docs/html/users_guide/packages.html#package-environments) of the User Guide, `ghc` and `ghci` invocations should use the `$HOME/.ghc/arc...## Summary
According to the [package environments section](https://downloads.haskell.org/ghc/latest/docs/html/users_guide/packages.html#package-environments) of the User Guide, `ghc` and `ghci` invocations should use the `$HOME/.ghc/arch-os-version/environments/default` package environment file if it exists and no specific options have been given to the contrary.
This works correctly on Linux, but the file is not being found on Windows.
On my machine, the default package environment is located at `C:\Users\myuser\.ghc\x86_64-mingw32-8.10.3\environments\default`.
## Steps to reproduce
Create a package environment file in the default location. The simplest way is to install a library with [`cabal install --lib`](https://cabal.readthedocs.io/en/3.4/cabal-commands.html#cabal-v2-install):
`cabal install --lib sop-core`
Then, in an empty folder, start `ghci`, then try to `import Data.SOP.NP`.
Also create a `Main.hs` which imports `Data.SOP.NP` and try to compile with `ghc`.
## Expected behavior
Neither `ghci` nor `ghc` should complain about not finding the module.
`ghci` should show a `Loaded package environment from...` message when starting up.
## Environment
* GHC version used: 8.10.3
* Operating System: Windows 10https://gitlab.haskell.org/ghc/ghc/-/issues/18025INSTALL instructions of linux bindist says "make install" while it should be ...2020-04-08T23:06:50ZjwaldmannINSTALL instructions of linux bindist says "make install" while it should be "sudo make install"INSTALL of https://downloads.haskell.org/~ghc/8.8.3/ghc-8.8.3-x86_64-deb9-linux.tar.xz (and probably others) says
```
The default installation directory is /usr/local
...
Now run:
make install
```
This will fail, as "sudo make instal...INSTALL of https://downloads.haskell.org/~ghc/8.8.3/ghc-8.8.3-x86_64-deb9-linux.tar.xz (and probably others) says
```
The default installation directory is /usr/local
...
Now run:
make install
```
This will fail, as "sudo make install" is needed.https://gitlab.haskell.org/ghc/ghc/-/issues/17716Installed help files have broken hyperlink to Users Guide / local Users Guid...2020-01-20T21:34:37ZfreenInstalled help files have broken hyperlink to Users Guide / local Users Guide currently installed to wrong location## Summary
Accessing help from WinGHCi by pressing F1 or via the menu (Help->GHC Documentation) brings up the locally installed "GHC Documentation" page located at:
(Install Path)/doc/html/index.html
On this page there are hyperli...## Summary
Accessing help from WinGHCi by pressing F1 or via the menu (Help->GHC Documentation) brings up the locally installed "GHC Documentation" page located at:
(Install Path)/doc/html/index.html
On this page there are hyperlinks to:
* The Users Guide (href="users_guide/index.html")
* Libraries (href="libraries/index.html")
* GHC API (href="libraries/ghc-8.6.5/index.html")
The first link is broken, but the second and third links work.
The html help files are respectively located in:
* "(Install Path)/doc/users_guide"
* "(Install Path)/doc/html/libraries/" &
* "(Install Path)/doc/html/libraries/ghc-8.6.5/"
suggesting that the users_guide directory is not currently in the correct location.
## Proposed improvements or changes
Move the install location of the users_guide directory so it is in the doc/html/ directory. Doing this manually appears to resolve the issue.
## Environment
* GHC version used (if appropriate):
Win64 WinGHCi/Haskell Platform 8.6.5https://gitlab.haskell.org/ghc/ghc/-/issues/17468Hadrian uses wrong stage's ghc-pkg, writing incompatible package.cache2020-08-17T15:17:35ZNiklas Hambüchenmail@nh2.meHadrian uses wrong stage's ghc-pkg, writing incompatible package.cacheI tried to add a field to `InstalledPackageInfo`.
This gave me the error:
```
_build/stage0/lib/package.conf.d/package.cache: GHC.PackageDb.readPackageDb: inappropriate type (Not a valid Unicode code point!)
```
Full output: https://g...I tried to add a field to `InstalledPackageInfo`.
This gave me the error:
```
_build/stage0/lib/package.conf.d/package.cache: GHC.PackageDb.readPackageDb: inappropriate type (Not a valid Unicode code point!)
```
Full output: https://gist.github.com/nh2/94dc2f98b38798ed4a4e65844dd3ac9a
Doing `_build/stage0/lib/package.conf.d/{package.cache,rts.conf}` (also deleting a `.conf` file to work around #17467) and re-running `./hadrian/build.stack.sh -j --flavour=quickest --verbose` reveals the problem ([full output](https://gist.github.com/nh2/94dc2f98b38798ed4a4e65844dd3ac9a#file-problem-revealed-txt)):
```
ghc-pkg: cannot find package rts
| Run GhcPkg Copy Stage0: rts => _build/stage0/lib/package.conf.d/rts.conf
/raid/stack/programs/x86_64-linux/ghc-8.6.5/bin/ghc-pkg --expand-pkgroot --no-user-package-db describe rts
/raid/stack/programs/x86_64-linux/ghc-8.6.5/bin/ghc-pkg --global-package-db _build/stage0/lib/package.conf.d register -v0 -
```
As identified by @bgamari, it's using the global (stage0) `ghc-pkg register` to write the `package.conf`, which then of course cannot be deserialised by my modified `ghc-pkg` that expectes one field more.
> **nh2**: so you're saying it should use `_build/stage0/bin/ghc-pkg` instead?
>
> **bgamari**: rightMake removalAlp MestanogullariAlp Mestanogullarihttps://gitlab.haskell.org/ghc/ghc/-/issues/17467Hadrian does not track package.conf.d/package.cache2022-08-06T18:35:03ZAlp MestanogullariHadrian does not track package.conf.d/package.cacheWhile @nh2 and @bgamari were discussing a problem, they ended up realizing that deleting `_build/stage0/lib/package.conf.d/package.cache` and issuing a hadrian command to rebuild it and resume the build where it was previously failing re...While @nh2 and @bgamari were discussing a problem, they ended up realizing that deleting `_build/stage0/lib/package.conf.d/package.cache` and issuing a hadrian command to rebuild it and resume the build where it was previously failing results in:
```
ghc: there is no package.cache in _build/stage0/lib/package.conf.d even though package database is not empty
```
It's probably safe to assume that Hadrian does not track the package db cache in any way (not even using `traceWrite` or anything like that). It'd be nice to teach Hadrian enough about those caches for it to be able to regenerate them when needed.9.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/16751Cabal-3.0.0.0 breaks cabal012019-06-07T14:33:21ZBen GamariCabal-3.0.0.0 breaks cabal01When bumping cabal for %8.8.1 I found that the `cabal01` testcase broke. Tracked upstream as https://github.com/haskell/cabal/issues/6068.When bumping cabal for %8.8.1 I found that the `cabal01` testcase broke. Tracked upstream as https://github.com/haskell/cabal/issues/6068.8.8.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/16554Mixing `-package-env` and explicit package flags doesn't seem to work.2019-04-12T16:14:28ZOleg GrenrusMixing `-package-env` and explicit package flags doesn't seem to work.# Summary
Mixing `-package-env` and explicit package flags doesn't seem to work.
# Steps to reproduce
```
% ghci -package-env=default -hide-all-packages -clear-package-db
GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help
L...# Summary
Mixing `-package-env` and explicit package flags doesn't seem to work.
# Steps to reproduce
```
% ghci -package-env=default -hide-all-packages -clear-package-db
GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help
Loaded package environment from /home/ogre/.ghc/x86_64-linux-8.4.4/environments/default
Loaded GHCi configuration from /home/ogre/.ghci
```
# Expected behavior
I'd expect either empty package environment, or at least a warning that latter package database flags are ignored.
# Environment
* GHC version used: 8.4.4, 8.6.44
Optional:
* Operating System: Linux
* System Architecture: x86_64https://gitlab.haskell.org/ghc/ghc/-/issues/16318Explicitly passing -package-env causes "Loaded package environment from .ghc....2020-08-10T14:07:24ZRyan ScottExplicitly passing -package-env causes "Loaded package environment from .ghc.environment" message to be printed twice```
$ /opt/ghc/8.6.3/bin/ghc -package-env .ghc.environment.x86_64-linux-8.6.3 -e "putStrLn \"Hello\""
Loaded package environment from .ghc.environment.x86_64-linux-8.6.3
Loaded package environment from .ghc.environment.x86_64-linux-8.6.3...```
$ /opt/ghc/8.6.3/bin/ghc -package-env .ghc.environment.x86_64-linux-8.6.3 -e "putStrLn \"Hello\""
Loaded package environment from .ghc.environment.x86_64-linux-8.6.3
Loaded package environment from .ghc.environment.x86_64-linux-8.6.3
Hello
```
This is a regression from GHC 8.4.4:
```
$ /opt/ghc/8.4.4/bin/ghc -package-env .ghc.environment.x86_64-linux-8.4.4 -e "putStrLn \"Hello\""
Loaded package environment from .ghc.environment.x86_64-linux-8.4.4
Hello
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Explicitly passing -package-env causes \"Loaded package environment from .ghc.environment\" message to be printed twice","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr"],"type":"Bug","description":"{{{\r\n$ /opt/ghc/8.6.3/bin/ghc -package-env .ghc.environment.x86_64-linux-8.6.3 -e \"putStrLn \\\"Hello\\\"\"\r\nLoaded package environment from .ghc.environment.x86_64-linux-8.6.3\r\nLoaded package environment from .ghc.environment.x86_64-linux-8.6.3\r\nHello\r\n}}}\r\n\r\nThis is a regression from GHC 8.4.4:\r\n\r\n{{{\r\n$ /opt/ghc/8.4.4/bin/ghc -package-env .ghc.environment.x86_64-linux-8.4.4 -e \"putStrLn \\\"Hello\\\"\"\r\nLoaded package environment from .ghc.environment.x86_64-linux-8.4.4\r\nHello\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Artem PelenitsynArtem Pelenitsynhttps://gitlab.haskell.org/ghc/ghc/-/issues/15328cpphs: internal error: evacuate(static): strange closure type 84402021-09-28T14:02:00Zcnmnecpphs: internal error: evacuate(static): strange closure type 8440Attempting to install Agda via Cabal fails.
I've installed cpphs through Cabal and `~/Library/Haskell/bin` is in my path.
`~/.cabal/config` is default, but in `/Library/Frameworks/GHC.framework/Versions/8.4.3-x86_64/usr/lib/ghc-8.4.3 /...Attempting to install Agda via Cabal fails.
I've installed cpphs through Cabal and `~/Library/Haskell/bin` is in my path.
`~/.cabal/config` is default, but in `/Library/Frameworks/GHC.framework/Versions/8.4.3-x86_64/usr/lib/ghc-8.4.3 /settings` I have changed only `("C compiler supports -no-pie","NO")` (from "YES") because that was giving me errors earlier.
The log states: "Please report this as a GHC bug..." so here I am :\]
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.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":"cpphs: internal error: evacuate(static): strange closure type 8440","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["cabal,","closure","cpphs,","strange"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Attempting to install Agda via Cabal fails.\r\n\r\nI've installed cpphs through Cabal and {{{~/Library/Haskell/bin}}} is in my path.\r\n\r\n{{{~/.cabal/config}}} is default, but in {{{/Library/Frameworks/GHC.framework/Versions/8.4.3-x86_64/usr/lib/ghc-8.4.3 /settings}}} I have changed only {{{(\"C compiler supports -no-pie\",\"NO\")}}} (from \"YES\") because that was giving me errors earlier.\r\n\r\nThe log states: \"Please report this as a GHC bug...\" so here I am :]","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14297make bindist packages the wrong binaries for cross compilers2021-07-21T08:18:04ZMoritz Angermannmake bindist packages the wrong binaries for cross compilersWhen building binary distributions via `make binary-dist`, the resulting binaries in the package end up being compiled for the target instead of the host when cross compiling.
E.g. building a cross compiler for iOS on macOS yields:
```...When building binary distributions via `make binary-dist`, the resulting binaries in the package end up being compiled for the target instead of the host when cross compiling.
E.g. building a cross compiler for iOS on macOS yields:
```
./inplace/bin/ghc-cabal: Mach-O 64-bit executable x86_64
./utils/ghc-cabal/dist/build/tmp/ghc-cabal: Mach-O 64-bit executable x86_64
./utils/ghc-cabal/dist-install/build/tmp/ghc-cabal: Mach-O 64-bit executable arm64
./inplace/lib/bin/hsc2hs: Mach-O 64-bit executable x86_64
./utils/hsc2hs/dist/build/tmp/hsc2hs: Mach-O 64-bit executable x86_64
./utils/hsc2hs/dist-install/build/tmp/hsc2hs: Mach-O 64-bit executable arm64
```
to just name `ghc-cabal` and `hsc2hs`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | bgamari |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"make bindist packages the wrong binaries for cross compilers","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"8.4.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["bgamari"],"type":"Bug","description":"When building binary distributions via `make binary-dist`, the resulting binaries in the package end up being compiled for the target instead of the host when cross compiling.\r\n\r\nE.g. building a cross compiler for iOS on macOS yields:\r\n{{{\r\n./inplace/bin/ghc-cabal: Mach-O 64-bit executable x86_64\r\n./utils/ghc-cabal/dist/build/tmp/ghc-cabal: Mach-O 64-bit executable x86_64\r\n./utils/ghc-cabal/dist-install/build/tmp/ghc-cabal: Mach-O 64-bit executable arm64\r\n./inplace/lib/bin/hsc2hs: Mach-O 64-bit executable x86_64\r\n./utils/hsc2hs/dist/build/tmp/hsc2hs: Mach-O 64-bit executable x86_64\r\n./utils/hsc2hs/dist-install/build/tmp/hsc2hs: Mach-O 64-bit executable arm64\r\n}}}\r\nto just name `ghc-cabal` and `hsc2hs`.","type_of_failure":"OtherFailure","blocking":[]} -->8.4.1Moritz AngermannMoritz Angermannhttps://gitlab.haskell.org/ghc/ghc/-/issues/14182Allow full control over dyn lib names2019-07-07T18:18:06ZduncanAllow full control over dyn lib namesThis is related to:
- GHC ticket #11587
- Cabal issue https://github.com/haskell/cabal/issues/4263
- Cabal PR https://github.com/haskell/cabal/pull/4656
- Cabal PR https://github.com/haskell/cabal/pull/4426
Currently GHC hard codes the...This is related to:
- GHC ticket #11587
- Cabal issue https://github.com/haskell/cabal/issues/4263
- Cabal PR https://github.com/haskell/cabal/pull/4656
- Cabal PR https://github.com/haskell/cabal/pull/4426
Currently GHC hard codes the naming convention for shared/dynamic libraries. For example:
For `hs-libraries: HScpu-0.1.2-b25995` in the package registration, on ELF GHC uses the name `libHScpu-0.1.2-b2599-ghc8.0.1.so` (and .dynlib on OSX).
This naming convention is based on an old assumption that shared libraries would go in a shared `$libdir`, and that all that was needed to ensure uniqueness was the combination of the package id and ghc version.
This assumption is very out of date now. Different install schemes are used by different packaging tools (nix style vs classic style) and sometimes we want shared lib dirs and sometimes not, and of course we all know now that a package id is not nearly enough to ensure file names are unique.
The obvious solution is for GHC to stop making any unnecessary naming convention assumptions and allow specifying the full library name in the package registration information.
We would of course keep the remaining necessary naming convention is the `lib` prefix and `.so`/`.dynlib`/`.dll` suffix, which is the same convention used by the system linker for `-lfoo` vs `libfoo.so`.
- \*So specifically:\*\*
- Add a new `dynamic-hs-libraries` (to go along with `hs-libraries`) to the `ghc-pkg` registration information. This naming convention follows the existing `library-dirs` and `dynamic-library-dirs`.
- When this field is used then these library names will by used for dynamic linking. For backward compatibility, when this field is not supplied then the existing `-ghc8.0.1` convention is used.
While we are at it, we should do the same for the `extra-libraries` and add a `dynamic-extra-libraries`. Note that there is an existing `extra-ghci-libraries` which was added for a similar reason (though prior to ghci switching to dynamic libs by default) because in rare cases the dyn libs are just named differently from the static libs, or occasionally there are extra static vs dynamic libs. For example, `pkg-config` makes a clear distinction between static and dynamic libs (because dynamic libs only need direct deps whereas static needs the full transitive closure).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.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":"Allow full control over dyn lib names","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This is related to: \r\n\r\n * GHC ticket #11587\r\n * Cabal issue https://github.com/haskell/cabal/issues/4263\r\n * Cabal PR https://github.com/haskell/cabal/pull/4656\r\n * Cabal PR https://github.com/haskell/cabal/pull/4426\r\n\r\nCurrently GHC hard codes the naming convention for shared/dynamic libraries. For example:\r\n\r\nFor `hs-libraries: HScpu-0.1.2-b25995` in the package registration, on ELF GHC uses the name `libHScpu-0.1.2-b2599-ghc8.0.1.so` (and .dynlib on OSX).\r\n\r\nThis naming convention is based on an old assumption that shared libraries would go in a shared `$libdir`, and that all that was needed to ensure uniqueness was the combination of the package id and ghc version.\r\n\r\nThis assumption is very out of date now. Different install schemes are used by different packaging tools (nix style vs classic style) and sometimes we want shared lib dirs and sometimes not, and of course we all know now that a package id is not nearly enough to ensure file names are unique.\r\n\r\nThe obvious solution is for GHC to stop making any unnecessary naming convention assumptions and allow specifying the full library name in the package registration information.\r\n\r\nWe would of course keep the remaining necessary naming convention is the `lib` prefix and `.so`/`.dynlib`/`.dll` suffix, which is the same convention used by the system linker for `-lfoo` vs `libfoo.so`.\r\n\r\n**So specifically:**\r\n\r\n* Add a new `dynamic-hs-libraries` (to go along with `hs-libraries`) to the `ghc-pkg` registration information. This naming convention follows the existing `library-dirs` and `dynamic-library-dirs`.\r\n\r\n* When this field is used then these library names will by used for dynamic linking. For backward compatibility, when this field is not supplied then the existing `-ghc8.0.1` convention is used.\r\n\r\nWhile we are at it, we should do the same for the `extra-libraries` and add a `dynamic-extra-libraries`. Note that there is an existing `extra-ghci-libraries` which was added for a similar reason (though prior to ghci switching to dynamic libs by default) because in rare cases the dyn libs are just named differently from the static libs, or occasionally there are extra static vs dynamic libs. For example, `pkg-config` makes a clear distinction between static and dynamic libs (because dynamic libs only need direct deps whereas static needs the full transitive closure).","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14017"make install" with non-standard umask causes bad permission on package.cache2022-02-11T00:19:09Zdjf"make install" with non-standard umask causes bad permission on package.cacheUsing Debian 8 binary package ghc-8.2.1-x86_64-deb8-linux.tar.xz to install with `configure` and then `su` and `make install`.
If your umask is 0027 rather than the default 0022, a file doesn't get made world-readable. (Other files in t...Using Debian 8 binary package ghc-8.2.1-x86_64-deb8-linux.tar.xz to install with `configure` and then `su` and `make install`.
If your umask is 0027 rather than the default 0022, a file doesn't get made world-readable. (Other files in this directory do though.)
```
$ ls -l /usr/local/lib/ghc-8.2.1/package.conf.d/package.cache
-rw-r----- 1 root staff 161490 Jul 23 10:02 /usr/local/lib/ghc-8.2.1/package.conf.d/package.cache
```
It results in this message when trying to use ghc or ghci:
```
$ ghci
GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help
/usr/local/lib/ghc-8.2.1/package.conf.d/package.cache: openBinaryFile: permission denied (Permission denied)
```
(n.b. I have set the version field in this bug to 8.2.1-rc3 for now because 8.2.1 isn't in the list yet.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1-rc3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"\"make install\" with non-standard umask causes bad permission on package.cache","status":"New","operating_system":"","component":"None","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1-rc3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Using Debian 8 binary package ghc-8.2.1-x86_64-deb8-linux.tar.xz to install with `configure` and then `su` and `make install`.\r\n\r\nIf your umask is 0027 rather than the default 0022, a file doesn't get made world-readable. (Other files in this directory do though.)\r\n\r\n{{{\r\n$ ls -l /usr/local/lib/ghc-8.2.1/package.conf.d/package.cache\r\n-rw-r----- 1 root staff 161490 Jul 23 10:02 /usr/local/lib/ghc-8.2.1/package.conf.d/package.cache\r\n}}}\r\n\r\nIt results in this message when trying to use ghc or ghci:\r\n\r\n{{{\r\n$ ghci\r\nGHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help\r\n/usr/local/lib/ghc-8.2.1/package.conf.d/package.cache: openBinaryFile: permission denied (Permission denied)\r\n}}}\r\n\r\n(n.b. I have set the version field in this bug to 8.2.1-rc3 for now because 8.2.1 isn't in the list yet.)","type_of_failure":"OtherFailure","blocking":[]} -->8.2.3Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/13475Possible missing case in ghc-pkg2019-07-07T18:21:42ZTamar ChristinaPossible missing case in ghc-pkgI saw this while compiling
```
utils\ghc-pkg\Main.hs:761:25: Warning:
Pattern match(es) are non-exhaustive
In a case alternative: Patterns not matched: GhcPkg.DbOpenReadOnly
```
I don't know if this is indicative of a bug in th...I saw this while compiling
```
utils\ghc-pkg\Main.hs:761:25: Warning:
Pattern match(es) are non-exhaustive
In a case alternative: Patterns not matched: GhcPkg.DbOpenReadOnly
```
I don't know if this is indicative of a bug in the implementation or not?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.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":"Possible missing case in ghc-pkg","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I saw this while compiling\r\n\r\n{{{\r\nutils\\ghc-pkg\\Main.hs:761:25: Warning:\r\n Pattern match(es) are non-exhaustive\r\n In a case alternative: Patterns not matched: GhcPkg.DbOpenReadOnly\r\n}}}\r\n\r\nI don't know if this is indicative of a bug in the implementation or not?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13354Package database locking patch broke ghc-pkg with non-existent database2019-07-07T18:22:18ZBen GamariPackage database locking patch broke ghc-pkg with non-existent databaseIt seems that [D3090](https://phabricator.haskell.org/D3090) (#13194) broke `ghc-pkg`'s behavior in the face of non-existent package databases. Namely, `cabal install` fails during registration with,
```
Creating package registration fi...It seems that [D3090](https://phabricator.haskell.org/D3090) (#13194) broke `ghc-pkg`'s behavior in the face of non-existent package databases. Namely, `cabal install` fails during registration with,
```
Creating package registration file: /tmp/pkgConf-compact-0.1.0.1-13684/pkgConf
("/opt/exp/ghc/roots/master/bin/ghc-pkg",["update","-","--global","--user","-v2"])
/opt/exp/ghc/roots/master/bin/ghc-pkg returned ExitFailure 1 with error
message:
ghc-pkg: Couldn't open database
/home/ben/.ghc/x86_64-linux-8.1.20170227/package.conf.d for modification:
/home/ben/.ghc/x86_64-linux-8.1.20170227/package.conf.d.lock: openBinaryFile:
does not exist (No such file or directory)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Package database locking patch broke ghc-pkg with non-existent database","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"It seems that Phab:D3090 (#13194) broke `ghc-pkg`'s behavior in the face of non-existent package databases. Namely, `cabal install` fails during registration with,\r\n{{{\r\nCreating package registration file: /tmp/pkgConf-compact-0.1.0.1-13684/pkgConf\r\n(\"/opt/exp/ghc/roots/master/bin/ghc-pkg\",[\"update\",\"-\",\"--global\",\"--user\",\"-v2\"])\r\n/opt/exp/ghc/roots/master/bin/ghc-pkg returned ExitFailure 1 with error\r\nmessage:\r\nghc-pkg: Couldn't open database\r\n/home/ben/.ghc/x86_64-linux-8.1.20170227/package.conf.d for modification:\r\n/home/ben/.ghc/x86_64-linux-8.1.20170227/package.conf.d.lock: openBinaryFile:\r\ndoes not exist (No such file or directory)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/12673bkpcabal01 testcase fails with spurious output on stderr on Darwin2019-07-07T18:25:37ZBen Gamaribkpcabal01 testcase fails with spurious output on stderr on DarwinThe `bkpcabal01` testcase introduced the by Backpack merge fails on Mac OS X with,
```
=====> bkpcabal01(normal) 1 of 1 [0, 0, 0]
cd "./backpack/cabal/bkpcabal01/bkpcabal01.run" && $MAKE -s --no-print-directory bkpcabal01 CLEANUP=1
Ac...The `bkpcabal01` testcase introduced the by Backpack merge fails on Mac OS X with,
```
=====> bkpcabal01(normal) 1 of 1 [0, 0, 0]
cd "./backpack/cabal/bkpcabal01/bkpcabal01.run" && $MAKE -s --no-print-directory bkpcabal01 CLEANUP=1
Actual stderr output differs from expected:
--- /dev/null 2016-10-08 22:51:23.000000000 +0300
+++ ./backpack/cabal/bkpcabal01/bkpcabal01.run/bkpcabal01.run.stderr.normalised 2016-10-08 22:51:23.000000000 +0300
@@ -0,0 +1,4 @@
+/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/p-0.1+FBOSaiWyMx9DR2UZVI6wQJ/objs-36887/libHSp-0.1+FBOSaiWyMx9DR2UZVI6wQJ.a(H.o) has no symbols
+/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-36936/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a(I.o) has no symbols
+/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/p-0.1+FBOSaiWyMx9DR2UZVI6wQJ/objs-37078/libHSp-0.1+FBOSaiWyMx9DR2UZVI6wQJ.a(H.o) has no symbols
+/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-37123/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a(I.o) has no symbols
*** unexpected failure for bkpcabal01(normal)
```
It seems that the problem is that `ar` produces a warning when producing an archive file containing an object file with no symbols,
```
bkpcabal01 bgamari$ make SETUP="./Setup -v3" bkpcabal01
...
("/usr/bin/ar",["-r","-s","-v","dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-39951/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a","dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/Q.o","dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/I.o"])
ar: creating archive dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-39951/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a
a - dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/Q.o
a - dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/I.o
/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-39951/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a(I.o) has no symbols
```
In general it would be best if we could avoid linking these empty object files to avoid these spurious warnings.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ezyang |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"bkpcabal01 testcase fails with spurious output on stderr on Darwin","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ezyang"],"type":"Bug","description":"The `bkpcabal01` testcase introduced the by Backpack merge fails on Mac OS X with,\r\n\r\n{{{\r\n=====> bkpcabal01(normal) 1 of 1 [0, 0, 0]\r\ncd \"./backpack/cabal/bkpcabal01/bkpcabal01.run\" && $MAKE -s --no-print-directory bkpcabal01 CLEANUP=1 \r\nActual stderr output differs from expected:\r\n--- /dev/null\t2016-10-08 22:51:23.000000000 +0300\r\n+++ ./backpack/cabal/bkpcabal01/bkpcabal01.run/bkpcabal01.run.stderr.normalised\t2016-10-08 22:51:23.000000000 +0300\r\n@@ -0,0 +1,4 @@\r\n+/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/p-0.1+FBOSaiWyMx9DR2UZVI6wQJ/objs-36887/libHSp-0.1+FBOSaiWyMx9DR2UZVI6wQJ.a(H.o) has no symbols\r\n+/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-36936/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a(I.o) has no symbols\r\n+/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/p-0.1+FBOSaiWyMx9DR2UZVI6wQJ/objs-37078/libHSp-0.1+FBOSaiWyMx9DR2UZVI6wQJ.a(H.o) has no symbols\r\n+/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-37123/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a(I.o) has no symbols\r\n*** unexpected failure for bkpcabal01(normal)\r\n}}}\r\n\r\nIt seems that the problem is that `ar` produces a warning when producing an archive file containing an object file with no symbols,\r\n{{{\r\nbkpcabal01 bgamari$ make SETUP=\"./Setup -v3\" bkpcabal01\r\n...\r\n(\"/usr/bin/ar\",[\"-r\",\"-s\",\"-v\",\"dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-39951/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a\",\"dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/Q.o\",\"dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/I.o\"])\r\nar: creating archive dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-39951/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a\r\na - dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/Q.o\r\na - dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/I.o\r\n/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-39951/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a(I.o) has no symbols\r\n}}}\r\n\r\nIn general it would be best if we could avoid linking these empty object files to avoid these spurious warnings.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/12518Allow customizing immutable package dbs by stacking2019-07-07T18:26:16ZharendraAllow customizing immutable package dbs by stacking# Package Selection Across Multiple Package DBs
As explained by ezyang, when there are multiple package dbs, GHC chooses the packages to use in the following manner. I might have misunderstood so please correct me if I am wrong.
- If t...# Package Selection Across Multiple Package DBs
As explained by ezyang, when there are multiple package dbs, GHC chooses the packages to use in the following manner. I might have misunderstood so please correct me if I am wrong.
- If there are multiple packages with different versions the latest non-broken version is chosen.
- If the there are multiple packages with the same version the behavior is unspecified.
- If there are multiple packages with the same installed package id (shadowing) then the one which comes first in `GHC_PACKAGE_PATH` or which comes last on command line (according to `-package-db` flags) will be used.
# The Problem
The build tool `Stack` implements stacked package databases. It uses a base package database and then stacks another package database on top of it to customise it further without modifying. The behavior is such that the package db on top of the stack completely overrides the ones below. That means you choose a package from top of the stack even if the version is older.
Stack implements this by passing explicit package-ids of the packages to GHC. This scheme works well for cabal projects where we know ALL the packages used by the project in advance. But it does not work for scripts run using runghc. In that case we do not know the packages required by the script in advance and therefore cannot pass the package-ids to GHC. That means we cannot make GHC use the packages in the right way. GHC will choose the latest version even though we want it to choose a possibly older version from the top of the db stack.
# Proposed Solution
Implement a new CLI option, something like `--stacked-pkg-dbs`. If this option is used GHC will use `GHC_PACKAGE_PATH` or the `-package-db` options to specify a stack of dbs. The first db in the path or the last CLI option will be considered the top of the stack.
The default behavior of GHC is to union all databases whereas this feature is about vertically stacking them. The following stacking rules will apply:
- GHC will search a package from top to bottom and stop at the first db in which the package exists.
- If GHC is not looking for a specific version then it will stop at the first db in which ANY version is found.
- It will ignore the hidden packages when searching, but `-package <pkg>` will have the effect of unhiding all versions of `<pkg>`.
- If there are multiple versions available in the same db then usual rules of latest non-broken package will be used to select one.
- If the candidate package(s) found is broken it will not search further. When a broken package is needed in compilation it will report an error. It will not report errors in general when a broken package is encountered.
This will allow us to modify an immutable package db by stacking another db on top. Implementing this as a separate option will keep the existing behavior so as to remain backward compatible.
This has been discussed in a stack issue on github [here](https://github.com/commercialhaskell/stack/issues/1957).https://gitlab.haskell.org/ghc/ghc/-/issues/12485-package-db flags now need to be sorted by dependency order2019-07-07T18:26:24Zniteria-package-db flags now need to be sorted by dependency orderAfter 39b71e81ec1044518f065d0055676d713521e483 putting the -package-db flags in the wrong order will result in a compile error:
```
<command line>: cannot satisfy -package-id b-1-XXX:
b-1-XXX is unusable due to missing or recursive ...After 39b71e81ec1044518f065d0055676d713521e483 putting the -package-db flags in the wrong order will result in a compile error:
```
<command line>: cannot satisfy -package-id b-1-XXX:
b-1-XXX is unusable due to missing or recursive dependencies:
a-1-XXX
(use -v for more information)
```
See attached file for a repro.
It's reproduces in 8.0.1 and HEAD. Doesn't reproduce in GHC 7.10.3 or after reverting the above mentioned commit.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ezyang |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-package-db flags now need to be sorted by dependency order","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ezyang"],"type":"Bug","description":"After 39b71e81ec1044518f065d0055676d713521e483 putting the -package-db flags in the wrong order will result in a compile error:\r\n{{{\r\n<command line>: cannot satisfy -package-id b-1-XXX:\r\n b-1-XXX is unusable due to missing or recursive dependencies:\r\n a-1-XXX\r\n (use -v for more information)\r\n}}}\r\n\r\nSee attached file for a repro.\r\n\r\nIt's reproduces in 8.0.1 and HEAD. Doesn't reproduce in GHC 7.10.3 or after reverting the above mentioned commit.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.3https://gitlab.haskell.org/ghc/ghc/-/issues/12196ghc-pkg should drop trailing path separator when computing package database root2019-07-07T18:27:12ZBen Gamarighc-pkg should drop trailing path separator when computing package database rootReported on `ghc-devs@`,
Nicolas Dudebout \<nicolas.dudebout\@gmail.com\> writes,
> When passing a package database to ghc-pkg via `GHC_PACKAGE_PATH` or `--package-db`, `${pkgroot}` does not get computed properly if the input path cont...Reported on `ghc-devs@`,
Nicolas Dudebout \<nicolas.dudebout\@gmail.com\> writes,
> When passing a package database to ghc-pkg via `GHC_PACKAGE_PATH` or `--package-db`, `${pkgroot}` does not get computed properly if the input path contains a trailing slash.
>
> Default behavior:
>
> ```
> $ ghc-pkg describe base | grep pkgroot
> pkgroot: "/usr/lib/ghc-7.10.2"
> ```
>
> Correct behavior (no trailing slash):
>
> ```
> $ ghc-pkg --package-db /usr/lib/ghc-7.10.2/package.conf.d describe base
> | grep pkgroot
> pkgroot: "/usr/lib/ghc-7.10.2"
>
> $ GHC_PACKAGE_PATH=/usr/lib/ghc-7.10.2/package.conf.d ghc-pkg describe
> base | grep pkgroot
> pkgroot: "/usr/lib/ghc-7.10.2"
> ```
>
> Incorrect behavior (with trailing slash):
>
> ```
> $ ghc-pkg --package-db /usr/lib/ghc-7.10.2/package.conf.d/ describe
> base | grep pkgroot
> pkgroot: "/usr/lib/ghc-7.10.2/package.conf.d"
>
> $ GHC_PACKAGE_PATH=/usr/lib/ghc-7.10.2/package.conf.d/ ghc-pkg describe
> base | grep pkgroot
> pkgroot: "/usr/lib/ghc-7.10.2/package.conf.d"
> ```
>
> When this bug happens, `ghc-pkg` check complains about missing files for
> packages using `${pkgroot}`.
>
> This bug happens because `${pkgroot}` is computed using `takeDirectory`. It
> should instead use `(takeDirectory . dropTrailingPathSeparator)`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | nicolas.dudebout@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc-pkg should drop trailing path separator when computing package database root","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"8.0.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["nicolas.dudebout@gmail.com"],"type":"Bug","description":"Reported on `ghc-devs@`,\r\n\r\n\r\nNicolas Dudebout <nicolas.dudebout@gmail.com> writes,\r\n\r\n> When passing a package database to ghc-pkg via `GHC_PACKAGE_PATH` or `--package-db`, `${pkgroot}` does not get computed properly if the input path contains a trailing slash.\r\n> \r\n> Default behavior:\r\n> {{{\r\n> $ ghc-pkg describe base | grep pkgroot\r\n> pkgroot: \"/usr/lib/ghc-7.10.2\"\r\n> }}}\r\n> \r\n> Correct behavior (no trailing slash):\r\n> {{{\r\n> $ ghc-pkg --package-db /usr/lib/ghc-7.10.2/package.conf.d describe base\r\n> | grep pkgroot\r\n> pkgroot: \"/usr/lib/ghc-7.10.2\"\r\n> \r\n> $ GHC_PACKAGE_PATH=/usr/lib/ghc-7.10.2/package.conf.d ghc-pkg describe\r\n> base | grep pkgroot\r\n> pkgroot: \"/usr/lib/ghc-7.10.2\"\r\n> }}}\r\n> \r\n> Incorrect behavior (with trailing slash):\r\n> {{{\r\n> $ ghc-pkg --package-db /usr/lib/ghc-7.10.2/package.conf.d/ describe\r\n> base | grep pkgroot\r\n> pkgroot: \"/usr/lib/ghc-7.10.2/package.conf.d\"\r\n> \r\n> $ GHC_PACKAGE_PATH=/usr/lib/ghc-7.10.2/package.conf.d/ ghc-pkg describe\r\n> base | grep pkgroot\r\n> pkgroot: \"/usr/lib/ghc-7.10.2/package.conf.d\"\r\n> }}}\r\n> \r\n> When this bug happens, `ghc-pkg` check complains about missing files for\r\n> packages using `${pkgroot}`.\r\n> \r\n> This bug happens because `${pkgroot}` is computed using `takeDirectory`. It\r\n> should instead use `(takeDirectory . dropTrailingPathSeparator)`.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/12154GHC 8.0.1 x64 Windows installer doesn't honor custom install location2019-07-07T18:27:26ZscsGHC 8.0.1 x64 Windows installer doesn't honor custom install locationThe GHC Windows installer has (thankfully!) the option for a preferred custom install location, in my case 'c:\\devel\\Haskell\\8' (beside 'c:\\devel\\Haskell\\WinHugs' etc.) However, it obstinately installs into 'c:\\Program Files\\Hask...The GHC Windows installer has (thankfully!) the option for a preferred custom install location, in my case 'c:\\devel\\Haskell\\8' (beside 'c:\\devel\\Haskell\\WinHugs' etc.) However, it obstinately installs into 'c:\\Program Files\\Haskell Platform\\yada yada...' The _uninstaller_ operates with the custom location, and the uninstallation therefore fails.
Potential triggers: disallowing the installer to muck with the environment path and registry (I set these myself, thank you very much).
Workaround: GHC is thankfully still self contained, and moving the installation to the preferred location suffices.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC 8.0.1 x64 Windows installer doesn't honor custom install location","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The GHC Windows installer has (thankfully!) the option for a preferred custom install location, in my case 'c:\\devel\\Haskell\\8' (beside 'c:\\devel\\Haskell\\WinHugs' etc.) However, it obstinately installs into 'c:\\Program Files\\Haskell Platform\\yada yada...' The _uninstaller_ operates with the custom location, and the uninstallation therefore fails.\r\n\r\nPotential triggers: disallowing the installer to muck with the environment path and registry (I set these myself, thank you very much).\r\n\r\nWorkaround: GHC is thankfully still self contained, and moving the installation to the preferred location suffices.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/11696Windows Install Makes Unnecessary/Incorrect PATH Changes2019-07-07T18:29:03ZAlexAndrewsWindows Install Makes Unnecessary/Incorrect PATH ChangesI installed haskell 7.10.3 (32-bit) under Windows XP SP3 into a folder on my L: drive. However, the installation process added a number of non-existent directories to my PATH variables:
User environment variable PATH:
> C:\\Documents a...I installed haskell 7.10.3 (32-bit) under Windows XP SP3 into a folder on my L: drive. However, the installation process added a number of non-existent directories to my PATH variables:
User environment variable PATH:
> C:\\Documents and Settings\\\<username\>\\Application Data\\cabal\\bin
System environment variable PATH:
> C:\\Program Files\\Haskell\\bin
If these directories need to be in the PATH variables, they should be created by the installer and, if so, since I installed haskell to my L: drive, surely these should be created on my L: drive (or the user should be prompted for their location)?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.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":"Windows Install Makes Unnecessary/Incorrect PATH Changes","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.3","keywords":["environment","install","path","variable"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I installed haskell 7.10.3 (32-bit) under Windows XP SP3 into a folder on my L: drive. However, the installation process added a number of non-existent directories to my PATH variables:\r\n\r\nUser environment variable PATH:\r\n\r\n C:\\Documents and Settings\\<username>\\Application Data\\cabal\\bin\r\n\r\nSystem environment variable PATH:\r\n\r\n C:\\Program Files\\Haskell\\bin\r\n\r\nIf these directories need to be in the PATH variables, they should be created by the installer and, if so, since I installed haskell to my L: drive, surely these should be created on my L: drive (or the user should be prompted for their location)?","type_of_failure":"OtherFailure","blocking":[]} -->