GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2021-12-09T20:47:10Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/19286ghc and ghci don't read the default package environment file on Windows2021-12-09T20:47:10Zdanidiazghc and ghci don't read the default package environment file on Windows## Summary
According to the [package environments section](https://downloads.haskell.org/ghc/latest/docs/html/users_guide/packages.html#package-environments) of the User Guide, `ghc` and `ghci` invocations should use the `$HOME/.ghc/arc...## Summary
According to the [package environments section](https://downloads.haskell.org/ghc/latest/docs/html/users_guide/packages.html#package-environments) of the User Guide, `ghc` and `ghci` invocations should use the `$HOME/.ghc/arch-os-version/environments/default` package environment file if it exists and no specific options have been given to the contrary.
This works correctly on Linux, but the file is not being found on Windows.
On my machine, the default package environment is located at `C:\Users\myuser\.ghc\x86_64-mingw32-8.10.3\environments\default`.
## Steps to reproduce
Create a package environment file in the default location. The simplest way is to install a library with [`cabal install --lib`](https://cabal.readthedocs.io/en/3.4/cabal-commands.html#cabal-v2-install):
`cabal install --lib sop-core`
Then, in an empty folder, start `ghci`, then try to `import Data.SOP.NP`.
Also create a `Main.hs` which imports `Data.SOP.NP` and try to compile with `ghc`.
## Expected behavior
Neither `ghci` nor `ghc` should complain about not finding the module.
`ghci` should show a `Loaded package environment from...` message when starting up.
## Environment
* GHC version used: 8.10.3
* Operating System: Windows 10https://gitlab.haskell.org/ghc/ghc/-/issues/18070GHC 8.10's API can load interfaces with the wrong package identifier when loo...2020-08-13T22:22:56ZquasicomputationalGHC 8.10's API can load interfaces with the wrong package identifier when looking for pluginsOriginally a doctest bug report: https://github.com/sol/doctest/issues/264
I inlined the relevant code from doctest into the provided reproducer, producing [this reduced reproducer](https://github.com/quasicomputational/test-doctest). R...Originally a doctest bug report: https://github.com/sol/doctest/issues/264
I inlined the relevant code from doctest into the provided reproducer, producing [this reduced reproducer](https://github.com/quasicomputational/test-doctest). Run with `./run-test.sh`.
On my machine, I get an error that looks like this:
```
test-doctest: Bad interface file: [..]/dist-newstyle/build/x86_64-linux/ghc-8.10.1/dummy-plugin-0.1.0.0/build/DummyDefs.hi
Something is amiss; requested module dummy-plugin-0.1.0.0:DummyDefs differs from name found in the interface file ghc-compact-0.1.0.0:DummyDefs (if these names look the same, try again with -dppr-debug)
```
Where does that `ghc-compact` come from? I have no idea. Even more puzzlingly, if I turn up GHC's verbosity, that turns into `process`!
[`test-doctest.hs`](https://github.com/quasicomputational/test-doctest/blob/master/test-doctest.hs) is the (now misleadingly-named) code driving GHC, and as far as I can tell it's not doing anything exotic or bizarre.
[`Haddock.Interface`](https://github.com/haskell/haddock/blob/8c6532636e6bd572455dfcf0b0d6e05f7033d110/haddock-api/src/Haddock/Interface.hs) is the roughly corresponding code in Haddock, which seems to mostly do the same thing - and yet Haddock works and doctest doesn't. I have no idea what the difference is, except that it might be something to do with order-sensitivity in how modules are loaded.
The error doesn't happen on GHC 8.8. I couldn't find anything in the release notes warning me about any changes here, so this is a regression.https://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/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/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":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/11504Can't install haskell-platform in OpenBSD2019-07-07T18:30:09ZAchifaifaCan't install haskell-platform in OpenBSDI'm trying to install the haskell platform in openbsd. This is the output I get
` Can't install freeglut-2.8.0 because of libraries
|library GL.13.0 not found
| not found anywhere
|library X11.15.1 not found
| not found anywhere
|librar...I'm trying to install the haskell platform in openbsd. This is the output I get
` Can't install freeglut-2.8.0 because of libraries
|library GL.13.0 not found
| not found anywhere
|library X11.15.1 not found
| not found anywhere
|library Xdamage.3.1 not found
| not found anywhere
|library Xext.12.0 not found
| not found anywhere
|library Xfixes.5.1 not found
| not found anywhere
|library Xi.11.1 not found
| not found anywhere
|library Xrandr.6.1 not found
| not found anywhere
|library Xrender.5.0 not found
| not found anywhere
|library Xxf86vm.5.0 not found
| not found anywhere
|library drm.3.1 not found
| not found anywhere
|library xcb.2.4 not found
| not found anywhere
Can't install hs-GLUT-2.1.2.1p11: can't resolve freeglut-2.8.0
Can't install haskell-platform-2012.4.0.0p0: can't resolve hs-GLUT-2.1.2.1p11 `
I'm installing it on a laptop without a desktop environment or X server, so I'm not sure if the problem is that I don't have a X/GL installation or if the installer can't locate some packages in the source.
I'm a total newbie to both OpenBSD and Haskell, so I know nothing that could help with this. Let me know if you need any extra information about the issue.https://gitlab.haskell.org/ghc/ghc/-/issues/11455GHC-8.0.0.20160109 runs into "Bad interface file: ... Something is amiss"2019-07-07T18:30:21ZLemmingGHC-8.0.0.20160109 runs into "Bad interface file: ... Something is amiss"When I first started testing GHC-8.0.0.20160109 I could compile a lot of packages. However, now I get the following error more and more frequently:
```
$ cabal install --with-ghc=ghc-8.0.0.20160109 --with-haddock=haddock-ghc-8.0.0.20160...When I first started testing GHC-8.0.0.20160109 I could compile a lot of packages. However, now I get the following error more and more frequently:
```
$ cabal install --with-ghc=ghc-8.0.0.20160109 --with-haddock=haddock-ghc-8.0.0.20160109 http://hackage.haskell.org/package/set-cover-0.0.8/set-cover-0.0.8.tar.gz
Downloading
http://hackage.haskell.org/package/set-cover-0.0.8/set-cover-0.0.8.tar.gz
Resolving dependencies...
Configuring enummapset-0.5.2.1...
Building enummapset-0.5.2.1...
Preprocessing library enummapset-0.5.2.1...
[1 of 5] Compiling Data.EnumSet ( Data/EnumSet.hs, dist/build/Data/EnumSet.o )
...
[4 of 5] Compiling Data.EnumMap.Lazy ( Data/EnumMap/Lazy.hs, dist/build/Data/EnumMap/Lazy.p_o )
[5 of 5] Compiling Data.EnumMap ( Data/EnumMap.hs, dist/build/Data/EnumMap.p_o )
In-place registering enummapset-0.5.2.1...
Running Haddock for enummapset-0.5.2.1...
Preprocessing library enummapset-0.5.2.1...
...
Registering enummapset-0.5.2.1...
Installed enummapset-0.5.2.1
Configuring set-cover-0.0.8...
Building set-cover-0.0.8...
Preprocessing library set-cover-0.0.8...
[ 1 of 15] Compiling Math.SetCover.Cuboid ( src/Math/SetCover/Cuboid.hs, dist/build/Math/SetCover/Cuboid.o )
[ 2 of 15] Compiling Math.SetCover.Queue ( src/Math/SetCover/Queue.hs, dist/build/Math/SetCover/Queue.o )
src/Math/SetCover/Queue.hs:3:1: error:
Bad interface file: /home/cabal/lib/x86_64-linux-ghc-8.0.0.20160109/enummapset-0.5.2.1-KxKeewRMTNa4DSa3VnUuRQ/Data/EnumMap.hi
Something is amiss; requested module enummapset-0.5.2.1@enummapset-0.5.2.1-64948c41f2d75b38829fcb75933a73f0:Data.EnumMap differs from name found in the interface file enumm_KxKeewRMTNa4DSa3VnUuRQ:Data.EnumMap
src/Math/SetCover/Queue.hs:4:1: error:
Bad interface file: /home/cabal/lib/x86_64-linux-ghc-8.0.0.20160109/enummapset-0.5.2.1-KxKeewRMTNa4DSa3VnUuRQ/Data/EnumSet.hi
Something is amiss; requested module enummapset-0.5.2.1@enummapset-0.5.2.1-64948c41f2d75b38829fcb75933a73f0:Data.EnumSet differs from name found in the interface file enumm_KxKeewRMTNa4DSa3VnUuRQ:Data.EnumSet
Failed to install set-cover-0.0.8
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1-rc1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC-8.0.0.20160109 runs into \"Bad interface file: ... Something is amiss\"","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When I first started testing GHC-8.0.0.20160109 I could compile a lot of packages. However, now I get the following error more and more frequently:\r\n{{{\r\n$ cabal install --with-ghc=ghc-8.0.0.20160109 --with-haddock=haddock-ghc-8.0.0.20160109 http://hackage.haskell.org/package/set-cover-0.0.8/set-cover-0.0.8.tar.gz\r\nDownloading\r\nhttp://hackage.haskell.org/package/set-cover-0.0.8/set-cover-0.0.8.tar.gz\r\nResolving dependencies...\r\nConfiguring enummapset-0.5.2.1...\r\nBuilding enummapset-0.5.2.1...\r\nPreprocessing library enummapset-0.5.2.1...\r\n[1 of 5] Compiling Data.EnumSet ( Data/EnumSet.hs, dist/build/Data/EnumSet.o )\r\n...\r\n[4 of 5] Compiling Data.EnumMap.Lazy ( Data/EnumMap/Lazy.hs, dist/build/Data/EnumMap/Lazy.p_o )\r\n[5 of 5] Compiling Data.EnumMap ( Data/EnumMap.hs, dist/build/Data/EnumMap.p_o )\r\nIn-place registering enummapset-0.5.2.1...\r\nRunning Haddock for enummapset-0.5.2.1...\r\nPreprocessing library enummapset-0.5.2.1...\r\n...\r\nRegistering enummapset-0.5.2.1...\r\nInstalled enummapset-0.5.2.1\r\nConfiguring set-cover-0.0.8...\r\nBuilding set-cover-0.0.8...\r\nPreprocessing library set-cover-0.0.8...\r\n[ 1 of 15] Compiling Math.SetCover.Cuboid ( src/Math/SetCover/Cuboid.hs, dist/build/Math/SetCover/Cuboid.o )\r\n[ 2 of 15] Compiling Math.SetCover.Queue ( src/Math/SetCover/Queue.hs, dist/build/Math/SetCover/Queue.o )\r\n\r\nsrc/Math/SetCover/Queue.hs:3:1: error:\r\n Bad interface file: /home/cabal/lib/x86_64-linux-ghc-8.0.0.20160109/enummapset-0.5.2.1-KxKeewRMTNa4DSa3VnUuRQ/Data/EnumMap.hi\r\n Something is amiss; requested module enummapset-0.5.2.1@enummapset-0.5.2.1-64948c41f2d75b38829fcb75933a73f0:Data.EnumMap differs from name found in the interface file enumm_KxKeewRMTNa4DSa3VnUuRQ:Data.EnumMap\r\n\r\nsrc/Math/SetCover/Queue.hs:4:1: error:\r\n Bad interface file: /home/cabal/lib/x86_64-linux-ghc-8.0.0.20160109/enummapset-0.5.2.1-KxKeewRMTNa4DSa3VnUuRQ/Data/EnumSet.hi\r\n Something is amiss; requested module enummapset-0.5.2.1@enummapset-0.5.2.1-64948c41f2d75b38829fcb75933a73f0:Data.EnumSet differs from name found in the interface file enumm_KxKeewRMTNa4DSa3VnUuRQ:Data.EnumSet\r\nFailed to install set-cover-0.0.8\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/10723Make declarations in signatures "weakly bound" until they are used2019-07-07T18:34:19ZEdward Z. YangMake declarations in signatures "weakly bound" until they are usedSuppose you are the author of a library in a Backpack world, and you publish a signature package which defines the entire public facing interface of your library. The library `foo` which uses of your library decides to `include` the sign...Suppose you are the author of a library in a Backpack world, and you publish a signature package which defines the entire public facing interface of your library. The library `foo` which uses of your library decides to `include` the signature package for convenience, but actually only uses a small portion of the API.
Later, you make a BC-breaking change in one part of the library and release a new signature package. The library `bar` which uses your library includes this NEW signature package, using a different portion of the API which was unaffected by the by the BC change.
Now, a hapless user tries to use `foo` and `bar`, but Backpack complains that the requirements are not compatible.
What's the problem here? The practice of writing reusable signature packages for people to use caused the requirements of `foo` and `bar` to become too large, since they included a lot of junk that these libraries didn't actually use. It would be far better if you could `include` a signature package, but only "require" the bits of it that you actually used!
How can we achieve this?
1. We augment the `ModIface` of signature merges (#10690) to record whether or not a declaration was (transitively) used or not by some module. Used declarations must be filled, but unused ones are treated more flexibly: if they are merged with a different, incompatible but used requirement, they disappear, and we don't check if an implementing module actually implemented the declaration. (If two unused incompatible requirements are merged, we just erase the name.)
1. How do we compute the usage info? I think it will have to be done during shaping (which runs the renamer). We only need to annotate each declaration a signature with the transitive set of names from other signatures that it has used--this can be incrementally computed. (It's not necessary to annotate declarations in modules, since they are always assumed to use holes). Then whenever a declaration from a signature is used in a module, we mark its transitive set as used. This information can then be used later when constructing the merged `ModIface` which represents the "public requirement" of the package.
So, for example, a package containing only signatures would contain all unused declarations (however, they may start being used by a package which includes them). Any unused declaration which isn't mixed with another incompatible declaration can be imported (causing it to be used), but we will complain if you try to use a name and we can't tell which declaration to use.
(PS: another moral here, is that `include`s are bad UNLESS you are including a signature package! Because an include for a concrete module is a dependency you can't override...)Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/10680Make Backpack order-independent (again)2019-07-07T18:34:41ZEdward Z. YangMake Backpack order-independent (again)When we moved to the new `bkp` file format, we also went back to the a format which is order-dependent: that is to say, the order in which you put the declarations matters. So if you write:
```
unit p where
module A where
import B...When we moved to the new `bkp` file format, we also went back to the a format which is order-dependent: that is to say, the order in which you put the declarations matters. So if you write:
```
unit p where
module A where
import B
module B where
...
```
this fails to type-check, GHC complaining that `B` is not in scope. I did this, in part because it's what the Backpack paper described, and because it was "simpler" to implement.
I think we should move back to an order-independent scheme, for the following reasons:
1. Haskell users are used to not needing pay particularly close attention to the ordering of their modules, and forcing people to linearize their module descriptions would be spectacularly disruptive with large amounts of modules. So un-ordered modules are "more natural for a traditional Haskell user.
1. Order-independence imposes some constraints on how expressive programs are (with order-dependent Backpack, you can do some pretty tricky things by ordering things certain ways); this could simplify some aspects of compiler implementation and make Backpack easier to explain.
1. A particular case of (2): it seems a lot simpler UX-wise to let a user assume that if you import a module `M` in a unit, it doesn't matter where you import it: you always get the same set of identifiers brought into scope. Thus, the incremental results of signatures should not be visible, c.f. #10679
The main idea is that only the surface-syntax is un-ordered: the internal representation of units is a DAG which we work out in an elaboration phase, not altogether unsimilar from what `GhcMake` computes. An important auxiliary idea is that `import A` where `A` is backed by some signatures depends on EVERY signature in scope.
Here are the details:
- \*The intermediate representation.\*\* We translate into an intermediate representation which consists of a directed graph of:
• Each source-level module, signature and include, and
• Each unfilled requirement (called a “signature merge” node).
The edges of the directed graph signify a “depends on” relation, and are defined as follows:
• An include p depends on include q if, for some module name m, p requires m and q provides m.
• An include p depends on a module m if p requires a module named m.
• A module/signature m depends on include p if m imports a module provided by p.
• A module/signature m depends on a module n if m imports n.
• A module/signature m depends on a signature merge n if m imports n.
• A module/signature m depends on a signature n if m {-\# SOURCE \#-} imports n.
• A signature merge m depends on a local signature m (if it exists).
• A signature merge m depends on a include p, if the (renamed) include requires m.
- \*Elaboration.\*\* Take a Backpack file, construct this graph, and topsort it into a DAG of SCCs. SCCs with a single node are compileable as before. SCCs with multiple nodes will have to be managed with some mutual recursion mechanism; see refinements for more thoughts on this.
- \*Refinements:\*\*
1. \*\*Can a signature depend on a (home) module?\*\* Imports of this kind require a retypecheck loop. Consider this situation:
```
unit p where
signature H where
data T
module M where
import H
data S = S T
unit q where
include p
module Q where
import M
signature H where
import Q
data T = T S
```
> Here, signature H in q depends on Q. When we typecheck `Q`, we bring `M.S` into the type environment with a `TyThing` that describes the constructor as accepting an abstract type `T`. However, when we subsequently typecheck the local signature `H`, we must refine all `TyThing`s of `T` with the true description (e.g. constructor information). So you'll need to retypecheck `Q` (and `M`) in order to make sure the `TyThing` is correct.
1. \*\*Can an include depend on a (home) module?\*\* If the module has no (transitive) dependency on signatures, this is fine. However, it's easy to have a circular dependency. Consider:
```
unit p where
signature A -- imports nothing
signature B -- imports nothing
module M
unit q where
include p
module B where
import A
...
```
> `B` depends on `p` for `p/A.hsig`; however, `p` depends on `B` because this module is filling a requirement. However, if we were to include the internal graph of `p` into `q`, the resulting graph would not have an cycles; so this is one possibility of how to untangle this situation. However, if there's still a cycle (e.g. `A` imports `B`), then you will need at least a retypecheck loop, and maybe `hs-boot` style compilation. We're not going to implement this for now.
1. \*\*Can we deal with include-include dependency cycles?\*\* Yes! Just use the Backpack paper's strategy for creating a recursive unit key and compile the two packages `hs-boot` style. But I'm not planning on implementing this yet.
1. \*\*Can we deal with signature-signature dependency cycles?\*\* Ordered Backpack would have supported this:
```
unit a-sig where
signature A where
data T
unit ab-sig where
include a-sig
signature B where
import A
data S = S T
signature A where
import B
data T = T S
```
> In our model, `ab-sig` has a cycle. However, I believe any such cycle can be broken by creating sufficiently many units:
```
unit a-sig where
signature B where
data T
signature A where
data S = S T
unit b-sig where
signature A where
data S
signature B where
data T = T S
unit ab-sig where
include a-sig
include b-sig
```
> In principle, GHC could automatically break import cycles by replacing an import with an import of a reduced signature that simply has abstract type definitions. See #10681. (I'm not sure this is possible for all language features.) This technique would also work for normal modules, assuming that every function is explicitly annotated with a type.Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/10679Generalize hi-boot/hi for signatures, to manage intermediate merged interfaces2019-07-07T18:34:41ZEdward Z. YangGeneralize hi-boot/hi for signatures, to manage intermediate merged interfaces## The problem
In some situations, we need to output multiple interface
files for what is morally the same module name.
### Example 1: Merging external and home signatures
```
unit a-sig where
signature A
unit p where
include ...## The problem
In some situations, we need to output multiple interface
files for what is morally the same module name.
### Example 1: Merging external and home signatures
```
unit a-sig where
signature A
unit p where
include a-sig
signature A
```
Compiling `p/A.hsig` produces an interface file which contains just
the definitions declared in `p`. However, someone including `p`
should see the merge of the interface of `p/A.hsig` AND `a-sig/A.hsig`
(which was included.)
### Example 2: Merging two home signatures
```
unit p where
signature A
signature B where
import A
...
signature A where
import B
...
```
What should we do if a signature is specified multiple times in the same
unit? The compilation of each produces a distinct interface, and the
public interface we want to expose is the merge of the two. (And by the
way, what's the source file name of `A`, if we are not using the inline syntax?)
### Example 3: Merging a signature and a module
```
unit p where
signature A
module B where
import A
...
module A where
import B
...
```
`A` and `B` are mutually recursive, and we want to use a signature file to
break the gap. The signature produces an interface file, only to be
overwritten when we actually define the module proper.
But wait! We have a solution for this example already: the first interface
file for `A` is not saved to `A.hi`, but `A.hi-boot`...
## The proposal
I want to take the `A.hi-boot` versus `A.hi` distinction and
generalize it: we should be able to name intermediate interface
files A.1.hi, A.2.hi, ... and finally A.hi (which
is publically visible outside the unit.) This naming convention applies
to Haskell files too.
### User-visible consequences
Every signature file is numbered, and every import of a signature file
refers to a specific number. This number is unique among all other
modules in a unit which share the same name. For backwards
compatibility, some number/file name extensions are treated specially:
1. `.hs` files compile to `.hi` (implicitly numbered 0)
1. `.hs-boot` files compile to `.hi-boot` (implicitly numbered 1)
1. `.hsig` files compile to `.hi-boot` (implicitly numbered 1)
1. `.n.hsig` files compile to `.n.hi-boot` (numbered n, where n is greater than 1)
- \*Flex point:\*\* We could give `.hsig` files their own file extension
for interface files; just would require some more work to distinguish
between `hs-boot` and `hsig` as well as record the numbering.
To import, the `{-# SOURCE n #-}` pragma can be used (with `{-# SOURCE #-}`
being equivalent `{-# SOURCE 1 #-}`.)
Inline Backpack files can omit numbering, since we can figure it out
based on the ordering of declarations (numbering in REVERSE order
of occurrence). Example 2 can be numbered as follows:
```
signature {-# SOURCE 2 #-} A
signature {-# SOURCE 1 #-} B where
import {-# SOURCE 2 #-} A
...
signature {-# SOURCE 1 #-} A where
import {-# SOURCE 1 #-} B
...
```
### Internal consequences
In many places in the code today, we record a boolean indicating if
we depended on the boot interface `hi-boot` or the normal interface `hi`.
We now replace this marker with an integer which records the numbering.
The primary affected components are dependency recording in interfaces,
interface loading code in GHC, and the implementation of `--make`.
### Interaction with signature merging
Unlike `hs-boot` files, `hsig` files can be included from external
units, in which case the semantics are that all signatures in scope
are merged together. The key rule is that we \*\*generate an hi
file for each partial merge\*\*; this means that whenever we want
to typecheck a module, there is exactly one interface file per
module we import. Consider this example:
```
unit a-sig where
signature A
unit a-sig2 where
signature A
unit p where
include a-sig
module B
include a-sig2
module C
signature A
module D
```
When compiling this, we generate four interface files for `A`:
```
unit p where
include a-sig
-- Produces A.3.hi-boot (a-sig)
module B -- uses A.3.hi-boot
include a-sig2
-- Produces A.2.hi-boot (a-sig + a-sig2)
module C -- uses A.2.hi-boot
signature A
-- Produces A.hi-boot (everything)
module D -- uses A.hi-boot
-- At the end, A.hi-boot copied to A.hi to be publically visible
```
## Can we do anything simpler?
There are a few barriers to doing something simpler:
1. We can avoid generating extra interface files if we instead merge them on-the-fly when we use them. However, this forces later instances of GHC to do repeated work remerging interface files, so it seems desirable from a performance perspective to merge before writing. Another scheme is that we could merge on use for signatures in the home package, and then write out a unified file at the very end, trading off performance for less written interface files.
1. The Backpack language is defined in a way that allows modules, signatures and includes to be ordered in a semantically meaningful way. For example:
```
unit q where
signature M
signature A where
f :: Int -> Int
...
unit p where
signature A where
data T
module M where
import A -- should get T but not f
...
include q -- fill in M
module S where
import A -- should get T and f
```
> This means that even within a unit, the interface of a signature file may differ. We could rule this out, but we would have to work out how to explain this limitation to users. (For example, we could solve the example above by saying that units which define modules do not bring their signatures into scope for a package which imports them; but this is a pretty ad hoc rule! And you still have to deal with repeated signatures, or a signature importing a module importing a signature. There are a lot of cases.)
1. This problem cannot be avoided at all if you are truly doing recursive modules, since you need the intermediate interface file to do compilation at all prior to getting the real implementation.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.11 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Generalize hi-boot/hi for signatures, to manage intermediate merged interfaces","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ezyang"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"== The problem ==\r\n\r\nIn some situations, we need to output multiple interface\r\nfiles for what is morally the same module name.\r\n\r\n=== Example 1: Merging external and home signatures ===\r\n\r\n{{{\r\nunit a-sig where\r\n signature A\r\nunit p where\r\n include a-sig\r\n signature A\r\n}}}\r\n\r\nCompiling `p/A.hsig` produces an interface file which contains just\r\nthe definitions declared in `p`. However, someone including `p`\r\nshould see the merge of the interface of `p/A.hsig` AND `a-sig/A.hsig`\r\n(which was included.)\r\n\r\n=== Example 2: Merging two home signatures ===\r\n\r\n{{{\r\nunit p where\r\n signature A\r\n signature B where\r\n import A\r\n ...\r\n signature A where\r\n import B\r\n ...\r\n}}}\r\n\r\nWhat should we do if a signature is specified multiple times in the same\r\nunit? The compilation of each produces a distinct interface, and the\r\npublic interface we want to expose is the merge of the two. (And by the\r\nway, what's the source file name of `A`, if we are not using the inline syntax?)\r\n\r\n=== Example 3: Merging a signature and a module ===\r\n\r\n{{{\r\nunit p where\r\n signature A\r\n module B where\r\n import A\r\n ...\r\n module A where\r\n import B\r\n ...\r\n}}}\r\n\r\n`A` and `B` are mutually recursive, and we want to use a signature file to\r\nbreak the gap. The signature produces an interface file, only to be\r\noverwritten when we actually define the module proper.\r\n\r\nBut wait! We have a solution for this example already: the first interface\r\nfile for `A` is not saved to `A.hi`, but `A.hi-boot`...\r\n\r\n== The proposal ==\r\n\r\nI want to take the `A.hi-boot` versus `A.hi` distinction and\r\ngeneralize it: we should be able to name intermediate interface\r\nfiles A.1.hi, A.2.hi, ... and finally A.hi (which\r\nis publically visible outside the unit.) This naming convention applies\r\nto Haskell files too.\r\n\r\n=== User-visible consequences ===\r\n\r\nEvery signature file is numbered, and every import of a signature file\r\nrefers to a specific number. This number is unique among all other\r\nmodules in a unit which share the same name. For backwards\r\ncompatibility, some number/file name extensions are treated specially:\r\n\r\n1. `.hs` files compile to `.hi` (implicitly numbered 0)\r\n\r\n2. `.hs-boot` files compile to `.hi-boot` (implicitly numbered 1)\r\n\r\n3. `.hsig` files compile to `.hi-boot` (implicitly numbered 1)\r\n\r\n4. `.n.hsig` files compile to `.n.hi-boot` (numbered n, where n is greater than 1)\r\n\r\n**Flex point:** We could give `.hsig` files their own file extension\r\nfor interface files; just would require some more work to distinguish\r\nbetween `hs-boot` and `hsig` as well as record the numbering.\r\n\r\nTo import, the `{-# SOURCE n #-}` pragma can be used (with `{-# SOURCE #-}`\r\nbeing equivalent `{-# SOURCE 1 #-}`.)\r\n\r\nInline Backpack files can omit numbering, since we can figure it out\r\nbased on the ordering of declarations (numbering in REVERSE order\r\nof occurrence). Example 2 can be numbered as follows:\r\n\r\n{{{\r\n signature {-# SOURCE 2 #-} A\r\n signature {-# SOURCE 1 #-} B where\r\n import {-# SOURCE 2 #-} A\r\n ...\r\n signature {-# SOURCE 1 #-} A where\r\n import {-# SOURCE 1 #-} B\r\n ...\r\n}}}\r\n\r\n=== Internal consequences ===\r\n\r\nIn many places in the code today, we record a boolean indicating if\r\nwe depended on the boot interface `hi-boot` or the normal interface `hi`.\r\nWe now replace this marker with an integer which records the numbering.\r\nThe primary affected components are dependency recording in interfaces,\r\ninterface loading code in GHC, and the implementation of `--make`.\r\n\r\n=== Interaction with signature merging ===\r\n\r\nUnlike `hs-boot` files, `hsig` files can be included from external\r\nunits, in which case the semantics are that all signatures in scope\r\nare merged together. The key rule is that we **generate an hi\r\nfile for each partial merge**; this means that whenever we want\r\nto typecheck a module, there is exactly one interface file per\r\nmodule we import. Consider this example:\r\n\r\n{{{\r\nunit a-sig where\r\n signature A\r\nunit a-sig2 where\r\n signature A\r\nunit p where\r\n include a-sig\r\n module B\r\n include a-sig2\r\n module C\r\n signature A\r\n module D\r\n}}}\r\n\r\nWhen compiling this, we generate four interface files for `A`:\r\n\r\n{{{\r\nunit p where\r\n include a-sig\r\n -- Produces A.3.hi-boot (a-sig)\r\n module B -- uses A.3.hi-boot\r\n include a-sig2\r\n -- Produces A.2.hi-boot (a-sig + a-sig2)\r\n module C -- uses A.2.hi-boot\r\n signature A\r\n -- Produces A.hi-boot (everything)\r\n module D -- uses A.hi-boot\r\n -- At the end, A.hi-boot copied to A.hi to be publically visible\r\n}}}\r\n\r\n== Can we do anything simpler? ==\r\n\r\nThere are a few barriers to doing something simpler:\r\n\r\n1. We can avoid generating extra interface files if we instead merge them on-the-fly when we use them. However, this forces later instances of GHC to do repeated work remerging interface files, so it seems desirable from a performance perspective to merge before writing. Another scheme is that we could merge on use for signatures in the home package, and then write out a unified file at the very end, trading off performance for less written interface files.\r\n\r\n2. The Backpack language is defined in a way that allows modules, signatures and includes to be ordered in a semantically meaningful way. For example:\r\n{{{\r\nunit q where\r\n signature M\r\n signature A where\r\n f :: Int -> Int\r\n ...\r\nunit p where\r\n signature A where\r\n data T\r\n module M where\r\n import A -- should get T but not f\r\n ...\r\n include q -- fill in M\r\n module S where\r\n import A -- should get T and f\r\n}}}\r\n This means that even within a unit, the interface of a signature file may differ. We could rule this out, but we would have to work out how to explain this limitation to users. (For example, we could solve the example above by saying that units which define modules do not bring their signatures into scope for a package which imports them; but this is a pretty ad hoc rule! And you still have to deal with repeated signatures, or a signature importing a module importing a signature. There are a lot of cases.)\r\n\r\n3. This problem cannot be avoided at all if you are truly doing recursive modules, since you need the intermediate interface file to do compilation at all prior to getting the real implementation.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/10666Distinguish between semantic module / identity module in TcGblEnv, ModIface a...2019-07-07T18:34:44ZEdward Z. YangDistinguish between semantic module / identity module in TcGblEnv, ModIface and ModGutsWhen we write a signature like
```
package p where
signature H where
data T
```
and compile it to an interface file, there are two ways we might say what the `Module` of this interface is:
1. The \*\*identity module\*\* uniquely...When we write a signature like
```
package p where
signature H where
data T
```
and compile it to an interface file, there are two ways we might say what the `Module` of this interface is:
1. The \*\*identity module\*\* uniquely identifies an interface file, and is used for dependency analysis and tracking. In the example above, the identity module is `p(H -> HOLE:H):H`.
1. The \*\*semantic module\*\* tells us what the `Name`s of the entities defined in the module are supposed to be; e.g., it's used for generating new names when type-checking hs files or interfaces. In the example above, the semantic module is `hole:H`, since this signature exports one entity named `hole:H.T`. The semantic module can always be derived from the identity module.
For normal Haskell modules, the semantic and identity module coincide. However, for signatures they differ: we may have many signatures for the same module; they all share their semantic module but have differing identity modules.
By in large, when GHC manipulates `Module` directly it is interested in the identity module. However, when a `Module` is used with reference to a `Name` (primarily `nameIsLocalOrFrom`), we want to use the SEMANTIC module. (Another example: when we filter out the type environment before making a `ModIface`, need to filter against the semantic module.)
I tried a few ways of factoring GHC's code so we'd be less likely to confuse these two `Module`s when typechecking signatures: the big problem is if you're adding a `getModule` call to `TcRn`, you're probably not going to think too hard whether or not you actually wanted the semantic module or the identity module. But if you pick the wrong thing that will break all sorts of things for signatures.
Here are some things we could do:
1. My initial attempt was to change `tcg_mod`, `mg_module` and `mi_module` to record a new data type `TopModule` which recorded both the semantic and identity module, with `getModule` in `TcRn` continuing to return a semantic module, but `mi_module` returning an identity module. However, the resulting patch was pretty ugly and it's not altogether clear that `getModule` returning the semantic module is always correct.
1. My other idea is to say that these entries always are IDENTITY modules (this will result on fail fast behavior for signatures if you get it wrong), and then rewrite `nameIsLocalOrFrom`, `externaliseAndTidyId`, `initIfaceTcRn`, `newGlobalBinder` so that they always do the right thing (i.e. use the semantic module); thus, the only time you can get it wrong is if you're creating some new functionality that's not these functions that needs to use semantic modules.
Pretty delicate.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Distinguish between semantic module / identity module in TcGblEnv, ModIface and ModGuts","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ezyang"},"version":"7.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"When we write a signature like\r\n\r\n{{{\r\npackage p where\r\n signature H where\r\n data T\r\n}}}\r\n\r\nand compile it to an interface file, there are two ways we might say what the `Module` of this interface is:\r\n\r\n1. The **identity module** uniquely identifies an interface file, and is used for dependency analysis and tracking. In the example above, the identity module is `p(H -> HOLE:H):H`.\r\n\r\n2. The **semantic module** tells us what the `Name`s of the entities defined in the module are supposed to be; e.g., it's used for generating new names when type-checking hs files or interfaces. In the example above, the semantic module is `hole:H`, since this signature exports one entity named `hole:H.T`. The semantic module can always be derived from the identity module.\r\n\r\nFor normal Haskell modules, the semantic and identity module coincide. However, for signatures they differ: we may have many signatures for the same module; they all share their semantic module but have differing identity modules.\r\n\r\nBy in large, when GHC manipulates `Module` directly it is interested in the identity module. However, when a `Module` is used with reference to a `Name` (primarily `nameIsLocalOrFrom`), we want to use the SEMANTIC module. (Another example: when we filter out the type environment before making a `ModIface`, need to filter against the semantic module.)\r\n\r\nI tried a few ways of factoring GHC's code so we'd be less likely to confuse these two `Module`s when typechecking signatures: the big problem is if you're adding a `getModule` call to `TcRn`, you're probably not going to think too hard whether or not you actually wanted the semantic module or the identity module. But if you pick the wrong thing that will break all sorts of things for signatures.\r\n\r\nHere are some things we could do:\r\n\r\n1. My initial attempt was to change `tcg_mod`, `mg_module` and `mi_module` to record a new data type `TopModule` which recorded both the semantic and identity module, with `getModule` in `TcRn` continuing to return a semantic module, but `mi_module` returning an identity module. However, the resulting patch was pretty ugly and it's not altogether clear that `getModule` returning the semantic module is always correct.\r\n\r\n2. My other idea is to say that these entries always are IDENTITY modules (this will result on fail fast behavior for signatures if you get it wrong), and then rewrite `nameIsLocalOrFrom`, `externaliseAndTidyId`, `initIfaceTcRn`, `newGlobalBinder` so that they always do the right thing (i.e. use the semantic module); thus, the only time you can get it wrong is if you're creating some new functionality that's not these functions that needs to use semantic modules.\r\n\r\nPretty delicate.","type_of_failure":"OtherFailure","blocking":[]} -->Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/9998GHC binary package seems to be corrupt2019-07-07T18:37:59Zmark_christiaensGHC binary package seems to be corruptInstalled https://www.haskell.org/ghc/dist/7.8.4/ghc-7.8.4-x86_64-unknown-linux-deb7.tar.bz2
Did ghc-pkg check
Got:
ghc-pkg check
There are problems in package haskell-src-exts-1.16.0.1:
> Warning: library-dirs: /home/developer/.caba...Installed https://www.haskell.org/ghc/dist/7.8.4/ghc-7.8.4-x86_64-unknown-linux-deb7.tar.bz2
Did ghc-pkg check
Got:
ghc-pkg check
There are problems in package haskell-src-exts-1.16.0.1:
> Warning: library-dirs: /home/developer/.cabal/lib/x86_64-linux-ghc-7.8.4/haskell-src-exts-1.16.0.1 doesn't exist or isn't a directory
> Warning: haddock-interfaces: /home/developer/.cabal/share/doc/x86_64-linux-ghc-7.8.4/haskell-src-exts-1.16.0.1/html/haskell-src-exts.haddock doesn't exist or isn't a file
> Warning: haddock-html: /home/developer/.cabal/share/doc/x86_64-linux-ghc-7.8.4/haskell-src-exts-1.16.0.1/html doesn't exist or isn't a directory
> import-dirs: /home/developer/.cabal/lib/x86_64-linux-ghc-7.8.4/haskell-src-exts-1.16.0.1 doesn't exist or isn't a directory
> cannot find any of \["Language/Haskell/Exts.hi","Language/Haskell/Exts.p_hi","Language/Haskell/Exts.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/Lexer.hi","Language/Haskell/Exts/Lexer.p_hi","Language/Haskell/Exts/Lexer.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/Parser.hi","Language/Haskell/Exts/Parser.p_hi","Language/Haskell/Exts/Parser.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/Pretty.hi","Language/Haskell/Exts/Pretty.p_hi","Language/Haskell/Exts/Pretty.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/Syntax.hi","Language/Haskell/Exts/Syntax.p_hi","Language/Haskell/Exts/Syntax.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/Extension.hi","Language/Haskell/Exts/Extension.p_hi","Language/Haskell/Exts/Extension.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/Build.hi","Language/Haskell/Exts/Build.p_hi","Language/Haskell/Exts/Build.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/Fixity.hi","Language/Haskell/Exts/Fixity.p_hi","Language/Haskell/Exts/Fixity.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/Comments.hi","Language/Haskell/Exts/Comments.p_hi","Language/Haskell/Exts/Comments.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/SrcLoc.hi","Language/Haskell/Exts/SrcLoc.p_hi","Language/Haskell/Exts/SrcLoc.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/Annotated.hi","Language/Haskell/Exts/Annotated.p_hi","Language/Haskell/Exts/Annotated.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/Annotated/Syntax.hi","Language/Haskell/Exts/Annotated/Syntax.p_hi","Language/Haskell/Exts/Annotated/Syntax.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/Annotated/Fixity.hi","Language/Haskell/Exts/Annotated/Fixity.p_hi","Language/Haskell/Exts/Annotated/Fixity.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/Annotated/Build.hi","Language/Haskell/Exts/Annotated/Build.p_hi","Language/Haskell/Exts/Annotated/Build.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/Annotated/ExactPrint.hi","Language/Haskell/Exts/Annotated/ExactPrint.p_hi","Language/Haskell/Exts/Annotated/ExactPrint.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/Annotated/Simplify.hi","Language/Haskell/Exts/Annotated/Simplify.p_hi","Language/Haskell/Exts/Annotated/Simplify.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/ExtScheme.hi","Language/Haskell/Exts/ExtScheme.p_hi","Language/Haskell/Exts/ExtScheme.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/ParseMonad.hi","Language/Haskell/Exts/ParseMonad.p_hi","Language/Haskell/Exts/ParseMonad.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/ParseSyntax.hi","Language/Haskell/Exts/ParseSyntax.p_hi","Language/Haskell/Exts/ParseSyntax.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/InternalLexer.hi","Language/Haskell/Exts/InternalLexer.p_hi","Language/Haskell/Exts/InternalLexer.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/ParseUtils.hi","Language/Haskell/Exts/ParseUtils.p_hi","Language/Haskell/Exts/ParseUtils.dyn_hi"\]
> cannot find any of \["Language/Haskell/Exts/InternalParser.hi","Language/Haskell/Exts/InternalParser.p_hi","Language/Haskell/Exts/InternalParser.dyn_hi"\]
> cannot find any of \["libHShaskell-src-exts-1.16.0.1.a","libHShaskell-src-exts-1.16.0.1.p_a","libHShaskell-src-exts-1.16.0.1-ghc7.8.4.so","libHShaskell-src-exts-1.16.0.1-ghc7.8.4.dylib","HShaskell-src-exts-1.16.0.1-ghc7.8.4.dll"\] on library path
There are problems in package aeson-0.8.0.2:
> Warning: library-dirs: /home/developer/.cabal/lib/x86_64-linux-ghc-7.8.4/aeson-0.8.0.2 doesn't exist or isn't a directory
1. ..
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC binary package seems to be corrupt","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Installed https://www.haskell.org/ghc/dist/7.8.4/ghc-7.8.4-x86_64-unknown-linux-deb7.tar.bz2\r\n\r\nDid ghc-pkg check\r\n\r\nGot: \r\n\r\nghc-pkg check\r\nThere are problems in package haskell-src-exts-1.16.0.1:\r\n Warning: library-dirs: /home/developer/.cabal/lib/x86_64-linux-ghc-7.8.4/haskell-src-exts-1.16.0.1 doesn't exist or isn't a directory\r\n Warning: haddock-interfaces: /home/developer/.cabal/share/doc/x86_64-linux-ghc-7.8.4/haskell-src-exts-1.16.0.1/html/haskell-src-exts.haddock doesn't exist or isn't a file\r\n Warning: haddock-html: /home/developer/.cabal/share/doc/x86_64-linux-ghc-7.8.4/haskell-src-exts-1.16.0.1/html doesn't exist or isn't a directory\r\n import-dirs: /home/developer/.cabal/lib/x86_64-linux-ghc-7.8.4/haskell-src-exts-1.16.0.1 doesn't exist or isn't a directory\r\n cannot find any of [\"Language/Haskell/Exts.hi\",\"Language/Haskell/Exts.p_hi\",\"Language/Haskell/Exts.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/Lexer.hi\",\"Language/Haskell/Exts/Lexer.p_hi\",\"Language/Haskell/Exts/Lexer.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/Parser.hi\",\"Language/Haskell/Exts/Parser.p_hi\",\"Language/Haskell/Exts/Parser.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/Pretty.hi\",\"Language/Haskell/Exts/Pretty.p_hi\",\"Language/Haskell/Exts/Pretty.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/Syntax.hi\",\"Language/Haskell/Exts/Syntax.p_hi\",\"Language/Haskell/Exts/Syntax.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/Extension.hi\",\"Language/Haskell/Exts/Extension.p_hi\",\"Language/Haskell/Exts/Extension.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/Build.hi\",\"Language/Haskell/Exts/Build.p_hi\",\"Language/Haskell/Exts/Build.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/Fixity.hi\",\"Language/Haskell/Exts/Fixity.p_hi\",\"Language/Haskell/Exts/Fixity.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/Comments.hi\",\"Language/Haskell/Exts/Comments.p_hi\",\"Language/Haskell/Exts/Comments.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/SrcLoc.hi\",\"Language/Haskell/Exts/SrcLoc.p_hi\",\"Language/Haskell/Exts/SrcLoc.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/Annotated.hi\",\"Language/Haskell/Exts/Annotated.p_hi\",\"Language/Haskell/Exts/Annotated.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/Annotated/Syntax.hi\",\"Language/Haskell/Exts/Annotated/Syntax.p_hi\",\"Language/Haskell/Exts/Annotated/Syntax.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/Annotated/Fixity.hi\",\"Language/Haskell/Exts/Annotated/Fixity.p_hi\",\"Language/Haskell/Exts/Annotated/Fixity.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/Annotated/Build.hi\",\"Language/Haskell/Exts/Annotated/Build.p_hi\",\"Language/Haskell/Exts/Annotated/Build.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/Annotated/ExactPrint.hi\",\"Language/Haskell/Exts/Annotated/ExactPrint.p_hi\",\"Language/Haskell/Exts/Annotated/ExactPrint.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/Annotated/Simplify.hi\",\"Language/Haskell/Exts/Annotated/Simplify.p_hi\",\"Language/Haskell/Exts/Annotated/Simplify.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/ExtScheme.hi\",\"Language/Haskell/Exts/ExtScheme.p_hi\",\"Language/Haskell/Exts/ExtScheme.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/ParseMonad.hi\",\"Language/Haskell/Exts/ParseMonad.p_hi\",\"Language/Haskell/Exts/ParseMonad.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/ParseSyntax.hi\",\"Language/Haskell/Exts/ParseSyntax.p_hi\",\"Language/Haskell/Exts/ParseSyntax.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/InternalLexer.hi\",\"Language/Haskell/Exts/InternalLexer.p_hi\",\"Language/Haskell/Exts/InternalLexer.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/ParseUtils.hi\",\"Language/Haskell/Exts/ParseUtils.p_hi\",\"Language/Haskell/Exts/ParseUtils.dyn_hi\"]\r\n cannot find any of [\"Language/Haskell/Exts/InternalParser.hi\",\"Language/Haskell/Exts/InternalParser.p_hi\",\"Language/Haskell/Exts/InternalParser.dyn_hi\"]\r\n cannot find any of [\"libHShaskell-src-exts-1.16.0.1.a\",\"libHShaskell-src-exts-1.16.0.1.p_a\",\"libHShaskell-src-exts-1.16.0.1-ghc7.8.4.so\",\"libHShaskell-src-exts-1.16.0.1-ghc7.8.4.dylib\",\"HShaskell-src-exts-1.16.0.1-ghc7.8.4.dll\"] on library path\r\nThere are problems in package aeson-0.8.0.2:\r\n Warning: library-dirs: /home/developer/.cabal/lib/x86_64-linux-ghc-7.8.4/aeson-0.8.0.2 doesn't exist or isn't a directory\r\n\r\n...\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/9625ghc: panic using --enable-executable-dynamic2019-07-07T18:39:46ZCoreyOConnorghc: panic using --enable-executable-dynamic(from: https://github.com/haskell/cabal/issues/2039)
Using --enable-executable-dynamic leads to a ghc panic.
Reproduction steps:
```
1. git clone https://github.com/coreyoconnor/executable-dynamic-issue
2. cabal configure --enable-tes...(from: https://github.com/haskell/cabal/issues/2039)
Using --enable-executable-dynamic leads to a ghc panic.
Reproduction steps:
```
1. git clone https://github.com/coreyoconnor/executable-dynamic-issue
2. cabal configure --enable-tests --enable-executable-dynamic
3. cabal test
```
Expected results: Test executes and passes.
Actual results:
```
ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): Don't understand library name verify-foo
```
Actual results varies based on the name of "verify-foo" test suite. Other names tried: "verifyFoo", "VerifyFoo". All of which also fail.
Removing "--enable-executable-dynamic" results in a pass regardless of test suite name.
Reproduced on GHC 7.8.2, GHC 7.8.3, Cabal 1.18, Cabal 1.20. Ubuntu.https://gitlab.haskell.org/ghc/ghc/-/issues/9375Support for module thinning/renaming on command line2019-07-07T18:40:40ZEdward Z. YangSupport for module thinning/renaming on command lineIn #8407, we added the capability for packages to reexport modules from other packages. This ticket is for the dual operation: during the compilation of a module, rather than being forced dump all of the exposed modules of package foo wh...In #8407, we added the capability for packages to reexport modules from other packages. This ticket is for the dual operation: during the compilation of a module, rather than being forced dump all of the exposed modules of package foo when I say `-package foo`, I should be able to selectively pick which modules I make visible (thinning) and rename them, if I like. For now, the proposed syntax is for all package flags, I can now write `-package "foo (A as B, C)"`.
This feature has special implications for how the package database hiding/showing works. Currently, if I write `-package foo-0.1`, this will automatically go ahead and un-expose any other packages named `foo` that I may have loaded. But if I write `-package foo-0.1 (Foo as Foo1) -package foo-0.2 (Foo as Foo2)`, I probably didn't actually want to hide the old instance of `foo-0.1` when I exposed `foo-0.2`. More generally, rather than thinking of package configuration as flipping exposed/not-exposed bits on and off of an in-memory package database, we would rather think of it as setting up a mapping of module names to their implementations, and only reporting a conflict when there is an inconsistent module mapping.
Since this is a change of behavior, I propose two sets of semantics, controlled by a flag `-backpack` (but really, I mostly care about the second set). Flag naming can be negotiated.
In the \*\*absence\*\* of `-backpack`, thinning/renaming works by modifying the exposed/reexported module fields of the matched packages in the database. However, the old hiding behavior still applies, so this functionality would primarily be useful if two separate packages exported a module with the same name, and you still wanted to use both of them. So, the original example would not do what you want, but `-package mtl (Control.Monad.Trans as MtlTrans) -package transformers (Control.Monad.Trans as TransformersTrans)` would DTRT.
- \*With\*\* the `-backpack` flag, no auto-hiding of packages occurs (this affects flags with thinning and renaming). Furthermore, the package database is cleared, as would be done with `-hide-all-packages`. We replace the old resolution algorithm with the new one, which processes each flag one-by-one while building a module mapping, picking a package which is consistent with the currently selected set of packages. This consistency is done by looking at the current module mapping and ensuring all of the modules the package would bring into scope are consistent with the modules we have already. Both example shown before would work; furthermore, `-package foo -package foo` would also continue to work, since `foo`'s exports are consistent with itself. However, `-package foo-0.1 -package foo-0.2` would be rejected (whereas now it is accepted.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.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 module thinning/renaming on command line","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ezyang"},"version":"7.8.2","keywords":["backpack"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"In #8407, we added the capability for packages to reexport modules from other packages. This ticket is for the dual operation: during the compilation of a module, rather than being forced dump all of the exposed modules of package foo when I say `-package foo`, I should be able to selectively pick which modules I make visible (thinning) and rename them, if I like. For now, the proposed syntax is for all package flags, I can now write `-package \"foo (A as B, C)\"`.\r\n\r\nThis feature has special implications for how the package database hiding/showing works. Currently, if I write `-package foo-0.1`, this will automatically go ahead and un-expose any other packages named `foo` that I may have loaded. But if I write `-package foo-0.1 (Foo as Foo1) -package foo-0.2 (Foo as Foo2)`, I probably didn't actually want to hide the old instance of `foo-0.1` when I exposed `foo-0.2`. More generally, rather than thinking of package configuration as flipping exposed/not-exposed bits on and off of an in-memory package database, we would rather think of it as setting up a mapping of module names to their implementations, and only reporting a conflict when there is an inconsistent module mapping.\r\n\r\nSince this is a change of behavior, I propose two sets of semantics, controlled by a flag `-backpack` (but really, I mostly care about the second set). Flag naming can be negotiated.\r\n\r\nIn the **absence** of `-backpack`, thinning/renaming works by modifying the exposed/reexported module fields of the matched packages in the database. However, the old hiding behavior still applies, so this functionality would primarily be useful if two separate packages exported a module with the same name, and you still wanted to use both of them. So, the original example would not do what you want, but `-package mtl (Control.Monad.Trans as MtlTrans) -package transformers (Control.Monad.Trans as TransformersTrans)` would DTRT.\r\n\r\n**With** the `-backpack` flag, no auto-hiding of packages occurs (this affects flags with thinning and renaming). Furthermore, the package database is cleared, as would be done with `-hide-all-packages`. We replace the old resolution algorithm with the new one, which processes each flag one-by-one while building a module mapping, picking a package which is consistent with the currently selected set of packages. This consistency is done by looking at the current module mapping and ensuring all of the modules the package would bring into scope are consistent with the modules we have already. Both example shown before would work; furthermore, `-package foo -package foo` would also continue to work, since `foo`'s exports are consistent with itself. However, `-package foo-0.1 -package foo-0.2` would be rejected (whereas now it is accepted.)","type_of_failure":"OtherFailure","blocking":[]} -->Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/9060`cabal` linking error with GHC 7.8.22019-07-07T18:42:06Zpseudonom`cabal` linking error with GHC 7.8.2First reported on [GitHub](https://github.com/haskell/cabal/issues/1830).
Trying
```
rm -r .ghc .cabal
cabal update
cabal install cabal-install # Update from 1.16.0.2 to 1.20.0.0
cabal install polyparse
```
with GHC 7.8.2 throws the f...First reported on [GitHub](https://github.com/haskell/cabal/issues/1830).
Trying
```
rm -r .ghc .cabal
cabal update
cabal install cabal-install # Update from 1.16.0.2 to 1.20.0.0
cabal install polyparse
```
with GHC 7.8.2 throws the following error:
```
[18 of 18] Compiling Text.ParserCombinators.HuttonMeijer ( src/Text/ParserCombinators/HuttonMeijer.hs, dist/build/Text/ParserCombinators/HuttonMeijer.o )
src/Text/ParserCombinators/HuttonMeijer.hs:53:10: Warning:
‘Parser’ is an instance of Monad but not Applicative - this will become an error in GHC 7.10, under the Applicative-Monad Proposal.
src/Text/ParserCombinators/HuttonMeijer.hs:63:10: Warning:
‘Parser’ is an instance of MonadPlus but not Alternative - this will become an error in GHC 7.10, under the Applicative-Monad Proposal.
Linking...
/usr/bin/ar -r dist/build/libHSpolyparse-1.9.a-12038/libHSpolyparse-1.9.a dist/build/Text/ParserCombinators/HuttonMeijer.o dist/build/Text/ParserCombinators/HuttonMeijerWallace.o dist/build/Text/ParserCombinators/Poly.o dist/build/Text/ParserCombinators/Poly/Base.o dist/build/Text/ParserCombinators/Poly/Result.o dist/build/Text/ParserCombinators/Poly/Parser.o dist/build/Text/ParserCombinators/Poly/Plain.o dist/build/Text/ParserCombinators/Poly/Lazy.o dist/build/Text/ParserCombinators/Poly/StateParser.o dist/build/Text/ParserCombinators/Poly/State.o dist/build/Text/ParserCombinators/Poly/StateLazy.o dist/build/Text/ParserCombinators/Poly/Lex.o dist/build/Text/Parse.o dist/build/Text/ParserCombinators/Poly/ByteString.o dist/build/Text/ParserCombinators/Poly/ByteStringChar.o dist/build/Text/Parse/ByteString.o dist/build/Text/ParserCombinators/Poly/Text.o dist/build/Text/ParserCombinators/Poly/StateText.o
/usr/bin/ar: creating dist/build/libHSpolyparse-1.9.a-12038/libHSpolyparse-1.9.a
/usr/bin/strip dist/build/libHSpolyparse-1.9.a-12038/libHSpolyparse-1.9.a --strip-unneeded
/usr/bin/ghc -shared -dynamic -package-name polyparse-1.9 -no-auto-link-packages -package-db dist/package.conf.inplace -package-id base-4.7.0.0-018311399e3b6350d5be3a16b144df9b -package-id bytestring-0.10.4.0-7de5230c6d895786641a4de344336838 -package-id text-1.1.1.1-dd6849c4a01e66d368eb3b161ca67182 dist/build/Text/ParserCombinators/HuttonMeijer.dyn_o dist/build/Text/ParserCombinators/HuttonMeijerWallace.dyn_o dist/build/Text/ParserCombinators/Poly.dyn_o dist/build/Text/ParserCombinators/Poly/Base.dyn_o dist/build/Text/ParserCombinators/Poly/Result.dyn_o dist/build/Text/ParserCombinators/Poly/Parser.dyn_o dist/build/Text/ParserCombinators/Poly/Plain.dyn_o dist/build/Text/ParserCombinators/Poly/Lazy.dyn_o dist/build/Text/ParserCombinators/Poly/StateParser.dyn_o dist/build/Text/ParserCombinators/Poly/State.dyn_o dist/build/Text/ParserCombinators/Poly/StateLazy.dyn_o dist/build/Text/ParserCombinators/Poly/Lex.dyn_o dist/build/Text/Parse.dyn_o dist/build/Text/ParserCombinators/Poly/ByteString.dyn_o dist/build/Text/ParserCombinators/Poly/ByteStringChar.dyn_o dist/build/Text/Parse/ByteString.dyn_o dist/build/Text/ParserCombinators/Poly/Text.dyn_o dist/build/Text/ParserCombinators/Poly/StateText.dyn_o -o dist/build/libHSpolyparse-1.9-ghc7.8.2.so
/usr/bin/ld: cannot find -lHStext-1.1.1.1-ghc7.8.2
collect2: error: ld returned 1 exit status
Failed to install polyparse-1.9
Updating world file...
cabal: Error: some packages failed to install:
polyparse-1.9 failed during the building phase. The exception was:
ExitFailure 1
```
It happens with other packages as well. `hashable`, for example. The `text` that `polyparse` fails on is installed as a transitive dependency of `cabal-install`:
```
...
[43 of 43] Compiling Data.Text.Read ( Data/Text/Read.hs, dist/build/Data/Text/Read.o )
Building C Sources...
creating dist/build
/usr/bin/ghc -c -odir dist/build -Idist/build -Iinclude -optc-O2 -package-db dist/package.conf.inplace -package-id array-0.5.0.0-9f212a0e8caa74d931af75060b4de2ab -package-id base-4.7.0.0-018311399e3b6350d5be3a16b144df9b -package-id bytestring-0.10.4.0-7de5230c6d895786641a4de344336838 -package-id deepseq-1.3.0.2-7160f83fdfe69b3794a2d7a3ad8d4c19 -package-id ghc-prim-0.3.1.0-948744e1f99cc8bcc7c7d3ba60c7c2d8 -package-id integer-gmp-0.5.1.0-dc47f6b546fc171f67a7f7d311684a99 cbits/cbits.c
Linking...
/usr/bin/ar -r dist/build/libHStext-1.1.1.1.a dist/build/Data/Text.o dist/build/Data/Text/Array.o dist/build/Data/Text/Encoding.o dist/build/Data/Text/Encoding/Error.o dist/build/Data/Text/Foreign.o dist/build/Data/Text/IO.o dist/build/Data/Text/Internal.o dist/build/Data/Text/Internal/Builder.o dist/build/Data/Text/Internal/Builder/Functions.o dist/build/Data/Text/Internal/Builder/Int/Digits.o dist/build/Data/Text/Internal/Builder/RealFloat/Functions.o dist/build/Data/Text/Internal/Encoding/Fusion.o dist/build/Data/Text/Internal/Encoding/Fusion/Common.o dist/build/Data/Text/Internal/Encoding/Utf16.o dist/build/Data/Text/Internal/Encoding/Utf32.o dist/build/Data/Text/Internal/Encoding/Utf8.o dist/build/Data/Text/Internal/Functions.o dist/build/Data/Text/Internal/Fusion.o dist/build/Data/Text/Internal/Fusion/CaseMapping.o dist/build/Data/Text/Internal/Fusion/Common.o dist/build/Data/Text/Internal/Fusion/Size.o dist/build/Data/Text/Internal/Fusion/Types.o dist/build/Data/Text/Internal/IO.o dist/build/Data/Text/Internal/Lazy.o dist/build/Data/Text/Internal/Lazy/Encoding/Fusion.o dist/build/Data/Text/Internal/Lazy/Fusion.o dist/build/Data/Text/Internal/Lazy/Search.o dist/build/Data/Text/Internal/Private.o dist/build/Data/Text/Internal/Read.o dist/build/Data/Text/Internal/Search.o dist/build/Data/Text/Internal/Unsafe.o dist/build/Data/Text/Internal/Unsafe/Char.o dist/build/Data/Text/Internal/Unsafe/Shift.o dist/build/Data/Text/Lazy.o dist/build/Data/Text/Lazy/Builder.o dist/build/Data/Text/Lazy/Builder/Int.o dist/build/Data/Text/Lazy/Builder/RealFloat.o dist/build/Data/Text/Lazy/Encoding.o dist/build/Data/Text/Lazy/IO.o dist/build/Data/Text/Lazy/Internal.o dist/build/Data/Text/Lazy/Read.o dist/build/Data/Text/Read.o dist/build/Data/Text/Unsafe.o dist/build/cbits/cbits.o
/usr/bin/ar: creating dist/build/libHStext-1.1.1.1.a
/usr/bin/ld -x -r -o dist/build/HStext-1.1.1.1.o dist/build/Data/Text.o dist/build/Data/Text/Array.o dist/build/Data/Text/Encoding.o dist/build/Data/Text/Encoding/Error.o dist/build/Data/Text/Foreign.o dist/build/Data/Text/IO.o dist/build/Data/Text/Internal.o dist/build/Data/Text/Internal/Builder.o dist/build/Data/Text/Internal/Builder/Functions.o dist/build/Data/Text/Internal/Builder/Int/Digits.o dist/build/Data/Text/Internal/Builder/RealFloat/Functions.o dist/build/Data/Text/Internal/Encoding/Fusion.o dist/build/Data/Text/Internal/Encoding/Fusion/Common.o dist/build/Data/Text/Internal/Encoding/Utf16.o dist/build/Data/Text/Internal/Encoding/Utf32.o dist/build/Data/Text/Internal/Encoding/Utf8.o dist/build/Data/Text/Internal/Functions.o dist/build/Data/Text/Internal/Fusion.o dist/build/Data/Text/Internal/Fusion/CaseMapping.o dist/build/Data/Text/Internal/Fusion/Common.o dist/build/Data/Text/Internal/Fusion/Size.o dist/build/Data/Text/Internal/Fusion/Types.o dist/build/Data/Text/Internal/IO.o dist/build/Data/Text/Internal/Lazy.o dist/build/Data/Text/Internal/Lazy/Encoding/Fusion.o dist/build/Data/Text/Internal/Lazy/Fusion.o dist/build/Data/Text/Internal/Lazy/Search.o dist/build/Data/Text/Internal/Private.o dist/build/Data/Text/Internal/Read.o dist/build/Data/Text/Internal/Search.o dist/build/Data/Text/Internal/Unsafe.o dist/build/Data/Text/Internal/Unsafe/Char.o dist/build/Data/Text/Internal/Unsafe/Shift.o dist/build/Data/Text/Lazy.o dist/build/Data/Text/Lazy/Builder.o dist/build/Data/Text/Lazy/Builder/Int.o dist/build/Data/Text/Lazy/Builder/RealFloat.o dist/build/Data/Text/Lazy/Encoding.o dist/build/Data/Text/Lazy/IO.o dist/build/Data/Text/Lazy/Internal.o dist/build/Data/Text/Lazy/Read.o dist/build/Data/Text/Read.o dist/build/Data/Text/Unsafe.o dist/build/cbits/cbits.o
In-place registering text-1.1.1.1...
/usr/bin/ghc-pkg update - --global --user --package-db=dist/package.conf.inplace
directory dist/doc/html/text does exist: False
creating /home/intrados/.cabal/share/doc/text-1.1.1.1
Installing LICENSE to /home/intrados/.cabal/share/doc/text-1.1.1.1/LICENSE
Installing library in /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2
creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data
creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2
creating /home/intrados/.cabal/lib/text-1.1.1.1
creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2
creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data
creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text
creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Encoding
creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal
creating
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Builder
creating
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Builder/Int
creating
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Builder/RealFloat
creating
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Encoding
creating
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Encoding/Fusion
creating
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Fusion
creating
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy/Encoding
creating
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy
creating
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy/Encoding
creating
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy
creating
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Unsafe
creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy
creating
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/Builder
Installing dist/build/Data/Text.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text.hi
Installing dist/build/Data/Text/Array.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Array.hi
Installing dist/build/Data/Text/Encoding.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Encoding.hi
Installing dist/build/Data/Text/Encoding/Error.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Encoding/Error.hi
Installing dist/build/Data/Text/Foreign.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Foreign.hi
Installing dist/build/Data/Text/IO.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/IO.hi
Installing dist/build/Data/Text/Internal.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal.hi
Installing dist/build/Data/Text/Internal/Builder.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Builder.hi
Installing dist/build/Data/Text/Internal/Builder/Functions.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Builder/Functions.hi
Installing dist/build/Data/Text/Internal/Builder/Int/Digits.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Builder/Int/Digits.hi
Installing dist/build/Data/Text/Internal/Builder/RealFloat/Functions.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Builder/RealFloat/Functions.hi
Installing dist/build/Data/Text/Internal/Encoding/Fusion.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Encoding/Fusion.hi
Installing dist/build/Data/Text/Internal/Encoding/Fusion/Common.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Encoding/Fusion/Common.hi
Installing dist/build/Data/Text/Internal/Encoding/Utf16.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Encoding/Utf16.hi
Installing dist/build/Data/Text/Internal/Encoding/Utf32.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Encoding/Utf32.hi
Installing dist/build/Data/Text/Internal/Encoding/Utf8.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Encoding/Utf8.hi
Installing dist/build/Data/Text/Internal/Functions.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Functions.hi
Installing dist/build/Data/Text/Internal/Fusion.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Fusion.hi
Installing dist/build/Data/Text/Internal/Fusion/CaseMapping.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Fusion/CaseMapping.hi
Installing dist/build/Data/Text/Internal/Fusion/Common.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Fusion/Common.hi
Installing dist/build/Data/Text/Internal/Fusion/Size.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Fusion/Size.hi
Installing dist/build/Data/Text/Internal/Fusion/Types.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Fusion/Types.hi
Installing dist/build/Data/Text/Internal/IO.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/IO.hi
Installing dist/build/Data/Text/Internal/Lazy.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy.hi
Installing dist/build/Data/Text/Internal/Lazy/Encoding/Fusion.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy/Encoding/Fusion.hi
Installing dist/build/Data/Text/Internal/Lazy/Fusion.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy/Fusion.hi
Installing dist/build/Data/Text/Internal/Lazy/Search.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy/Search.hi
Installing dist/build/Data/Text/Internal/Private.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Private.hi
Installing dist/build/Data/Text/Internal/Read.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Read.hi
Installing dist/build/Data/Text/Internal/Search.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Search.hi
Installing dist/build/Data/Text/Internal/Unsafe.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Unsafe.hi
Installing dist/build/Data/Text/Internal/Unsafe/Char.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Unsafe/Char.hi
Installing dist/build/Data/Text/Internal/Unsafe/Shift.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Unsafe/Shift.hi
Installing dist/build/Data/Text/Lazy.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy.hi
Installing dist/build/Data/Text/Lazy/Builder.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/Builder.hi
Installing dist/build/Data/Text/Lazy/Builder/Int.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/Builder/Int.hi
Installing dist/build/Data/Text/Lazy/Builder/RealFloat.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/Builder/RealFloat.hi
Installing dist/build/Data/Text/Lazy/Encoding.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/Encoding.hi
Installing dist/build/Data/Text/Lazy/IO.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/IO.hi
Installing dist/build/Data/Text/Lazy/Internal.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/Internal.hi
Installing dist/build/Data/Text/Lazy/Read.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/Read.hi
Installing dist/build/Data/Text/Read.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Read.hi
Installing dist/build/Data/Text/Unsafe.hi to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Unsafe.hi
creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2
Installing dist/build/libHStext-1.1.1.1.a to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/libHStext-1.1.1.1.a
creating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2
Installing dist/build/HStext-1.1.1.1.o to
/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/HStext-1.1.1.1.o
/usr/bin/ghc --abi-hash -fbuilding-cabal-package -O -odir dist/build -hidir dist/build -stubdir dist/build -i -idist/build -i. -idist/build/autogen -Idist/build/autogen -Idist/build -Iinclude -optP-DINTEGER_GMP -optP-DHAVE_DEEPSEQ -optP-include -optPdist/build/autogen/cabal_macros.h -package-name text-1.1.1.1 -hide-all-packages -package-id array-0.5.0.0-9f212a0e8caa74d931af75060b4de2ab -package-id base-4.7.0.0-018311399e3b6350d5be3a16b144df9b -package-id bytestring-0.10.4.0-7de5230c6d895786641a4de344336838 -package-id deepseq-1.3.0.2-7160f83fdfe69b3794a2d7a3ad8d4c19 -package-id ghc-prim-0.3.1.0-948744e1f99cc8bcc7c7d3ba60c7c2d8 -package-id integer-gmp-0.5.1.0-dc47f6b546fc171f67a7f7d311684a99 -XHaskell98 Data.Text Data.Text.Array Data.Text.Encoding Data.Text.Encoding.Error Data.Text.Foreign Data.Text.IO Data.Text.Internal Data.Text.Internal.Builder Data.Text.Internal.Builder.Functions Data.Text.Internal.Builder.Int.Digits Data.Text.Internal.Builder.RealFloat.Functions Data.Text.Internal.Encoding.Fusion Data.Text.Internal.Encoding.Fusion.Common Data.Text.Internal.Encoding.Utf16 Data.Text.Internal.Encoding.Utf32 Data.Text.Internal.Encoding.Utf8 Data.Text.Internal.Functions Data.Text.Internal.Fusion Data.Text.Internal.Fusion.CaseMapping Data.Text.Internal.Fusion.Common Data.Text.Internal.Fusion.Size Data.Text.Internal.Fusion.Types Data.Text.Internal.IO Data.Text.Internal.Lazy Data.Text.Internal.Lazy.Encoding.Fusion Data.Text.Internal.Lazy.Fusion Data.Text.Internal.Lazy.Search Data.Text.Internal.Private Data.Text.Internal.Read Data.Text.Internal.Search Data.Text.Internal.Unsafe Data.Text.Internal.Unsafe.Char Data.Text.Internal.Unsafe.Shift Data.Text.Lazy Data.Text.Lazy.Builder Data.Text.Lazy.Builder.Int Data.Text.Lazy.Builder.RealFloat Data.Text.Lazy.Encoding Data.Text.Lazy.IO Data.Text.Lazy.Internal Data.Text.Lazy.Read Data.Text.Read Data.Text.Unsafe -Wall -fwarn-tabs -funbox-strict-fields -O2
Registering text-1.1.1.1...
/usr/bin/ghc-pkg update - --global --user
Installed text-1.1.1.1
```
The same procedure succeeds with a clean GHC 7.6.3.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.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":"`cabal` linking error with GHC 7.8.2","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"First reported on [https://github.com/haskell/cabal/issues/1830 GitHub].\r\n\r\nTrying\r\n\r\n{{{\r\nrm -r .ghc .cabal\r\ncabal update\r\ncabal install cabal-install # Update from 1.16.0.2 to 1.20.0.0\r\ncabal install polyparse\r\n}}}\r\n\r\nwith GHC 7.8.2 throws the following error:\r\n\r\n{{{\r\n[18 of 18] Compiling Text.ParserCombinators.HuttonMeijer ( src/Text/ParserCombinators/HuttonMeijer.hs, dist/build/Text/ParserCombinators/HuttonMeijer.o )\r\n\r\nsrc/Text/ParserCombinators/HuttonMeijer.hs:53:10: Warning:\r\n ‘Parser’ is an instance of Monad but not Applicative - this will become an error in GHC 7.10, under the Applicative-Monad Proposal.\r\n\r\nsrc/Text/ParserCombinators/HuttonMeijer.hs:63:10: Warning:\r\n ‘Parser’ is an instance of MonadPlus but not Alternative - this will become an error in GHC 7.10, under the Applicative-Monad Proposal.\r\nLinking...\r\n/usr/bin/ar -r dist/build/libHSpolyparse-1.9.a-12038/libHSpolyparse-1.9.a dist/build/Text/ParserCombinators/HuttonMeijer.o dist/build/Text/ParserCombinators/HuttonMeijerWallace.o dist/build/Text/ParserCombinators/Poly.o dist/build/Text/ParserCombinators/Poly/Base.o dist/build/Text/ParserCombinators/Poly/Result.o dist/build/Text/ParserCombinators/Poly/Parser.o dist/build/Text/ParserCombinators/Poly/Plain.o dist/build/Text/ParserCombinators/Poly/Lazy.o dist/build/Text/ParserCombinators/Poly/StateParser.o dist/build/Text/ParserCombinators/Poly/State.o dist/build/Text/ParserCombinators/Poly/StateLazy.o dist/build/Text/ParserCombinators/Poly/Lex.o dist/build/Text/Parse.o dist/build/Text/ParserCombinators/Poly/ByteString.o dist/build/Text/ParserCombinators/Poly/ByteStringChar.o dist/build/Text/Parse/ByteString.o dist/build/Text/ParserCombinators/Poly/Text.o dist/build/Text/ParserCombinators/Poly/StateText.o\r\n/usr/bin/ar: creating dist/build/libHSpolyparse-1.9.a-12038/libHSpolyparse-1.9.a\r\n/usr/bin/strip dist/build/libHSpolyparse-1.9.a-12038/libHSpolyparse-1.9.a --strip-unneeded\r\n/usr/bin/ghc -shared -dynamic -package-name polyparse-1.9 -no-auto-link-packages -package-db dist/package.conf.inplace -package-id base-4.7.0.0-018311399e3b6350d5be3a16b144df9b -package-id bytestring-0.10.4.0-7de5230c6d895786641a4de344336838 -package-id text-1.1.1.1-dd6849c4a01e66d368eb3b161ca67182 dist/build/Text/ParserCombinators/HuttonMeijer.dyn_o dist/build/Text/ParserCombinators/HuttonMeijerWallace.dyn_o dist/build/Text/ParserCombinators/Poly.dyn_o dist/build/Text/ParserCombinators/Poly/Base.dyn_o dist/build/Text/ParserCombinators/Poly/Result.dyn_o dist/build/Text/ParserCombinators/Poly/Parser.dyn_o dist/build/Text/ParserCombinators/Poly/Plain.dyn_o dist/build/Text/ParserCombinators/Poly/Lazy.dyn_o dist/build/Text/ParserCombinators/Poly/StateParser.dyn_o dist/build/Text/ParserCombinators/Poly/State.dyn_o dist/build/Text/ParserCombinators/Poly/StateLazy.dyn_o dist/build/Text/ParserCombinators/Poly/Lex.dyn_o dist/build/Text/Parse.dyn_o dist/build/Text/ParserCombinators/Poly/ByteString.dyn_o dist/build/Text/ParserCombinators/Poly/ByteStringChar.dyn_o dist/build/Text/Parse/ByteString.dyn_o dist/build/Text/ParserCombinators/Poly/Text.dyn_o dist/build/Text/ParserCombinators/Poly/StateText.dyn_o -o dist/build/libHSpolyparse-1.9-ghc7.8.2.so\r\n/usr/bin/ld: cannot find -lHStext-1.1.1.1-ghc7.8.2\r\ncollect2: error: ld returned 1 exit status\r\nFailed to install polyparse-1.9\r\nUpdating world file...\r\ncabal: Error: some packages failed to install:\r\npolyparse-1.9 failed during the building phase. The exception was:\r\nExitFailure 1\r\n}}}\r\n\r\nIt happens with other packages as well. {{{hashable}}}, for example. The {{{text}}} that {{{polyparse}}} fails on is installed as a transitive dependency of {{{cabal-install}}}:\r\n\r\n{{{\r\n...\r\n[43 of 43] Compiling Data.Text.Read ( Data/Text/Read.hs, dist/build/Data/Text/Read.o )\r\nBuilding C Sources...\r\ncreating dist/build\r\n/usr/bin/ghc -c -odir dist/build -Idist/build -Iinclude -optc-O2 -package-db dist/package.conf.inplace -package-id array-0.5.0.0-9f212a0e8caa74d931af75060b4de2ab -package-id base-4.7.0.0-018311399e3b6350d5be3a16b144df9b -package-id bytestring-0.10.4.0-7de5230c6d895786641a4de344336838 -package-id deepseq-1.3.0.2-7160f83fdfe69b3794a2d7a3ad8d4c19 -package-id ghc-prim-0.3.1.0-948744e1f99cc8bcc7c7d3ba60c7c2d8 -package-id integer-gmp-0.5.1.0-dc47f6b546fc171f67a7f7d311684a99 cbits/cbits.c\r\nLinking...\r\n/usr/bin/ar -r dist/build/libHStext-1.1.1.1.a dist/build/Data/Text.o dist/build/Data/Text/Array.o dist/build/Data/Text/Encoding.o dist/build/Data/Text/Encoding/Error.o dist/build/Data/Text/Foreign.o dist/build/Data/Text/IO.o dist/build/Data/Text/Internal.o dist/build/Data/Text/Internal/Builder.o dist/build/Data/Text/Internal/Builder/Functions.o dist/build/Data/Text/Internal/Builder/Int/Digits.o dist/build/Data/Text/Internal/Builder/RealFloat/Functions.o dist/build/Data/Text/Internal/Encoding/Fusion.o dist/build/Data/Text/Internal/Encoding/Fusion/Common.o dist/build/Data/Text/Internal/Encoding/Utf16.o dist/build/Data/Text/Internal/Encoding/Utf32.o dist/build/Data/Text/Internal/Encoding/Utf8.o dist/build/Data/Text/Internal/Functions.o dist/build/Data/Text/Internal/Fusion.o dist/build/Data/Text/Internal/Fusion/CaseMapping.o dist/build/Data/Text/Internal/Fusion/Common.o dist/build/Data/Text/Internal/Fusion/Size.o dist/build/Data/Text/Internal/Fusion/Types.o dist/build/Data/Text/Internal/IO.o dist/build/Data/Text/Internal/Lazy.o dist/build/Data/Text/Internal/Lazy/Encoding/Fusion.o dist/build/Data/Text/Internal/Lazy/Fusion.o dist/build/Data/Text/Internal/Lazy/Search.o dist/build/Data/Text/Internal/Private.o dist/build/Data/Text/Internal/Read.o dist/build/Data/Text/Internal/Search.o dist/build/Data/Text/Internal/Unsafe.o dist/build/Data/Text/Internal/Unsafe/Char.o dist/build/Data/Text/Internal/Unsafe/Shift.o dist/build/Data/Text/Lazy.o dist/build/Data/Text/Lazy/Builder.o dist/build/Data/Text/Lazy/Builder/Int.o dist/build/Data/Text/Lazy/Builder/RealFloat.o dist/build/Data/Text/Lazy/Encoding.o dist/build/Data/Text/Lazy/IO.o dist/build/Data/Text/Lazy/Internal.o dist/build/Data/Text/Lazy/Read.o dist/build/Data/Text/Read.o dist/build/Data/Text/Unsafe.o dist/build/cbits/cbits.o\r\n/usr/bin/ar: creating dist/build/libHStext-1.1.1.1.a\r\n/usr/bin/ld -x -r -o dist/build/HStext-1.1.1.1.o dist/build/Data/Text.o dist/build/Data/Text/Array.o dist/build/Data/Text/Encoding.o dist/build/Data/Text/Encoding/Error.o dist/build/Data/Text/Foreign.o dist/build/Data/Text/IO.o dist/build/Data/Text/Internal.o dist/build/Data/Text/Internal/Builder.o dist/build/Data/Text/Internal/Builder/Functions.o dist/build/Data/Text/Internal/Builder/Int/Digits.o dist/build/Data/Text/Internal/Builder/RealFloat/Functions.o dist/build/Data/Text/Internal/Encoding/Fusion.o dist/build/Data/Text/Internal/Encoding/Fusion/Common.o dist/build/Data/Text/Internal/Encoding/Utf16.o dist/build/Data/Text/Internal/Encoding/Utf32.o dist/build/Data/Text/Internal/Encoding/Utf8.o dist/build/Data/Text/Internal/Functions.o dist/build/Data/Text/Internal/Fusion.o dist/build/Data/Text/Internal/Fusion/CaseMapping.o dist/build/Data/Text/Internal/Fusion/Common.o dist/build/Data/Text/Internal/Fusion/Size.o dist/build/Data/Text/Internal/Fusion/Types.o dist/build/Data/Text/Internal/IO.o dist/build/Data/Text/Internal/Lazy.o dist/build/Data/Text/Internal/Lazy/Encoding/Fusion.o dist/build/Data/Text/Internal/Lazy/Fusion.o dist/build/Data/Text/Internal/Lazy/Search.o dist/build/Data/Text/Internal/Private.o dist/build/Data/Text/Internal/Read.o dist/build/Data/Text/Internal/Search.o dist/build/Data/Text/Internal/Unsafe.o dist/build/Data/Text/Internal/Unsafe/Char.o dist/build/Data/Text/Internal/Unsafe/Shift.o dist/build/Data/Text/Lazy.o dist/build/Data/Text/Lazy/Builder.o dist/build/Data/Text/Lazy/Builder/Int.o dist/build/Data/Text/Lazy/Builder/RealFloat.o dist/build/Data/Text/Lazy/Encoding.o dist/build/Data/Text/Lazy/IO.o dist/build/Data/Text/Lazy/Internal.o dist/build/Data/Text/Lazy/Read.o dist/build/Data/Text/Read.o dist/build/Data/Text/Unsafe.o dist/build/cbits/cbits.o\r\nIn-place registering text-1.1.1.1...\r\n/usr/bin/ghc-pkg update - --global --user --package-db=dist/package.conf.inplace\r\ndirectory dist/doc/html/text does exist: False\r\ncreating /home/intrados/.cabal/share/doc/text-1.1.1.1\r\nInstalling LICENSE to /home/intrados/.cabal/share/doc/text-1.1.1.1/LICENSE\r\nInstalling library in /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2\r\ncreating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data\r\ncreating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2\r\ncreating /home/intrados/.cabal/lib/text-1.1.1.1\r\ncreating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2\r\ncreating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data\r\ncreating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text\r\ncreating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Encoding\r\ncreating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal\r\ncreating\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Builder\r\ncreating\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Builder/Int\r\ncreating\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Builder/RealFloat\r\ncreating\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Encoding\r\ncreating\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Encoding/Fusion\r\ncreating\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Fusion\r\ncreating\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy/Encoding\r\ncreating\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy\r\ncreating\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy/Encoding\r\ncreating\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy\r\ncreating\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Unsafe\r\ncreating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy\r\ncreating\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/Builder\r\nInstalling dist/build/Data/Text.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text.hi\r\nInstalling dist/build/Data/Text/Array.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Array.hi\r\nInstalling dist/build/Data/Text/Encoding.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Encoding.hi\r\nInstalling dist/build/Data/Text/Encoding/Error.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Encoding/Error.hi\r\nInstalling dist/build/Data/Text/Foreign.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Foreign.hi\r\nInstalling dist/build/Data/Text/IO.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/IO.hi\r\nInstalling dist/build/Data/Text/Internal.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal.hi\r\nInstalling dist/build/Data/Text/Internal/Builder.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Builder.hi\r\nInstalling dist/build/Data/Text/Internal/Builder/Functions.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Builder/Functions.hi\r\nInstalling dist/build/Data/Text/Internal/Builder/Int/Digits.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Builder/Int/Digits.hi\r\nInstalling dist/build/Data/Text/Internal/Builder/RealFloat/Functions.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Builder/RealFloat/Functions.hi\r\nInstalling dist/build/Data/Text/Internal/Encoding/Fusion.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Encoding/Fusion.hi\r\nInstalling dist/build/Data/Text/Internal/Encoding/Fusion/Common.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Encoding/Fusion/Common.hi\r\nInstalling dist/build/Data/Text/Internal/Encoding/Utf16.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Encoding/Utf16.hi\r\nInstalling dist/build/Data/Text/Internal/Encoding/Utf32.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Encoding/Utf32.hi\r\nInstalling dist/build/Data/Text/Internal/Encoding/Utf8.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Encoding/Utf8.hi\r\nInstalling dist/build/Data/Text/Internal/Functions.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Functions.hi\r\nInstalling dist/build/Data/Text/Internal/Fusion.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Fusion.hi\r\nInstalling dist/build/Data/Text/Internal/Fusion/CaseMapping.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Fusion/CaseMapping.hi\r\nInstalling dist/build/Data/Text/Internal/Fusion/Common.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Fusion/Common.hi\r\nInstalling dist/build/Data/Text/Internal/Fusion/Size.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Fusion/Size.hi\r\nInstalling dist/build/Data/Text/Internal/Fusion/Types.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Fusion/Types.hi\r\nInstalling dist/build/Data/Text/Internal/IO.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/IO.hi\r\nInstalling dist/build/Data/Text/Internal/Lazy.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy.hi\r\nInstalling dist/build/Data/Text/Internal/Lazy/Encoding/Fusion.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy/Encoding/Fusion.hi\r\nInstalling dist/build/Data/Text/Internal/Lazy/Fusion.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy/Fusion.hi\r\nInstalling dist/build/Data/Text/Internal/Lazy/Search.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Lazy/Search.hi\r\nInstalling dist/build/Data/Text/Internal/Private.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Private.hi\r\nInstalling dist/build/Data/Text/Internal/Read.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Read.hi\r\nInstalling dist/build/Data/Text/Internal/Search.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Search.hi\r\nInstalling dist/build/Data/Text/Internal/Unsafe.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Unsafe.hi\r\nInstalling dist/build/Data/Text/Internal/Unsafe/Char.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Unsafe/Char.hi\r\nInstalling dist/build/Data/Text/Internal/Unsafe/Shift.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Internal/Unsafe/Shift.hi\r\nInstalling dist/build/Data/Text/Lazy.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy.hi\r\nInstalling dist/build/Data/Text/Lazy/Builder.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/Builder.hi\r\nInstalling dist/build/Data/Text/Lazy/Builder/Int.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/Builder/Int.hi\r\nInstalling dist/build/Data/Text/Lazy/Builder/RealFloat.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/Builder/RealFloat.hi\r\nInstalling dist/build/Data/Text/Lazy/Encoding.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/Encoding.hi\r\nInstalling dist/build/Data/Text/Lazy/IO.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/IO.hi\r\nInstalling dist/build/Data/Text/Lazy/Internal.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/Internal.hi\r\nInstalling dist/build/Data/Text/Lazy/Read.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Lazy/Read.hi\r\nInstalling dist/build/Data/Text/Read.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Read.hi\r\nInstalling dist/build/Data/Text/Unsafe.hi to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/Data/Text/Unsafe.hi\r\ncreating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2\r\nInstalling dist/build/libHStext-1.1.1.1.a to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/libHStext-1.1.1.1.a\r\ncreating /home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2\r\nInstalling dist/build/HStext-1.1.1.1.o to\r\n/home/intrados/.cabal/lib/text-1.1.1.1/ghc-7.8.2/HStext-1.1.1.1.o\r\n/usr/bin/ghc --abi-hash -fbuilding-cabal-package -O -odir dist/build -hidir dist/build -stubdir dist/build -i -idist/build -i. -idist/build/autogen -Idist/build/autogen -Idist/build -Iinclude -optP-DINTEGER_GMP -optP-DHAVE_DEEPSEQ -optP-include -optPdist/build/autogen/cabal_macros.h -package-name text-1.1.1.1 -hide-all-packages -package-id array-0.5.0.0-9f212a0e8caa74d931af75060b4de2ab -package-id base-4.7.0.0-018311399e3b6350d5be3a16b144df9b -package-id bytestring-0.10.4.0-7de5230c6d895786641a4de344336838 -package-id deepseq-1.3.0.2-7160f83fdfe69b3794a2d7a3ad8d4c19 -package-id ghc-prim-0.3.1.0-948744e1f99cc8bcc7c7d3ba60c7c2d8 -package-id integer-gmp-0.5.1.0-dc47f6b546fc171f67a7f7d311684a99 -XHaskell98 Data.Text Data.Text.Array Data.Text.Encoding Data.Text.Encoding.Error Data.Text.Foreign Data.Text.IO Data.Text.Internal Data.Text.Internal.Builder Data.Text.Internal.Builder.Functions Data.Text.Internal.Builder.Int.Digits Data.Text.Internal.Builder.RealFloat.Functions Data.Text.Internal.Encoding.Fusion Data.Text.Internal.Encoding.Fusion.Common Data.Text.Internal.Encoding.Utf16 Data.Text.Internal.Encoding.Utf32 Data.Text.Internal.Encoding.Utf8 Data.Text.Internal.Functions Data.Text.Internal.Fusion Data.Text.Internal.Fusion.CaseMapping Data.Text.Internal.Fusion.Common Data.Text.Internal.Fusion.Size Data.Text.Internal.Fusion.Types Data.Text.Internal.IO Data.Text.Internal.Lazy Data.Text.Internal.Lazy.Encoding.Fusion Data.Text.Internal.Lazy.Fusion Data.Text.Internal.Lazy.Search Data.Text.Internal.Private Data.Text.Internal.Read Data.Text.Internal.Search Data.Text.Internal.Unsafe Data.Text.Internal.Unsafe.Char Data.Text.Internal.Unsafe.Shift Data.Text.Lazy Data.Text.Lazy.Builder Data.Text.Lazy.Builder.Int Data.Text.Lazy.Builder.RealFloat Data.Text.Lazy.Encoding Data.Text.Lazy.IO Data.Text.Lazy.Internal Data.Text.Lazy.Read Data.Text.Read Data.Text.Unsafe -Wall -fwarn-tabs -funbox-strict-fields -O2\r\nRegistering text-1.1.1.1...\r\n/usr/bin/ghc-pkg update - --global --user\r\nInstalled text-1.1.1.1\r\n}}}\r\n\r\nThe same procedure succeeds with a clean GHC 7.6.3.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/9009Confusing error message when loading package with TH2019-07-07T18:42:20ZJan Stolarekjan.stolarek@ed.ac.ukConfusing error message when loading package with THI got this error message when compiling a file that calls Template Haskell function from `singletons` package:
```
[1 of 1] Compiling Splices ( Splices.hs, Splices.o )
Loading package ghc-prim ... linking ... done.
Loading pack...I got this error message when compiling a file that calls Template Haskell function from `singletons` package:
```
[1 of 1] Compiling Splices ( Splices.hs, Splices.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package transformers-0.3.0.0 ... linking ... done.
Loading package pretty-1.1.1.1 ... linking ... done.
Loading package array-0.5.0.0 ... linking ... done.
Loading package deepseq-1.3.0.2 ... linking ... done.
Loading package containers-0.5.5.1 ... linking ... done.
Loading package mtl-2.1.2 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package syb-0.4.1 ... linking ... done.
Loading package th-desugar-1.4.0 ... linking ... done.
Loading package singletons-1.0 ... <command line>: can't load .so/.DLL for: /home/killy/.cabal/lib/x86_64-linux-ghc-7.8.2/singletons-1.0/libHSsingletons-1.0-ghc7.8.2.so (/home/killy/.cabal/lib/x86_64-linux-ghc-7.8.2/singletons-1.0/libHSsingletons-1.0-ghc7.8.2.so: undefined symbol: singletonszm1zi0_DataziSingletonsziSingleziMonad_lookupProxy1_info)
```
After some investigation it turned out that the module Data.Singletons.Single.Monad was not listed in singletons.cabal file - neither under exported-modules nor other-modules - when the package was installed. The error message is mostly confusing. It would be good to at least get a hint on the possible cause.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.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":"Confusing error message when loading package with TH","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I got this error message when compiling a file that calls Template Haskell function from `singletons` package:\r\n\r\n{{{\r\n[1 of 1] Compiling Splices ( Splices.hs, Splices.o )\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading package transformers-0.3.0.0 ... linking ... done.\r\nLoading package pretty-1.1.1.1 ... linking ... done.\r\nLoading package array-0.5.0.0 ... linking ... done.\r\nLoading package deepseq-1.3.0.2 ... linking ... done.\r\nLoading package containers-0.5.5.1 ... linking ... done.\r\nLoading package mtl-2.1.2 ... linking ... done.\r\nLoading package template-haskell ... linking ... done.\r\nLoading package syb-0.4.1 ... linking ... done.\r\nLoading package th-desugar-1.4.0 ... linking ... done.\r\nLoading package singletons-1.0 ... <command line>: can't load .so/.DLL for: /home/killy/.cabal/lib/x86_64-linux-ghc-7.8.2/singletons-1.0/libHSsingletons-1.0-ghc7.8.2.so (/home/killy/.cabal/lib/x86_64-linux-ghc-7.8.2/singletons-1.0/libHSsingletons-1.0-ghc7.8.2.so: undefined symbol: singletonszm1zi0_DataziSingletonsziSingleziMonad_lookupProxy1_info)\r\n}}}\r\n\r\nAfter some investigation it turned out that the module Data.Singletons.Single.Monad was not listed in singletons.cabal file - neither under exported-modules nor other-modules - when the package was installed. The error message is mostly confusing. It would be good to at least get a hint on the possible cause.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/8591Concurrent executions of ghc-pkg can cause inconstant package.cache files2022-03-29T16:17:37ZjanmConcurrent executions of ghc-pkg can cause inconstant package.cache filesI am doing 24 way parallel builds of system images, including all packages on a system. This includes ghc and multiple ghc packages.
I am seeing intermittent dependency failure from the ghc packaging system. From examining Main.hs in gh...I am doing 24 way parallel builds of system images, including all packages on a system. This includes ghc and multiple ghc packages.
I am seeing intermittent dependency failure from the ghc packaging system. From examining Main.hs in ghc-pkg, I see the function withFileAtomic write to a temporary file in package.conf.d and then atomically rename on top of a target file, package.cache in the case. With parallel execution the last rename would win, leading to lost entries in package.cache.
In my case, the following things happened: ("Building" indicates a start, "Built" indicates completion, "Installing" is setup in a separate chroot'd environment and is isolated)
The FreeBSD ports system is used to drive the Haskell build system.
The process works single threaded and fails intermittently when done in parallel.
Building: devel/hs-data-default-instances-base
Building: devel/hs-data-default-instances-containers
Building: devel/hs-data-default-instances-old-locale
Built: devel/hs-dlist
Building: devel/hs-data-default-instances-dlist
Built: devel/hs-temporary
Built: jail-image-full
Installing: system-image__jail-image-full
Built: devel/hs-base64-bytestring
Built: archivers/hs-zlib
Building: security/hs-digest
Built: devel/hs-syb
Building: textproc/hs-hs-bibutils
Building: textproc/hs-pandoc-types
Built: devel/hs-utf8-string
Built: devel/hs-data-default-instances-old-locale
Built: devel/hs-data-default-instances-containers
Built: devel/hs-data-default-instances-base
Built: devel/hs-data-default-instances-dlist
Building: devel/hs-data-default
Built: devel/hs-random
Installed: system-image__lang/ghc
Installing: system-image__archivers/hs-zlib
Installing: system-image__devel/hs-utf8-string
Installing: system-image__devel/hs-syb
Installing: system-image__devel/hs-base64-bytestring
Installing: system-image__devel/hs-data-default-class
Installing: system-image__devel/hs-dlist
Installing: system-image__devel/hs-random
Installing: system-image__devel/hs-temporary
Installing: system-image__devel/hs-extensible-exceptions
Built: devel/hs-data-default FAILED
The error from the Haskell data-default build was:
setup: At least the following dependencies are missing:
data-default-instances-base -any
Looking in the in the package.conf.d directory shows that the data-default-instances-base-0.0.1-7bdf8678f0d8637e096e397e7910f82a.conf file was present, but running "ghc-pkg list" did not show data-default-instances-base
Running /usr/local/lib/cabal/ghc-7.6.3/data-default-instances-base-0.0.1/register.sh (which was also present) caused ghc-pkg to now show data-default-instances-base.
To me this looks like a race condition between multiple instances of ghc-pkg causing the cache to become inconsistent.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | FreeBSD |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Concurrent executions of ghc-pkg can cause inconstant package.cache files","status":"New","operating_system":"FreeBSD","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":["ghc-pkg","race"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I am doing 24 way parallel builds of system images, including all packages on a system. This includes ghc and multiple ghc packages.\r\n\r\nI am seeing intermittent dependency failure from the ghc packaging system. From examining Main.hs in ghc-pkg, I see the function withFileAtomic write to a temporary file in package.conf.d and then atomically rename on top of a target file, package.cache in the case. With parallel execution the last rename would win, leading to lost entries in package.cache.\r\n\r\nIn my case, the following things happened: (\"Building\" indicates a start, \"Built\" indicates completion, \"Installing\" is setup in a separate chroot'd environment and is isolated)\r\n\r\nThe FreeBSD ports system is used to drive the Haskell build system.\r\n\r\nThe process works single threaded and fails intermittently when done in parallel.\r\n\r\nBuilding: devel/hs-data-default-instances-base\r\nBuilding: devel/hs-data-default-instances-containers\r\nBuilding: devel/hs-data-default-instances-old-locale\r\nBuilt: devel/hs-dlist \r\nBuilding: devel/hs-data-default-instances-dlist\r\nBuilt: devel/hs-temporary \r\nBuilt: jail-image-full \r\nInstalling: system-image__jail-image-full\r\nBuilt: devel/hs-base64-bytestring \r\nBuilt: archivers/hs-zlib \r\nBuilding: security/hs-digest\r\nBuilt: devel/hs-syb \r\nBuilding: textproc/hs-hs-bibutils\r\nBuilding: textproc/hs-pandoc-types\r\nBuilt: devel/hs-utf8-string \r\nBuilt: devel/hs-data-default-instances-old-locale \r\nBuilt: devel/hs-data-default-instances-containers \r\nBuilt: devel/hs-data-default-instances-base \r\nBuilt: devel/hs-data-default-instances-dlist \r\nBuilding: devel/hs-data-default\r\nBuilt: devel/hs-random \r\nInstalled: system-image__lang/ghc \r\nInstalling: system-image__archivers/hs-zlib\r\nInstalling: system-image__devel/hs-utf8-string\r\nInstalling: system-image__devel/hs-syb\r\nInstalling: system-image__devel/hs-base64-bytestring\r\nInstalling: system-image__devel/hs-data-default-class\r\nInstalling: system-image__devel/hs-dlist\r\nInstalling: system-image__devel/hs-random\r\nInstalling: system-image__devel/hs-temporary\r\nInstalling: system-image__devel/hs-extensible-exceptions\r\nBuilt: devel/hs-data-default FAILED\r\n\r\nThe error from the Haskell data-default build was:\r\n\r\nsetup: At least the following dependencies are missing:\r\ndata-default-instances-base -any\r\n\r\nLooking in the in the package.conf.d directory shows that the data-default-instances-base-0.0.1-7bdf8678f0d8637e096e397e7910f82a.conf file was present, but running \"ghc-pkg list\" did not show data-default-instances-base\r\n\r\nRunning /usr/local/lib/cabal/ghc-7.6.3/data-default-instances-base-0.0.1/register.sh (which was also present) caused ghc-pkg to now show data-default-instances-base.\r\n\r\nTo me this looks like a race condition between multiple instances of ghc-pkg causing the cache to become inconsistent.","type_of_failure":"OtherFailure","blocking":[]} -->pgjpgjhttps://gitlab.haskell.org/ghc/ghc/-/issues/8442Cabal-install internal error with any use2019-07-07T18:45:03ZsenkCabal-install internal error with any useAny attempt to use cabal-install fails with an internal error.
Used FreeBSD (9.1) port hs-haskell-platform and built with hs-colour support, LLVM (3.2) backend, and profiling enabled. Warnings were given that the version of LLVM used wa...Any attempt to use cabal-install fails with an internal error.
Used FreeBSD (9.1) port hs-haskell-platform and built with hs-colour support, LLVM (3.2) backend, and profiling enabled. Warnings were given that the version of LLVM used was untested, but no issues were apparent when compiling.
```
cabal install hakyll
cabal-install: internal error: evacuate(static): strange closure type -385875968
(GHC version 7.6.3 for x86_64_portbld_freebsd)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Abort trap
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Cabal-install internal error with any use","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Any attempt to use cabal-install fails with an internal error.\r\n\r\nUsed FreeBSD (9.1) port hs-haskell-platform and built with hs-colour support, LLVM (3.2) backend, and profiling enabled. Warnings were given that the version of LLVM used was untested, but no issues were apparent when compiling.\r\n\r\n{{{\r\ncabal install hakyll\r\ncabal-install: internal error: evacuate(static): strange closure type -385875968\r\n (GHC version 7.6.3 for x86_64_portbld_freebsd)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nAbort trap\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->pgjpgjhttps://gitlab.haskell.org/ghc/ghc/-/issues/7990ghc-pkg warning shows the wrong command2019-07-07T18:47:09Zmcandreghc-pkg warning shows the wrong commandWhen ghc-pkg observes your cache is out of date, it displays a helpful warning, recommending "ghc-pkg recache". However, sometimes running this command does not fix the problem, because it targets the wrong cache.
For out of date global...When ghc-pkg observes your cache is out of date, it displays a helpful warning, recommending "ghc-pkg recache". However, sometimes running this command does not fix the problem, because it targets the wrong cache.
For out of date global caches, "ghc-pkg --global recache" successfully clears the warning. For out of date user caches, "ghc-pkg --user recache" clears the warning.
In the future, could ghc-pkg display the command more specific to the problem?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc-pkg warning shows the wrong command","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When ghc-pkg observes your cache is out of date, it displays a helpful warning, recommending \"ghc-pkg recache\". However, sometimes running this command does not fix the problem, because it targets the wrong cache.\r\n\r\nFor out of date global caches, \"ghc-pkg --global recache\" successfully clears the warning. For out of date user caches, \"ghc-pkg --user recache\" clears the warning.\r\n\r\nIn the future, could ghc-pkg display the command more specific to the problem?","type_of_failure":"OtherFailure","blocking":[]} -->