GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2023-01-26T21:42:58Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/22732Don't reuse `hsLibraries` field of InstalledPackageInfo for native libraries2023-01-26T21:42:58ZBen GamariDon't reuse `hsLibraries` field of InstalledPackageInfo for native librariesIn https://gitlab.haskell.org/ghc/ghc/-/issues/22564#note_468545 we noted that users of the `extra-bundled-libraries` field are saddled with the unfortunate requirement of naming their native libraries with a `libC` prefix (specified in ...In https://gitlab.haskell.org/ghc/ghc/-/issues/22564#note_468545 we noted that users of the `extra-bundled-libraries` field are saddled with the unfortunate requirement of naming their native libraries with a `libC` prefix (specified in the Cabal [reference documentation](https://cabal.readthedocs.io/en/stable/cabal-package.html#pkg-field-extra-bundled-libraries)).
The requirement is due to the strange implementation of `extra-bundled-libraries`: "bundled" libraries are added to the `hsLibraries` field of `InstalledPackageInfo`, leaving the runtime linker with an ambiguity regarding whether the library is a Haskell object (in which case it may need a "way" suffix in its name) or native object. The required `libHS`/`libC` prefix allows the linker to resolve this ambiguity.
IMHO it would be much better if `extra-bundled-libraries` were instead implemented in terms of a new `InstalledPackageInfo` field, eliminating the ambiguity by construction.https://gitlab.haskell.org/ghc/ghc/-/issues/20759Wire up library-dirs-static and extra-libraries-static in GHC2021-12-12T07:36:38ZAlex BiehlWire up library-dirs-static and extra-libraries-static in GHCWith the new fields `library-dirs-static` and `extra-libraries-static` InstalledPackageInfo supports a way to specify libraries for static linking separately from `extra-libraries`/`library-dirs`. This allows us to switch smoothly betwee...With the new fields `library-dirs-static` and `extra-libraries-static` InstalledPackageInfo supports a way to specify libraries for static linking separately from `extra-libraries`/`library-dirs`. This allows us to switch smoothly between dynamic and static linking of system libraries.
Cabal and cabal-install already do the right thing and populate the new fields when using pkg-config-depends.
What's left is the GHC side of things:
- [x] Bump GHC's Cabal dependency to support `library-dirs-static` and `extra-libraries-static`. This has been done.
- [ ] Introduce `library-dirs-static` and `extra-libraries-static` to ghc-pkg
- [ ] When statically linking an executable consult above fields for extra libraries to link (instead of always consulting `extra-libraries`/`library-dirs` as we do now)https://gitlab.haskell.org/ghc/ghc/-/issues/24399-hide-package doesn't play nice with -package-env2024-02-06T15:15:15ZSimon Hengelsol@typeful.net-hide-package doesn't play nice with -package-env## Summary
When I use `-hide-package` in combination with `-package-env` then it seems to have no effect.
## Steps to reproduce
With `cabal-install-3.10.2.1`:
```
$ tree
.
├── foo.cabal
└── src
└── Prelude.hs
```
```cabal
cabal-v...## Summary
When I use `-hide-package` in combination with `-package-env` then it seems to have no effect.
## Steps to reproduce
With `cabal-install-3.10.2.1`:
```
$ tree
.
├── foo.cabal
└── src
└── Prelude.hs
```
```cabal
cabal-version: 3.8
name: foo
version: 0.0.0
library
build-depends: base
mixins: base (Prelude as BasePrelude)
hs-source-dirs: src
exposed-modules: Prelude
```
```haskell
{-# LANGUAGE NoImplicitPrelude #-}
module Prelude where
import BasePrelude
foo :: Int
foo = 23
```
```
$ cabal install --package-env=package.env --lib
$ ghci -package-env=package.env -hide-package=base
ghci> import Prelude
<no location info>: error: [GHC-45102]
Ambiguous module name ‘Prelude’.
it was found in multiple packages: base-4.19.0.0 foo-0.0.0
```
## Expected behavior
The module `Prelude` from package `foo` is used.
## Environment
* GHC version used: 9.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/24120Unused Package Warning for `system-cxx-std-lib` Dependency2023-11-14T15:17:12ZjulianbrunnerUnused Package Warning for `system-cxx-std-lib` Dependency## Summary
When building a package depending on `system-cxx-std-lib` while using `-Wunused-packages`, the package `system-cxx-std-lib` is reported as unused.
## Steps to reproduce
I have a library specification that looks like this:
`...## Summary
When building a package depending on `system-cxx-std-lib` while using `-Wunused-packages`, the package `system-cxx-std-lib` is reported as unused.
## Steps to reproduce
I have a library specification that looks like this:
```
library
default-language: GHC2021
ghc-options: -Wall -Wno-name-shadowing -Wunused-packages
build-depends: base, system-cxx-std-lib
hs-source-dirs: source
exposed-modules: RTAudio.Audio
cxx-options: -Wall
cxx-sources: rtaudio/rtaudio_c.cpp rtaudio/RtAudio.cpp
```
When compiled, this produces the following warning:
```
<no location info>: warning: [GHC-42258] [-Wunused-packages]
The following packages were specified via -package or -package-id flags,
but were not needed for compilation:
- system-cxx-std-lib-1.0 (exposed by flag -package-id system-cxx-std-lib-1.0)
```
## Expected behavior
The package `system-cxx-std-lib` is actually used. The compilation fails with undefined references to C++ standard library symbols when it is not mentioned in `build-depends`. Thus, the package should not be reported as "not needed for compilation".
## Environment
* GHC version used: 9.6.3
Optional:
* Operating System: Arch Linux
* System Architecture: x649.10.1Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/23653Add `-fprint-unit-ids` and hide printing of unit-ids by default.2023-08-14T09:09:25ZOleg GrenrusAdd `-fprint-unit-ids` and hide printing of unit-ids by default.Output like
```
... (servant-0.19.1-2766f5fde1349996d1634ebb37647b1723dacd28547ecaafe0e93e4cfa5eec79:Servant.API.ReqBody.ReqBody
'[servant-0.19.1-2766f5fde1349996d1634ebb37647b1723dacd28547ecaafe0e93e4cfa5eec79:Servant.API.ContentTypes....Output like
```
... (servant-0.19.1-2766f5fde1349996d1634ebb37647b1723dacd28547ecaafe0e93e4cfa5eec79:Servant.API.ReqBody.ReqBody
'[servant-0.19.1-2766f5fde1349996d1634ebb37647b1723dacd28547ecaafe0e93e4cfa5eec79:Servant.API.ContentTypes.JSON]
```
is usually not helpful.
I think hiding full unit-ids by default would make output a lot cleaner (when things are not in scope).
A middleground would be to print *package name* (which I guess is somewhat easily available as `PackageImports` uses it), i.e.
```
... (servant:Servant.API.ReqBody.ReqBody '[servant:Servant.API.ContentTypes.JSON]
```Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/22960EPS contention may be slowing down parallel make2023-02-27T20:15:03ZTeo CamarasuEPS contention may be slowing down parallel make### Summary
I think it's likely that contention of the EPS is blocking parallel make from reaching its full potential on large shallow module graphs.
The EPS is stored in a global IORef and is regularly checked during typechecking.
If a...### Summary
I think it's likely that contention of the EPS is blocking parallel make from reaching its full potential on large shallow module graphs.
The EPS is stored in a global IORef and is regularly checked during typechecking.
If an interface hasn't yet been loaded, then it will be loaded, typecheched (potentially loading further interfaces), and then atomically merged with the current value of the EPS.
From a quick glance at the code I'm seeing two potential issues:
1) Duplicated work due to two threads racing:
In a situation where two threads both discover that an interface is missing from the EPS, I think, they will duplicate work to load it.
2) Atomically updating the EPS blocks reads:
AFAIK using `atomicModifyIORef'` blocks reads, as it updates the IORef with a thunk that it then evaluates. While the thunk is under evaluation, other threads will be blocked if they try to look at it.
I say potential issues because I haven't done enough investigating to confirm if this is actually an issue.
I'll try to do that in the next couple of weeks and come up with some strategies to mitigate it if it does turn out to be a problem.
### Context
I was led to the EPS by looking at the DWARF decoded stacks of threads blocking on blackholes while compiling `Cabal`.
Code that was looking things up in the EPS stood out to me. I used this branch of ghc https://gitlab.haskell.org/teo/ghc/-/commits/wip/blackhole-introspectionBen GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/21170Accommodate build systems with their own notion of package names2022-03-09T17:59:06ZAndrew PritchardAccommodate build systems with their own notion of package names## Motivation
Large-scale multi-language build systems like Bazel have their own notion of package identity different from Cabal's flat alphanumeric-plus-hyphens package names. When building Haskell code with these systems, collections...## Motivation
Large-scale multi-language build systems like Bazel have their own notion of package identity different from Cabal's flat alphanumeric-plus-hyphens package names. When building Haskell code with these systems, collections of Haskell modules might have names like `//some/path:my_library` rather than, say, `distributive`. Current integrations with these systems have to work around the package name validation, e.g. by using only the last path component (https://github.com/tweag/rules_haskell/blob/dfd0161264b3e1ca8e47c30ef258d50e754570fc/haskell/private/pkg_id.bzl#L45) or encoding the label into the set of allowed characters (https://github.com/google/cabal2bazel/blob/master/bzl/private/package.bzl#L32-L55), leading to ugly and confusing package names like `someS-SpathS-SmyU-Ulibrary` in various contexts (compiler command lines, package-qualified import syntax, occasionally type errors, and probably others).
More generally, complex builds may identify components with hierarchical paths, and it'd be good to allow them to use their own naming scheme for the corresponding GHC packages without needing to encode them into a highly-restricted set of characters.
## Proposal
Change GHC and (if necessary) the Cabal library to allow non-Cabal build systems to use their own preferred formatting for package names (without changing the package naming rules for Hackage or the Cabal build tool). An existing Bazel-specific patch already exists, which accepts Bazel label syntax as package names in GHC flags, package-qualified import syntax, and the Cabal parsers, but it might need to be more general-purpose in order to be merged.https://gitlab.haskell.org/ghc/ghc/-/issues/20888MHU: Package thinning/renaming not supported properly2023-07-18T07:32:47ZMatthew PickeringMHU: Package thinning/renaming not supported properlyThe way multiple home units calculate dependencies currently ignores any thinning/renaming specifications. This feature is rarely used so it doesn't matter too much for testing but will be subtly broken if anyone does try and use it.
S...The way multiple home units calculate dependencies currently ignores any thinning/renaming specifications. This feature is rarely used so it doesn't matter too much for testing but will be subtly broken if anyone does try and use it.
See `selectHomeUnits` in `GHC.Unit.State` for the start of where needs to be changed. Then the thinning specification needs to be carried all the way through to the Finder logic and applied accordingly.
Documentation - https://downloads.haskell.org/~ghc/8.8.1/docs/html/users_guide/packages.html#thinning-and-renaming-moduleshttps://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/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/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/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/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/11286ghc-pkg library2023-03-13T17:14:21ZEdward Z. Yangghc-pkg libraryOn Twitter, Anthony Cowley was wondering why there was no GHC API functions for taking Cabal InstalledPackageInfos and turning them into GHC InstalledPackageInfos. https://twitter.com/a_cowley/status/680158885953564672
No such interface...On Twitter, Anthony Cowley was wondering why there was no GHC API functions for taking Cabal InstalledPackageInfos and turning them into GHC InstalledPackageInfos. https://twitter.com/a_cowley/status/680158885953564672
No such interface exists: to keep GHC decoupled from Cabal, the GHC package representation is mediated solely by `ghc-pkg`, so the "correct" way to create a package config file, run `ghc-pkg` to load it into the GHC binary representation, and go from there.
It seems like it would be convenient if `ghc-pkg` was libified, and so people who linked against GHC and Cabal could just directly do the conversion without going through `ghc-pkg`. It's unclear what the right interface is; ghc-pkg does a number of sanity checks and it's unclear if those should be libified too. Any such library also must be uploaded to Hackage, because if you want to link against a newer version of Cabal you have to rebuild the ghc-pkg library against the newest version of Cabal.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.11 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | acowley |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc-pkg library","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["acowley"],"type":"FeatureRequest","description":"On Twitter, Anthony Cowley was wondering why there was no GHC API functions for taking Cabal InstalledPackageInfos and turning them into GHC InstalledPackageInfos. https://twitter.com/a_cowley/status/680158885953564672\r\n\r\nNo such interface exists: to keep GHC decoupled from Cabal, the GHC package representation is mediated solely by `ghc-pkg`, so the \"correct\" way to create a package config file, run `ghc-pkg` to load it into the GHC binary representation, and go from there.\r\n\r\nIt seems like it would be convenient if `ghc-pkg` was libified, and so people who linked against GHC and Cabal could just directly do the conversion without going through `ghc-pkg`. It's unclear what the right interface is; ghc-pkg does a number of sanity checks and it's unclear if those should be libified too. Any such library also must be uploaded to Hackage, because if you want to link against a newer version of Cabal you have to rebuild the ghc-pkg library against the newest version of Cabal.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/11124GHC does not shadow -package-name/-this-package-key2019-07-07T18:31:51ZEdward Z. YangGHC does not shadow -package-name/-this-package-keySteps to reproduce:
1. Install a package named `a` with these contents:
\*\*a.cabal\*\*
```
name: a
version: 0.1.0.0
cabal-version: >=1.10
library
exposed-modules: A
build-depends: bas...Steps to reproduce:
1. Install a package named `a` with these contents:
\*\*a.cabal\*\*
```
name: a
version: 0.1.0.0
cabal-version: >=1.10
library
exposed-modules: A
build-depends: base
```
- \*A.hs\*\*
```
module A where
data A = A String
```
> Note what unit ID/package key/package name the package installs as. On GHC 7.8 it will be something like `a-0.1.0.0`, on GHC 7.10 it will be something like `a_LKCPrTJwOTOLk4OU37YmeN`, on GHC 8.0 it will be something like `a-0.1.0.0-LKCPrTJwOTOLk4OU37Yme`.
1. Install a package named `b` with these contents:
\*\*b.cabal\*\*
```
name: b
version: 0.1.0.0
cabal-version: >=1.10
library
exposed-modules: B
build-depends: base, a
```
- \*b.hs\*\*
```
module B where
import A
b = A "foo"
```
1. Go back to `a`, and load `A.hs` in GHCi with `ghci A.hs -package-name a-0.1.0.0 -package-db ../db`. Notice that we can `import B` from this GHCi session:
```
ezyang@sabre:~/Dev/labs/ii/a$ ghci A.hs -package-name a-0.1.0.0 -package-db ../db
GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling A ( A.hs, interpreted )
Ok, modules loaded: A.
*A> import B
*A B> b
Loading package a-0.1.0.0 ... linking ... done.
Loading package b-0.1.0.0 ... linking ... done.
A "asdfsdf"
*A B>
Leaving GHCi.
```
1. Edit `A.hs` so that now contains:
```
module A where
data A = A Int
```
1. Load in GHCi again:
```
ezyang@sabre:~/Dev/labs/ii/a$ ghci A.hs -package-name a-0.1.0.0 -package-db ../db
GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling A ( A.hs, interpreted )
Ok, modules loaded: A.
*A> import B
*A B> b
Loading package a-0.1.0.0 ... linking ... done.
Loading package b-0.1.0.0 ... linking ... done.
A 3458765062984598387
```
Disaster!
Actually, this bug is relatively harmless:
1. If you try to actually reinstall package a, that's a "dangerous" reinstall and it's known that reinstalls can break things.
1. It's hard to convince Cabal to trigger this, since importing `B` requires `b` in the build-depends, and that would constitute a circular package dependency. (You can't separate it out because of (1))
1. If you don't specify `-package-name` (or similar) the local `A` and the remote `A` will have different identities, no problem.
1. When you do specify `-package-name`, you can't build a main executable (so the only way to run is by loading into GHCi, as shown above.)
1. Sometimes, GHCi will notice that something is amiss if it tries to load the object file for both the remote A and the local A.
But the fix seems simple: if a user specifies `-package-name`, it should be AS IF they also specified `-ignore-package`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC does not shadow -package-name/-this-package-key","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Steps to reproduce:\r\n\r\n1. Install a package named `a` with these contents:\r\n\r\n **a.cabal**\r\n{{{\r\nname: a\r\nversion: 0.1.0.0\r\ncabal-version: >=1.10\r\n\r\nlibrary\r\n exposed-modules: A\r\n build-depends: base\r\n}}}\r\n\r\n **A.hs**\r\n{{{\r\nmodule A where\r\ndata A = A String\r\n}}}\r\n\r\n Note what unit ID/package key/package name the package installs as. On GHC 7.8 it will be something like `a-0.1.0.0`, on GHC 7.10 it will be something like `a_LKCPrTJwOTOLk4OU37YmeN`, on GHC 8.0 it will be something like `a-0.1.0.0-LKCPrTJwOTOLk4OU37Yme`.\r\n\r\n2. Install a package named `b` with these contents:\r\n\r\n **b.cabal**\r\n{{{\r\nname: b\r\nversion: 0.1.0.0\r\ncabal-version: >=1.10\r\n\r\nlibrary\r\n exposed-modules: B\r\n build-depends: base, a\r\n}}}\r\n\r\n **b.hs**\r\n{{{\r\nmodule B where\r\nimport A\r\nb = A \"foo\"\r\n}}}\r\n\r\n3. Go back to `a`, and load `A.hs` in GHCi with `ghci A.hs -package-name a-0.1.0.0 -package-db ../db`. Notice that we can `import B` from this GHCi session:\r\n\r\n{{{\r\nezyang@sabre:~/Dev/labs/ii/a$ ghci A.hs -package-name a-0.1.0.0 -package-db ../db\r\nGHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\n[1 of 1] Compiling A ( A.hs, interpreted )\r\nOk, modules loaded: A.\r\n*A> import B\r\n*A B> b\r\nLoading package a-0.1.0.0 ... linking ... done.\r\nLoading package b-0.1.0.0 ... linking ... done.\r\nA \"asdfsdf\"\r\n*A B> \r\nLeaving GHCi.\r\n}}}\r\n\r\n3. Edit `A.hs` so that now contains:\r\n\r\n{{{\r\nmodule A where\r\ndata A = A Int\r\n}}}\r\n\r\n4. Load in GHCi again:\r\n\r\n{{{\r\nezyang@sabre:~/Dev/labs/ii/a$ ghci A.hs -package-name a-0.1.0.0 -package-db ../db\r\nGHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\n[1 of 1] Compiling A ( A.hs, interpreted )\r\nOk, modules loaded: A.\r\n*A> import B\r\n*A B> b\r\nLoading package a-0.1.0.0 ... linking ... done.\r\nLoading package b-0.1.0.0 ... linking ... done.\r\nA 3458765062984598387\r\n}}}\r\n\r\nDisaster!\r\n\r\nActually, this bug is relatively harmless:\r\n\r\n1. If you try to actually reinstall package a, that's a \"dangerous\" reinstall and it's known that reinstalls can break things.\r\n2. It's hard to convince Cabal to trigger this, since importing `B` requires `b` in the build-depends, and that would constitute a circular package dependency. (You can't separate it out because of (1))\r\n3. If you don't specify `-package-name` (or similar) the local `A` and the remote `A` will have different identities, no problem.\r\n4. When you do specify `-package-name`, you can't build a main executable (so the only way to run is by loading into GHCi, as shown above.)\r\n5. Sometimes, GHCi will notice that something is amiss if it tries to load the object file for both the remote A and the local A.\r\n\r\nBut the fix seems simple: if a user specifies `-package-name`, it should be AS IF they also specified `-ignore-package`.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/11023ghci and ghc-pkg disagree about what's exposed2019-07-07T18:32:34Zdmwitghci and ghc-pkg disagree about what's exposedI have installed vector-0.10.12.3 and vector-0.11.0.0. At some point, I had hidden both from the package database; however, I later used ghc-pkg expose to mark one as visible again. Now I seem to be in a strange state where ghci and ghc-...I have installed vector-0.10.12.3 and vector-0.11.0.0. At some point, I had hidden both from the package database; however, I later used ghc-pkg expose to mark one as visible again. Now I seem to be in a strange state where ghci and ghc-pkg disagree about what is hidden:
```
% ghci-7.10.2
GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help
Prelude> :m +Data.Vector.Unboxed
<no location info>:
Could not find module ‘Data.Vector.Unboxed’
It is a member of the hidden package ‘vector-0.11.0.0@vecto_3jMaUrldidp1bqsrn0qsS2’.
It is a member of the hidden package ‘vector-0.10.12.3@vecto_1COyUuV1LrA1IjYnWfJnbs’.
Prelude>
Leaving GHCi.
% ghc-pkg-7.10.2 list vector | cat
/usr/local/lib/ghc-7.10.2/package.conf.d:
(no packages)
/home/dmwit/.ghc/x86_64-linux-7.10.2/package.conf.d:
vector-0.10.12.3
(vector-0.11.0.0)
% ghc-pkg-7.10.2 describe vector-0.10.12.3 | grep 'key:\|exposed:'
key: vecto_1COyUuV1LrA1IjYnWfJnbs
exposed: True
```
I have tried reproducing this with other packages in a handful of ways and failed; so I can't give instructions for reproducing. But I am happy to perform any diagnostics you can think of.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghci and ghc-pkg disagree about what's exposed","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have installed vector-0.10.12.3 and vector-0.11.0.0. At some point, I had hidden both from the package database; however, I later used ghc-pkg expose to mark one as visible again. Now I seem to be in a strange state where ghci and ghc-pkg disagree about what is hidden:\r\n\r\n{{{\r\n% ghci-7.10.2 \r\nGHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help\r\nPrelude> :m +Data.Vector.Unboxed\r\n\r\n<no location info>:\r\n Could not find module ‘Data.Vector.Unboxed’\r\n It is a member of the hidden package ‘vector-0.11.0.0@vecto_3jMaUrldidp1bqsrn0qsS2’.\r\n It is a member of the hidden package ‘vector-0.10.12.3@vecto_1COyUuV1LrA1IjYnWfJnbs’.\r\nPrelude> \r\nLeaving GHCi.\r\n% ghc-pkg-7.10.2 list vector | cat\r\n/usr/local/lib/ghc-7.10.2/package.conf.d:\r\n (no packages)\r\n/home/dmwit/.ghc/x86_64-linux-7.10.2/package.conf.d:\r\n vector-0.10.12.3\r\n (vector-0.11.0.0)\r\n\r\n% ghc-pkg-7.10.2 describe vector-0.10.12.3 | grep 'key:\\|exposed:'\r\nkey: vecto_1COyUuV1LrA1IjYnWfJnbs\r\nexposed: True\r\n}}}\r\n\r\nI have tried reproducing this with other packages in a handful of ways and failed; so I can't give instructions for reproducing. But I am happy to perform any diagnostics you can think of.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/10912Support for out of the box static linking2019-07-07T18:33:05Zcrb002Support for out of the box static linkingWhen running in environments like AWS Lambda you don't have access to basic shared libraries Haskell needs like libgmp, libffi. Need good support for static linked libraries of anything included in a basic GHC distribution.
https://gith...When running in environments like AWS Lambda you don't have access to basic shared libraries Haskell needs like libgmp, libffi. Need good support for static linked libraries of anything included in a basic GHC distribution.
https://github.com/commercialhaskell/stack/issues/1032
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Support for out of the box static linking","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"When running in environments like AWS Lambda you don't have access to basic shared libraries Haskell needs like libgmp, libffi. Need good support for static linked libraries of anything included in a basic GHC distribution.\r\n\r\nhttps://github.com/commercialhaskell/stack/issues/1032","type_of_failure":"OtherFailure","blocking":[]} -->