GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2020-01-20T21:34:37Zhttps://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/17191Split configure script2024-02-09T21:09:44ZJohn EricsonSplit configure script## Motivation
We're getting pretty close to being done making GHC multi-target. One consequence of this is that GHC itself won't depend on the vast majority of the `@vars@` from configure. Only src-determined things like `@ProjectVersio...## Motivation
We're getting pretty close to being done making GHC multi-target. One consequence of this is that GHC itself won't depend on the vast majority of the `@vars@` from configure. Only src-determined things like `@ProjectVersionMunged@`, `@LlvmVersion@`, etc. are still needed project-wide.
What I propose then is we strip down the root `configure.ac` to just substitute those platform-agnostic variables with no dynamic checks, and push the vast majority of the configure checks into package-specific configure scripts rts, inter-gmp, and base. The `settings` file does depend on a number of configure checks, but it can be either an extra file installed by the `rts`, which makes sense is it basically is saying how to produce Haskell which works with a given RTS, or get it's own configure script. As usual, the `m4` directory means we an share as much logic as we like between these scripts.
This has a number of benefits:
0. Running top-level configure should only make changes that are "safe for sdist". E.g. we can put all the versions in the cabal files and then sdist each cabal package. C.f. !5965.
1. Prevents regressions with multi-target: Compiler doesn't know about the target platform by construction, so it cannot be biased towards one or another.
2. Slightly more parallelism: we can immediately start building the compiler.
3. Better incremental builds: Changing configure results will no longer invalidate the stage 0 compiler build via `ghcautoconf.h`. More broadly each package only sees the options it cares about, so smaller incremental benefits for the other libs.
5. One step closer to `cabal build ghc` for a stage 0 compiler. Running the meta-configure is trivial preprocessor step that also could be done in `./boot` instead of autoconf as follow up work. Then the only thing blocking the cabal-built compilers is code gen executables `genprimmops`. But we have `build-tool-depends` already to hack something up, and longer term I hope https://github.com/ghc-proposals/ghc-proposals/pull/243 means it can all become TH.
I'll try to avoid controversy by *not* including getting rid of autoconf in the above list :). My view is this split delivers most of the benefit of that, and right now `configure.ac` is too big and monolithic to assess how much we depend on autoconf and where. With this change any renewed talk on purging autoconf will be a better evidence-based discussion.
## Things that get configured today
Good to keep in mind.
- `ghcautoconf.h`, from `AC_DEFINE`, via `mk/config.h`
- `settings` files per stage, originally directly via type level configure, now indirectly via make/hadrian
- Build system config files, from `AC_SUBST`:
- `hadrian/cfg/system.config`
- `mk/config.mk`
## Roadmap
### Prep Make build system
It turns out there was a few things to do with the make build system to make it better cope with the RTS having a configure script, and generally anticipate the goals here.
- [x] !6816
- [x] !6821
- [x] !6817
- [x] !6819
- [x] !6869
- [x] !6864
- [x] !6908
- [x] !6833 Make: Do not generate ghc.* headers in stage
- [x] !6966
- [x] !6977
- [x] !6978
- [x] !6989
### Prep Hadrian changes
- [x] !6953 Hadrian: bring up to date with latest make improvements
- [x] !6978
### Prep Autoconf changes
- [x] !6828 modularize platform detection.
- [x] !6836 Separate some `AC_SUBST` / `AC_DEFINE`
- [x] !6927 Factor out unregisterised and tables next to code m4 macros
- [x] !6931 Factor out more m4 macros
- [x] !6964
### Other prep
- [x] !6216 Move `/includes` to `/rts/include`, sort per package better
- [x] !6839 Avoid GHC_STAGE and other include bits
- [x] !6791 / !6920 Compiler is target agnostic!
- [x] !6963 Generate ghcversion.h with the top-level configure
- [x] !6987
- [x] !7100
- [x] !9627 Remove hack for building RTS that gets in the way of `build-type: Simple`.
### Intro RTS Configure script
A beachhead!
- [x] !6822 (optional intermediate step) do blank RTS configure script before moving anything over.
- [x] !9760 Bump Cabal so configure script can detect cabal flags.
- [x] !9756 Move extern symbols logic
### Headers generated RTS side.
Hadrian can still tell RTS what the configuration is (the RTS configure script wont't yet decide for itself), but `ghcautoconf.h` and `ghcplatform.h` are made in the RTS configure script. `mk/config.h` can be deleted.
### Rest of RTS-oriented configure logic.
The RTS is able to figure out its configuration without relying on correctly-set manual Cabal flags.
Perhaps the RTS will contain some settings info that Hadrian reads (c.f. #22686) i.e. it could be a source of truth.
1. [x] !11311
2. [x] !11319
3. [x] !11317
4. [x] !11318
4. [x] !11322
5. [x] !6803
### Slim down Cabal Flags for RTS
With the logic from before moved into the RTS configure script, there is often no need to make decision from the outside --- just let the RTS configure script make its own private choice.
We can do that and get rid of a bunch of Hadrian logic.
- [x] !9269 / `wip/rts-configure-scrap-cabal-flags`
### Get rid of rest of configure script
See
- #24008
- #23966
### `genapply` shouldn't take RTS headers at compile time
If the RTS is built standalone, there it will be annoying to *build* genapply at *RTS configure* time. We should do something different -- like make genapply take the info at runtime so we can use a prebuilt genapply.
### Create configure script for settings file.
Many decisions however need to effect both RTS and settings file. At a minimum, we can share `m4` logic between projects, but we may also want to make (part of) the settings file during the RTS build.
Some settings effectively indicate choices where the RTS and GHC must agree, so deciding twice and hoping the system-snooping is deterministic is sketch. Other settings like what tools to use are naturally independent.
Note it is precisely second sort that the bindist will configure today.
### Possible prepare stage-wide configure more like status-quo-ante for hadrian/make
While it's important than components can be configured separately to untangle our current mess, hadrian/make might continue to want to make some settings across projects. Concretely, *something* need to fill in their settings input files, `hadrian/cfg/system.config`, and `mk/config.mk`.
We can have our cake and eat it too by keeping enough logic in `m4` files to create a "stage-wide" configure script.
(Remember, per https://gitlab.haskell.org/ghc/ghc/-/wikis/cross-compilation/roadmap bootstrapping is an infinite tree to explore, not a single chain, let alone a finite 3 stage chain! So stage-wide config files vs one master config files makes much more sense as input to Hadrian/Make.)
Additionally, we should enhance the autoconf macros to ensure every decision solved by the "outer" configure is not re-decided by the per-package configures. That means adding enough configure flags so the decisions can be "told" by make/hadrian to RTS/base/unix/whatever.
This last step might sound like it is undermining the whole project: what's the point of moving all the logic to per-package configure scripts if we are just going to centrally configure the decisions anyways?! Remember, only make/hadrian parameters that are either inspected/eliminated by the outer build system or "aliased" to multiple packages need be in the outer configure. The vast majority of stuff is just needed by on package (usually the RTS), or was `AC_DEFINED` and already bypasses the output build system going straight from autoconf to the headers. All such things need never be configured from the stage-wide configure script, and should purely be per-stage.
Also, downstream packaging like Haskell.nix or Nixpkgs will probably stop using Make/Hadrian, and thus bypass any stage-wide configuring, but will use the per-package configures. In general "whole compilers" should be thought of as mini-distros and not single packages, and thus our Make/Hadrian are more like package managers / multiple monorepo build systems (like the original BSD monorepo).
CC @angerman @alp @bgamari @hvr @nomeata @snowleopard @hsyl20 @nrnrnrhttps://gitlab.haskell.org/ghc/ghc/-/issues/16879Hide "Loading package environment" message2019-08-25T01:30:04ZGuillaume BouchardHide "Loading package environment" message# Motivation
#15145 introduced a new log message when a package database is loaded from a file. I'd like a way to hide this message. I tested with `-v0`, without success.
This poses problem in build system, such as bazel / rules_haskel...# Motivation
#15145 introduced a new log message when a package database is loaded from a file. I'd like a way to hide this message. I tested with `-v0`, without success.
This poses problem in build system, such as bazel / rules_haskell, were the output is spammed by this message for each compiler step. See https://github.com/tweag/rules_haskell/issues/969
Example:
```
[nix-shell:~]$ touch .ghc.environment.x86_64-linux-8.6.3
[nix-shell:~]$ ghc
Loaded package environment from /home/guillaume/.ghc.environment.x86_64-linux-8.6.3
ghc: no input files
Usage: For basic information, try the `--help' option.
```
The `Loaded package environment from ...` is annoying.
# Proposal
Apparenly that's a log message with `SevInfo`. I did not found anyway to filter theses log messages. I tried `-v0`, or `-ddump-to-file` without success. `-ddump-json` changes the format of the output, but this stays in stderr.
I'll be happy to know another option to disable that or to have an option to disable log message based on severity.8.10.1Artem PelenitsynArtem Pelenitsynhttps://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":[]} -->