GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2020-02-10T20:37:45Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/17807“ghc-cabal” cannot be opened because the developer cannot be verified.2020-02-10T20:37:45Zconradwt“ghc-cabal” cannot be opened because the developer cannot be verified.## Summary
I have downloaded the binary distribution of GHC 8.8.2 for macOS 10.15.3 and I'm getting a dialog:
```
“ghc-cabal” cannot be opened because the developer cannot be verified.
```
Thus, I'm not very clear how to proceed becau...## Summary
I have downloaded the binary distribution of GHC 8.8.2 for macOS 10.15.3 and I'm getting a dialog:
```
“ghc-cabal” cannot be opened because the developer cannot be verified.
```
Thus, I'm not very clear how to proceed because I have two choices here `Move to Trash` and `Cancel`.
## Steps to reproduce
cd ghc-8.8.2
./configure
make install
## Expected behavior
I expect that GHC would be properly installed with errors and dialog warning messages.
## Environment
* GHC version used: 8.8.2
Optional:
* Operating System: macOS 10.15.3
* System Architecture: Darwin 19.3.0 Darwin Kernel Version 19.3.0: Thu Jan 9 20:58:23 PST 2020; root:xnu-6153.81.5~1/RELEASE_X86_64 x86_64https://gitlab.haskell.org/ghc/ghc/-/issues/17848make sdist is broken, fails to generate source archive2020-02-23T15:23:45ZCsaba Hruskamake sdist is broken, fails to generate source archive## Summary
The command `make sdist-ghc` fails after a fresh git repo clone (GHC master).
After a successfull GHC build the source dist build fails:
```
make sdist-ghc
make --no-print-directory -f ghc.mk sdist-ghc NO_INCLUDE_DEPS=YES N...## Summary
The command `make sdist-ghc` fails after a fresh git repo clone (GHC master).
After a successfull GHC build the source dist build fails:
```
make sdist-ghc
make --no-print-directory -f ghc.mk sdist-ghc NO_INCLUDE_DEPS=YES NO_INCLUDE_PKGDATA=YES
ghc.mk:1221: warning: overriding recipe for target 'sdist_compiler_stage2_Cmm'
ghc.mk:1220: warning: ignoring old recipe for target 'sdist_compiler_stage2_Cmm'
make[1]: *** No rule to make target 'compiler/stage2/build/Cmm.hs', needed by 'sdist_compiler_stage2_Cmm'. Stop.
Makefile:162: recipe for target 'sdist-ghc' failed
make: *** [sdist-ghc] Error 2
```
## Steps to reproduce
1. clone GHC git repository: `git clone --recursive https://gitlab.haskell.org/ghc/ghc.git`
2. `./boot`
3. `./configure`
4. `make -j4` (optional, does not have effect on the problem)
5. `make sdist-ghc`
## Expected behavior
A working source tar.xz should be generated and it should compile.
Could the source-dist generator be tested via CI?
## Environment
* GHC version used: bootstrap GHC 8.6.2, GHC master git hash: 785008c1235bd77ddb4d13f57f92b249752d8ea5
Optional:
* Operating System: Ubuntu 16.04
* System Architecture: x64https://gitlab.haskell.org/ghc/ghc/-/issues/17849hadrian source-dist is broken, the generated source dist does not compile2020-02-29T17:02:43ZCsaba Hruskahadrian source-dist is broken, the generated source dist does not compile## Summary
The command `hadrian/build.sh source-dist` generates source archive that does not compile.
## Steps to reproduce
1. clone GHC git repository: `git clone --recursive https://gitlab.haskell.org/ghc/ghc.git`
2. `./boot`
3. `./...## Summary
The command `hadrian/build.sh source-dist` generates source archive that does not compile.
## Steps to reproduce
1. clone GHC git repository: `git clone --recursive https://gitlab.haskell.org/ghc/ghc.git`
2. `./boot`
3. `./configure`
4. `hadrian/build.sh source-dist`
5. extract and boot/configure/compile the genertated archive (i.e. ghc-8.11.0.20200215-src.tar.xz)
Compilation output of the source-dist with hadrian:
```
# 1. hadrian source-dist generated: ghc-8.11.0.20200215-src.tar.xz from ghc git head
# 2. extract and boot/configure/compile ghc-8.11.0.20200215-src.tar.xz with hadrian/build.sh -j
| Run Ghc CompileHs Stage0: libraries/Cabal/Cabal/Distribution/CabalSpecVersion.hs => _build/stage0/libraries/Cabal/Cabal/build/Distribution/CabalSpecVersion.o
| Run Ghc CompileHs Stage0: libraries/Cabal/Cabal/Distribution/Compat/DList.hs => _build/stage0/libraries/Cabal/Cabal/build/Distribution/Compat/DList.o
| Run Ghc CompileHs Stage0: libraries/Cabal/Cabal/Distribution/Lex.hs => _build/stage0/libraries/Cabal/Cabal/build/Distribution/Lex.o
| Run Ghc CompileHs Stage0: libraries/Cabal/Cabal/Distribution/Fields/Lexer.hs => _build/stage0/libraries/Cabal/Cabal/build/Distribution/Fields/Lexer.o
| Run Ghc CompileHs Stage0: libraries/Cabal/Cabal/Distribution/Pretty.hs => _build/stage0/libraries/Cabal/Cabal/build/Distribution/Pretty.o
<no location info>: error:
module ‘ghc-8.6.2:Lexer’ is defined in multiple files: compiler/GHC/Cmm/Lexer.hs
compiler/parser/Lexer.hs
Error when running Shake build system:
at action, called at src/Rules.hs:71:19 in main:Rules
at need, called at src/Rules.hs:93:5 in main:Rules
* Depends on: _build/stage0/lib/package.conf.d/ghc-8.11.0.20200215.conf
at need, called at src/Rules/Register.hs:116:5 in main:Rules.Register
* Depends on: _build/stage0/compiler/build/libHSghc-8.11.0.20200215.a
at need, called at src/Rules/Library.hs:146:5 in main:Rules.Library
* Depends on: _build/stage0/compiler/build/Hooks.o
at &%>, called at src/Rules/Compile.hs:62:9 in main:Rules.Compile
* Depends on: _build/stage0/compiler/build/Hooks.o _build/stage0/compiler/build/Hooks.hi
at apply1, called at src/Development/Shake/Internal/Rules/Oracle.hs:159:32 in shake-0.18.3-a2e904f154f09728357733d7a3e8955a2a87773d2d7eb963a6f88d9d883fdde3:Development.Shake.Internal.Rules.Oracle
* Depends on: OracleQ (KeyValues ("_build/stage0/compiler/.dependencies","_build/stage0/compiler/build/Hooks.o"))
at need, called at src/Hadrian/Oracles/TextFile.hs:96:9 in main:Hadrian.Oracles.TextFile
* Depends on: _build/stage0/compiler/.dependencies
at readFile', called at src/Rules/Dependencies.hs:34:19 in main:Rules.Dependencies
at need, called at src/Development/Shake/Internal/Derived.hs:118:15 in shake-0.18.3-a2e904f154f09728357733d7a3e8955a2a87773d2d7eb963a6f88d9d883fdde3:Development.Shake.Internal.Derived
* Depends on: _build/stage0/compiler/.dependencies.mk
* Raised the exception:
user error (Development.Shake.cmd, system command failed
Command line: /usr/local/bin/ghc -M -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-db _build/stage0/lib/package.conf.d' '-this-unit-id ghc-8.11.0.20200215' '-package-id array-0.5.3.0' '-
```
Compilation output of the source-dist with make:
```
# 1. hadrian source-dist generated: ghc-8.11.0.20200215-src.tar.xz from ghc git head
# 2. extract and boot/configure/compile ghc-8.11.0.20200215-src.tar.xz with make -j3
make -j3
+ test -f mk/config.mk.old
+ cp -p mk/config.mk mk/config.mk.old
touch -r mk/config.mk.old mk/config.mk
+ test -f mk/project.mk.old
+ cp -p mk/project.mk mk/project.mk.old
touch -r mk/project.mk.old mk/project.mk
+ test -f compiler/ghc.cabal.old
+ cp -p compiler/ghc.cabal compiler/ghc.cabal.old
touch -r compiler/ghc.cabal.old compiler/ghc.cabal
===--- building phase 0
make --no-print-directory -f ghc.mk phase=0 phase_0_builds
utils/genprimopcode/ghc.mk:19: utils/genprimopcode/dist/package-data.mk: No such file or directory
utils/deriveConstants/ghc.mk:19: utils/deriveConstants/dist/package-data.mk: No such file or directory
utils/genapply/ghc.mk:26: utils/genapply/dist/package-data.mk: No such file or directory
libraries/hpc/ghc.mk:3: libraries/hpc/dist-boot/package-data.mk: No such file or directory
libraries/binary/ghc.mk:3: libraries/binary/dist-boot/package-data.mk: No such file or directory
libraries/text/ghc.mk:3: libraries/text/dist-boot/package-data.mk: No such file or directory
libraries/transformers/ghc.mk:3: libraries/transformers/dist-boot/package-data.mk: No such file or directory
libraries/mtl/ghc.mk:3: libraries/mtl/dist-boot/package-data.mk: No such file or directory
libraries/parsec/ghc.mk:3: libraries/parsec/dist-boot/package-data.mk: No such file or directory
libraries/Cabal/Cabal/ghc.mk:3: libraries/Cabal/Cabal/dist-boot/package-data.mk: No such file or directory
libraries/ghc-boot-th/ghc.mk:3: libraries/ghc-boot-th/dist-boot/package-data.mk: No such file or directory
libraries/ghc-boot/ghc.mk:3: libraries/ghc-boot/dist-boot/package-data.mk: No such file or directory
libraries/template-haskell/ghc.mk:3: libraries/template-haskell/dist-boot/package-data.mk: No such file or directory
libraries/ghc-heap/ghc.mk:3: libraries/ghc-heap/dist-boot/package-data.mk: No such file or directory
libraries/terminfo/ghc.mk:3: libraries/terminfo/dist-boot/package-data.mk: No such file or directory
libraries/ghci/ghc.mk:3: libraries/ghci/dist-boot/package-data.mk: No such file or directory
ghc.mk:716: libraries/integer-gmp/gmp/ghc.mk: No such file or directory
compiler/ghc.mk:301: compiler/stage1/package-data.mk: No such file or directory
utils/hsc2hs/ghc.mk:21: utils/hsc2hs/dist/package-data.mk: No such file or directory
utils/ghc-pkg/ghc.mk:61: utils/ghc-pkg/dist/package-data.mk: No such file or directory
ghc/ghc.mk:117: ghc/stage1/package-data.mk: No such file or directory
ghc.mk:1221: warning: overriding recipe for target 'sdist_compiler_stage2_Cmm'
ghc.mk:1220: warning: ignoring old recipe for target 'sdist_compiler_stage2_Cmm'
mkdir -p inplace/bin
make[1]: *** No rule to make target 'libraries/integer-gmp/gmp/ghc.mk'. Stop.
make[1]: *** Waiting for unfinished jobs....
mkdir -p inplace/lib
"rm" -f inplace/bin/mkdirhier..
echo '#!/bin/sh' >> inplace/bin/mkdirhier
cat utils/mkdirhier/mkdirhier.sh >> inplace/bin/mkdirhier
chmod +x inplace/bin/mkdirhier
Makefile:123: recipe for target 'all' failed
make: *** [all] Error 2
```
## Expected behavior
The generated source distribution should compile with both hadrian and make.
Could the source-dist generator be tested via CI?
## Environment
* GHC version used: bootstrap GHC 8.6.2, GHC master git hash: 785008c1235bd77ddb4d13f57f92b249752d8ea5
Optional:
* Operating System: Ubuntu 16.04
* System Architecture: x64Make removalhttps://gitlab.haskell.org/ghc/ghc/-/issues/17874GHC-8.8.3 is announced but there is no release tag2020-02-25T04:02:09ZOleg GrenrusGHC-8.8.3 is announced but there is no release tagBen GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/17878Fully static GHC Linux builds for releases?2021-08-26T15:42:45ZJulian OspaldFully static GHC Linux builds for releases?Currently releases are per-distro. This causes unreliable guessing code in e.g. ghcup on which bindist tarball to pick for a given Linux distro. It causes known problems with libtinfo, libgmp etc, which are not particularly cross-distro ...Currently releases are per-distro. This causes unreliable guessing code in e.g. ghcup on which bindist tarball to pick for a given Linux distro. It causes known problems with libtinfo, libgmp etc, which are not particularly cross-distro compatible.
A fully static build would probably have to utilize:
* `integer-simple` (due to licensing issues)
* `musl`
* the rest should be piece of cake?
Concerns:
* `integer-simple` is slower, a lot
@bgamari @carter @hvrhttps://gitlab.haskell.org/ghc/ghc/-/issues/17956GHC 8.10.1 bundles an older version of text than 8.8.32020-10-06T15:00:32ZRyan ScottGHC 8.10.1 bundles an older version of text than 8.8.3```
$ /opt/ghc/8.8.3/bin/ghc-pkg list
/opt/ghc/8.8.3/lib/ghc-8.8.3/package.conf.d
...
text-1.2.4.0
...
$ ./ghc-8.10.1/bin/ghc-pkg list
/home/rgscott/Software/ghc-8.10.1/lib/ghc-8.10.1/package.conf.d
...
text-1.2.3.2
...```
$ /opt/ghc/8.8.3/bin/ghc-pkg list
/opt/ghc/8.8.3/lib/ghc-8.8.3/package.conf.d
...
text-1.2.4.0
...
$ ./ghc-8.10.1/bin/ghc-pkg list
/home/rgscott/Software/ghc-8.10.1/lib/ghc-8.10.1/package.conf.d
...
text-1.2.3.2
...
```
I doubt this was intended.8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/17980GHC 8.10.1 Source Distribution tarball missing Hadrian scripts2020-10-02T23:31:51ZBit ConnorGHC 8.10.1 Source Distribution tarball missing Hadrian scriptsI downloaded the file [ghc-8.10.1-src.tar.xz](https://downloads.haskell.org/~ghc/8.10.1/ghc-8.10.1-src.tar.xz) from <https://www.haskell.org/ghc/download_ghc_8_10_1.html>
I extracted it and want to build it with Hadrian, according to th...I downloaded the file [ghc-8.10.1-src.tar.xz](https://downloads.haskell.org/~ghc/8.10.1/ghc-8.10.1-src.tar.xz) from <https://www.haskell.org/ghc/download_ghc_8_10_1.html>
I extracted it and want to build it with Hadrian, according to these instructions: <https://gitlab.haskell.org/ghc/ghc/-/wikis/building/hadrian>
But it seems that it is completely missing the `hadrian` directory. I can see `hadrian` here in the GHC git, but it is not inside the source distribution tarballMake removalAlp MestanogullariAlp Mestanogullarihttps://gitlab.haskell.org/ghc/ghc/-/issues/17988GHC-8.8.3 shipped Cabal-3.0.1.0 release candiate, not Cabal-3.0.2.02022-02-24T15:11:21ZOleg GrenrusGHC-8.8.3 shipped Cabal-3.0.1.0 release candiate, not Cabal-3.0.2.0The https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2697 says that it was merged, but there is no sign of that commit in `ghc-8.8` branch.The https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2697 says that it was merged, but there is no sign of that commit in `ghc-8.8` branch.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/18039Deployment of ghc on alpine aarch642023-07-19T11:18:57ZodidevDeployment of ghc on alpine aarch64There was no support for ghc for alpine aarch64, I cross compiled it on x86_64 and I installed it for alpine aarch64, it is working as expected.
I want to deploy these changes for https://gitlab.alpinelinux.org/alpine/aports repository. ...There was no support for ghc for alpine aarch64, I cross compiled it on x86_64 and I installed it for alpine aarch64, it is working as expected.
I want to deploy these changes for https://gitlab.alpinelinux.org/alpine/aports repository.
Please tell the procedure for the deployment.
Thanks..https://gitlab.haskell.org/ghc/ghc/-/issues/18104More user-friendly Windows packaging2021-02-22T19:56:50ZBen GamariMore user-friendly Windows packagingThere was recently quite a bit of discussion surrounding GHC's Windows packaging on [haskell-cafe](https://mail.haskell.org/pipermail/haskell-cafe/2020-April/132129.html). The digested version of the discussion is:
* we are perpetually...There was recently quite a bit of discussion surrounding GHC's Windows packaging on [haskell-cafe](https://mail.haskell.org/pipermail/haskell-cafe/2020-April/132129.html). The digested version of the discussion is:
* we are perpetually short of contributors to test and maintain our Windows support
* Haskell Platform used to ship a [NSIS-based](https://sourceforge.net/projects/nsis/) [installer](https://github.com/haskell/haskell-platform/blob/master/windows-platform.sh)
* the old NSIS installer, while somewhat functional, was quite quirky, would break easily, and was difficult to maintain
* in recent years there has been a push to reduce the maintenance overhead (and size) of the Haskell Platform
* consequently, the [haskell.org download page](https://www.haskell.org/downloads/) points Windows users to the [Chocolatey](https://chocolatey.org/) package manager to install GHC (which installs a distribution [packaged by Tamar](https://github.com/Mistuke/CabalChoco))
* it turns out that the NSIS installer was more convenient for some users (particularly those lacking administrative privileges and those unfamiliar with PowerShell)
I spoke at length with Gershom, Tamar, and others about this. We generally agree that breathing life back into the NSIS installer is neither practical nor desirable. However, the current Chocolatey installer leaves much to be desired. Thankfully, the chocolatey packaging is all relatively straightforward PowerShell scripting. We could investigate providing a generic MSI installer which piggy-backs on Chocolatey:
1. install chocolatey to a temporary directory (see the [installation script](https://github.com/chocolatey/ChocolateyGUI/blob/develop/shell/InstallChocolatey.ps1))
1. query `choco` for available GHC versions
1. prompt the user for which GHC version to install
1. perform the installation (installing `ghc` and `haskell-dev`, to ensure that `cabal-install` is available and works)
1. remove the temporary chocolatey installation
This should leave us with a reasonably straightforward installation story that can work.
[WiX](https://www.firegiant.com/wix/tutorial/) is apparently the recommended method for building MSI installers.https://gitlab.haskell.org/ghc/ghc/-/issues/18146Mac os 10.15.4 install impossible 8.10.12020-05-09T16:29:31ZJean Marie FalisseMac os 10.15.4 install impossible 8.10.1## Summary
During the installation process (make install), messages like "Impossible d’ouvrir « ghc-pkg » car le développeur ne peut pas être vérifié." (impossible to open "ghc-pkg because the developer cannot be checked) are produced. ...## Summary
During the installation process (make install), messages like "Impossible d’ouvrir « ghc-pkg » car le développeur ne peut pas être vérifié." (impossible to open "ghc-pkg because the developer cannot be checked) are produced. Although, in "System preferences", the authorisations are given, installation finishes with "make[1]: *** [install_packages] Killed: 9
make: *** [install] Error 2".
## Steps to reproduce
make install
## Expected behavior
Just install ghc.
## Environment
* GHC version used: 8.10.1
Optional:
* Operating System: Mac OS 10.15.4
* System Architecture:8.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/18287Windows 32-bit distributions2023-01-18T18:59:45Zd86leaderWindows 32-bit distributionsIt seems that ever since GHC 8.6.4 there was no binary release for 32bit windows: https://www.haskell.org/ghc/download_ghc_8_6_4.html#binaries
I found a related issue: https://gitlab.haskell.org/ghc/ghc/issues/16516
It's closed with the...It seems that ever since GHC 8.6.4 there was no binary release for 32bit windows: https://www.haskell.org/ghc/download_ghc_8_6_4.html#binaries
I found a related issue: https://gitlab.haskell.org/ghc/ghc/issues/16516
It's closed with the promise of binaries coming, but I can't find them.
Is this a planned removal? I could not find any information about dropping the support, and I would like to have GHC with file path limit fixed.https://gitlab.haskell.org/ghc/ghc/-/issues/18556Chocolatey installer for GHC doesn't put mingw/bin into PATH2021-07-31T10:24:49ZJohn KyChocolatey installer for GHC doesn't put mingw/bin into PATH## Summary
The Chocolatey installer only puts $GHC/bin into the PATH. For example:
C:\ProgramData\chocolatey\lib\ghc.8.6.5\tools\ghc-8.6.5\bin
It does not put $GHC/mingw/bin into PATH. For example:
C:\ProgramData\chocolatey\lib\ghc...## Summary
The Chocolatey installer only puts $GHC/bin into the PATH. For example:
C:\ProgramData\chocolatey\lib\ghc.8.6.5\tools\ghc-8.6.5\bin
It does not put $GHC/mingw/bin into PATH. For example:
C:\ProgramData\chocolatey\lib\ghc.8.6.5\tools\ghc-8.6.5\mingw\bin
Maybe it should because some Haskell projects do not build out of the box without it. For example hw-dsv.
## Steps to reproduce
Install GHC via Chocolatey.
## Expected behavior
$GHC/mingw/bin should be in PATH and packages like hw-dsv should build out of the box.
## Environment
* GHC version used: ghc-8.6.5 but possibly affects all GHC versions
Optional:
* Operating System: Windows
* System Architecture: IntelTamar ChristinaTamar Christinahttps://gitlab.haskell.org/ghc/ghc/-/issues/18794GHC 9.0.1-alpha1 Source Distribution tarball missing Hadrian scripts2020-10-27T18:03:17ZbitGHC 9.0.1-alpha1 Source Distribution tarball missing Hadrian scriptsHello, I have downloaded this file: <https://downloads.haskell.org/ghc/9.0.1-alpha1/ghc-9.0.0.20200925-src.tar.xz>
It appears that that it is missing the `hadrian` directory so it is not possible to build it using hadrian.
This issue i...Hello, I have downloaded this file: <https://downloads.haskell.org/ghc/9.0.1-alpha1/ghc-9.0.0.20200925-src.tar.xz>
It appears that that it is missing the `hadrian` directory so it is not possible to build it using hadrian.
This issue is a re-raise of #17980. I was hoping that GHC 9.0 would be able to build using hadrian (to get relocatable builds) using the regular official source tarball (without having to mess with git).
Thank you9.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/18821get-win32-tarballs.sh always downloads from mirror2021-03-22T17:15:29ZBen Gamariget-win32-tarballs.sh always downloads from mirror@shayne-fletcher-da reported on `ghc-devs` that `get-win32-tarballs.sh` always downloads from `repo.msys2.org`, even if the `downloads.haskell.org` download finished successfully.
This doesn't apply to %8.10.1 and later due to the Win32...@shayne-fletcher-da reported on `ghc-devs` that `get-win32-tarballs.sh` always downloads from `repo.msys2.org`, even if the `downloads.haskell.org` download finished successfully.
This doesn't apply to %8.10.1 and later due to the Win32 tarballs revamp in 0725f4bbc7f59282ee5fe41619099957030d85ff.8.8.5Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/18826GHC on Windows has hardcoded libtool path.2022-04-25T15:52:26ZTamar ChristinaGHC on Windows has hardcoded libtool path.The GHC Windows bindists are shipping with a hardcoded `libtool` path.
```
,("libtool command","C:/msys64/usr/bin/libtool")
```
That's also not even the right libtool to use. The one that should be used is the `mingw-w64` one.
If lib...The GHC Windows bindists are shipping with a hardcoded `libtool` path.
```
,("libtool command","C:/msys64/usr/bin/libtool")
```
That's also not even the right libtool to use. The one that should be used is the `mingw-w64` one.
If libtool is now required as part of the compiler it should be included in the packaging.
This means `http://repo.msys2.org/mingw/x86_64/mingw-w64-x86_64-libtool-2.4.6-15-any.pkg.tar.xz` needs to be added to packages
and it needs to be patched for long paths.
The remaining settings for `clang`, `llc` and `opt` are bogus too, but happen to work out because the machine configuring the Windows builds
don't have `clang`, `llc` and `opt` installed.9.4.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/18908Bindist `configure` should check for availability of `libgmp`2022-02-23T16:15:23ZBen GamariBindist `configure` should check for availability of `libgmp`Currently `configure` does not check whether `CC` is able to link against `libgmp` if the bindist is configured to use the `gmp` integer backend.
Usually this isn't a problem since the `ghc-pkg` is a Haskell executable which runs during...Currently `configure` does not check whether `CC` is able to link against `libgmp` if the bindist is configured to use the `gmp` integer backend.
Usually this isn't a problem since the `ghc-pkg` is a Haskell executable which runs during installation (which links against `libgmp`). This generally means that `libgmp` would certainly fail if it's not available at all on the system. However, in some cases the toolchain we configure against is unable to link against system libraries (e.g. in the case that we are using Anaconda's C toolchain). This means that `configure` can succeed yet installs a compiler that is unavailable.
The bindist `configure` script really should try linking against `libgmp` to ensure that the toolchain is usable.9.4.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/18948Eliminate eventlog way?2022-06-28T15:26:35ZBen GamariEliminate eventlog way?I have recently started to question the value of having the eventlog as a configurable option. It's an incredibly useful tool with little to no cost and the observability that is enables is something that is increasingly expected by user...I have recently started to question the value of having the eventlog as a configurable option. It's an incredibly useful tool with little to no cost and the observability that is enables is something that is increasingly expected by users.
In general I wonder whether it wouldn't be best to :
* drop the `_l` RTS ways, and
* enable `TRACING` in the remaining ways
* deprecate the `-eventlog` compiler flag
This would bring a few benefits:
* users wouldn't need to opt-in to eventlogging
* binary distributions get a bit smaller
* we can drop a bit of build system complexity
The only cost is that all Haskell executables get larger by around 400kB:
```
-rw-r--r-- 1 ben users 6.2M Nov 12 09:55 _build/stage1/rts/build/libHSrts-1.0.a
-rw-r--r-- 1 ben users 6.6M Nov 12 09:55 _build/stage1/rts/build/libHSrts-1.0_l.a
-rwxr-xr-x 1 ben users 3.5M Nov 12 09:55 _build/stage1/rts/build/libHSrts-1.0-ghc9.1.0.20201111.so
-rwxr-xr-x 1 ben users 3.9M Nov 12 09:55 _build/stage1/rts/build/libHSrts-1.0_l-ghc9.1.0.20201111.so
```
In the age of terabytes of storage, this seems like a reasonable trade-off.
Thoughts?9.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/18967GHC 8.10.2 bindist for alpine claims to use integer-simple but it doesn't2021-06-29T07:17:17ZJavier SagredoGHC 8.10.2 bindist for alpine claims to use integer-simple but it doesn't## Summary
The bindist uses integer-gmp.
```
~ # wget https://downloads.haskell.org/~ghc/8.10.2/ghc-8.10.2-x86_64-alpine3.10-linux-integer-simple.tar.xz
Connecting to downloads.haskell.org (151.101.133.175:443)
saving to 'ghc-8.10.2-x8...## Summary
The bindist uses integer-gmp.
```
~ # wget https://downloads.haskell.org/~ghc/8.10.2/ghc-8.10.2-x86_64-alpine3.10-linux-integer-simple.tar.xz
Connecting to downloads.haskell.org (151.101.133.175:443)
saving to 'ghc-8.10.2-x86_64-alpine3.10-linux-integer-simple.tar.xz'
ghc-8.10.2-x86_64-al 100% |*************************************************************************************************************************************************************************************************************************************************************************| 136M 0:00:00 ETA
'ghc-8.10.2-x86_64-alpine3.10-linux-integer-simple.tar.xz' saved
~ # tar xf ghc-8.10.2-x86_64-alpine3.10-linux-integer-simple.tar.xz
~ # cat ghc-8.10.2-x86_64-unknown-linux/lib/settings | grep integer
,("integer library", "integer-gmp")
```
## Environment
```
~ # uname -a
Linux c4447ef747aa 5.8.0-28-generic #30-Ubuntu SMP Thu Nov 5 13:24:33 UTC 2020 x86_64 Linux
~ # cat /etc/alpine-release
3.12.1
```8.10.6https://gitlab.haskell.org/ghc/ghc/-/issues/19083Bump template-haskell version to 2.18.0.02022-12-05T23:27:46ZRyan ScottBump template-haskell version to 2.18.0.0[Type applications in patterns](!2464) made a breaking change to the `template-haskell` API, and as a result, we need to bump the `template-haskell` version to 2.18 to reflect this change. Also, the `libraries/template-haskell/changelog....[Type applications in patterns](!2464) made a breaking change to the `template-haskell` API, and as a result, we need to bump the `template-haskell` version to 2.18 to reflect this change. Also, the `libraries/template-haskell/changelog.md` entry for type applications in patterns was incorrectly mentioned in the section for `template-haskell-2.17.0.0`, which is slated to be released with GHC 9.0.1, not with 9.2.1, which is when type applications in patterns will debut.9.2.1