GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:21:59Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/13412Centralize the definition for GHC's libdir on Windows2019-07-07T18:21:59ZElieuxCentralize the definition for GHC's libdir on WindowsThe location of GHC libraries on Windows is currently something like `$bindir/../lib` (because the whole distribution can be put anywhere on the filesystem, there are no absolute paths), but this information is hard-coded in multiple pla...The location of GHC libraries on Windows is currently something like `$bindir/../lib` (because the whole distribution can be put anywhere on the filesystem, there are no absolute paths), but this information is hard-coded in multiple places instead of being defined in one place. To be clear, I mean only the relative path (`../lib`); the base still needs to be determined at runtime.
I assume that tools that can rely on `ghc --info` (or equivalent) already do that. If there are any that don't, they should be fixed regardless. The build system, ghc, ghc-cabal, ghc-pkg, hsc2hs, haddock... should all be able to get the relative path from `configure`'s output.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.2 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | Phyx- |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Centralize the definition for GHC's libdir on Windows","status":"New","operating_system":"","component":"None","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["Phyx-"],"type":"Task","description":"The location of GHC libraries on Windows is currently something like `$bindir/../lib` (because the whole distribution can be put anywhere on the filesystem, there are no absolute paths), but this information is hard-coded in multiple places instead of being defined in one place. To be clear, I mean only the relative path (`../lib`); the base still needs to be determined at runtime.\r\n\r\nI assume that tools that can rely on `ghc --info` (or equivalent) already do that. If there are any that don't, they should be fixed regardless. The build system, ghc, ghc-cabal, ghc-pkg, hsc2hs, haddock... should all be able to get the relative path from `configure`'s output.","type_of_failure":"OtherFailure","blocking":[]} -->https://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/19335Some Windows users do not like Chocolatey2021-02-16T18:50:44Zf-aSome Windows users do not like Chocolateytl;dr: some experienced Win users stay clear of Haskell because of Chocolatey.
Exposition
----------
Today I asked a friend of mine who runs Win10 to compile a small Haskell program for me. I asked out of curiosity how the install proc...tl;dr: some experienced Win users stay clear of Haskell because of Chocolatey.
Exposition
----------
Today I asked a friend of mine who runs Win10 to compile a small Haskell program for me. I asked out of curiosity how the install process went — that is, installing Haskell —, if it was annoying, etc. Answer:
> It was only not annoying because I took an image of my laptop first so I can cleanly remove it, because the problem is Chocolatey is installing a lot of stuff without making it clear what you will end up with.
I enquired more and:
> I think you would have to go and read the scripts to be sure what you would end up with. I would prefer to have installed msys2 myself and then got the haskell parts separately.
> My specific issue would be: what Chocolatey did did not seem too complicated. I would have done it myself if there were download links alongside the Chocolatey version.
> My issues with Chocolatey is that they random command-line switches behind a paywall/ransom. The specific example was trying to install the Visual Studio compiler in a container and wanted to use some different flags to keep the size/bandwidth usage down, I passed the options as documented and then it refuses and says this feature is pay only.
Comment
-------
- It is not the first time I have heard some venting about Chocolatey;
- this user does not «lack administrative privileges and those unfamiliar with PowerShell», so I feel this is not a duplicate of #18104;
- I understand there is little or no manpower behind Windows build;
- this creates a vicious circle where some experienced Windows users shy away from trying Haskell ⟶ smaller pool of contributors for Windows builds ⟶ suboptimal onboarding experience ⟶ …;
- I sadly have no idea how to break the circle, having used Linux exclusively for the last 15 years.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/19514Building an integer-simple GHC with Hadrian in Mac OS defaults to -fuse-ld=go...2021-04-07T16:37:15ZJavier SagredoBuilding an integer-simple GHC with Hadrian in Mac OS defaults to -fuse-ld=gold on hsc2hs which crashes## Summary
After building GHC 8.10.4 with hadrian with a installed GHC 8.8.4, trying to build a project that transitively depends on `basement` which makes use if hsc2hs results in a crash as it is using `-fuse-ld=gold`.
## Steps to re...## Summary
After building GHC 8.10.4 with hadrian with a installed GHC 8.8.4, trying to build a project that transitively depends on `basement` which makes use if hsc2hs results in a crash as it is using `-fuse-ld=gold`.
## Steps to reproduce
from a clean system, I did the following:
```
ghcup install ghc 8.8.4
ghcup set ghc 8.8.4
git clone -b ghc-8.10.4-release https://gitlab.haskell.org/ghc/ghc.git --recurse-submodules
cd ghc
./boot
./configure --disable-numa [--disable-ld-override] # tried with and without that
./hadrian/build.sh -j5 --integer-simple --docs=none
./hadrian/build.sh binary-dist --integer-simple --docs=none
ghcup rm 8.8.4
ghcup install ghc -u file://$(pwd)/_build/bindist/ghc-8.10.4-x86_64-apple-darwin.tar.xz 8.10.4 # just named it 8.10.4
ghcup set ghc 8.10.4
```
Then trying to build anything that depends on basement fails, but for the record, basement itself fails:
```
> ~ % git clone https://github.com/haskell-foundation/foundation
Cloning into 'foundation'...
remote: Enumerating objects: 12612, done.
remote: Total 12612 (delta 0), reused 0 (delta 0), pack-reused 12612
Receiving objects: 100% (12612/12612), 2.46 MiB | 13.33 MiB/s, done.
Resolving deltas: 100% (8724/8724), done.
> ~ % cd foundation
> foundation % vi stack.yaml # to update the lts to 17.5 // ghc-8.10.4
> foundation % stack build --system-ghc
basement > configure (lib)
basement > Configuring basement-0.0.11...
basement > build (lib)
basement > Preprocessing library for basement-0.0.11..
basement > linking .stack-work/dist/x86_64-osx/Cabal-3.2.1.0/build/Basement/Terminal/Size_hsc_make.o failed (exit code 1)
basement > rsp file was: ".stack-work/dist/x86_64-osx/Cabal-3.2.1.0/build/Basement/Terminal/hsc2hscall86830-2.rsp"
basement > command was: /usr/bin/cc .stack-work/dist/x86_64-osx/Cabal-3.2.1.0/build/Basement/Terminal/Size_hsc_make.o .stack-work/dist/x86_64-osx/Cabal-3.2.1.0/build/Basement/Terminal/Size_hsc_utils.o -o .stack-work/dist/x86_64-osx/Cabal-3.2.1.0/build/Basement/Terminal/Size_hsc_make -fuse-ld=gold -L/Users/administrator/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-osx-ghc-8.10.4/base-4.14.1.0 -liconv -L/Users/administrator/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-osx-ghc-8.10.4/integer-simple-0.1.2.0 -L/Users/administrator/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-osx-ghc-8.10.4/ghc-prim-0.6.1 -L/Users/administrator/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-osx-ghc-8.10.4/rts-1.0 -lm -ldl
basement > error: clang: error: invalid linker name in argument '-fuse-ld=gold'
basement >
Progress 1/2
-- While building package basement-0.0.11 (scroll up to its section to see the error) using:
/Users/administrator/.stack/setup-exe-cache/x86_64-osx/Cabal-simple_mPHDZzAJ_3.2.1.0_ghc-8.10.4 --builddir=.stack-work/dist/x86_64-osx/Cabal-3.2.1.0 build lib:basement --ghc-options " -fdiagnostics-color=always"
Process exited with code: ExitFailure 1
```
Building with cabal also fails:
```
> foundation % cd basement
> basement % cabal build
Resolving dependencies...
Build profile: -w ghc-8.10.4 -O1
In order, the following will be built (use -v for more details):
- basement-0.0.11 (lib) (first run)
Configuring library for basement-0.0.11..
Preprocessing library for basement-0.0.11..
linking /Users/administrator/foundation/basement/dist-newstyle/build/x86_64-osx/ghc-8.10.4/basement-0.0.11/build/Basement/Terminal/Size_hsc_make.o failed (exit code 1)
rsp file was: "/Users/administrator/foundation/basement/dist-newstyle/build/x86_64-osx/ghc-8.10.4/basement-0.0.11/build/Basement/Terminal/hsc2hscall86894-2.rsp"
command was: /usr/bin/cc /Users/administrator/foundation/basement/dist-newstyle/build/x86_64-osx/ghc-8.10.4/basement-0.0.11/build/Basement/Terminal/Size_hsc_make.o /Users/administrator/foundation/basement/dist-newstyle/build/x86_64-osx/ghc-8.10.4/basement-0.0.11/build/Basement/Terminal/Size_hsc_utils.o -o /Users/administrator/foundation/basement/dist-newstyle/build/x86_64-osx/ghc-8.10.4/basement-0.0.11/build/Basement/Terminal/Size_hsc_make -fuse-ld=gold -L/Users/administrator/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-osx-ghc-8.10.4/base-4.14.1.0 -liconv -L/Users/administrator/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-osx-ghc-8.10.4/integer-simple-0.1.2.0 -L/Users/administrator/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-osx-ghc-8.10.4/ghc-prim-0.6.1 -L/Users/administrator/.ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/../lib/x86_64-osx-ghc-8.10.4/rts-1.0 -lm -ldl
error: clang: error: invalid linker name in argument '-fuse-ld=gold'
```
In fact, calling hsc2hs directly just fails:
```
> basement % hsc2hs Basement/Terminal/Size.hsc -I cbits
linking Basement/Terminal/Size_hsc_make.o failed (exit code 1)
rsp file was: "Basement/Terminal/hsc2hscall86916-2.rsp"
command was: /usr/bin/cc Basement/Terminal/Size_hsc_make.o Basement/Terminal/Size_hsc_utils.o -o Basement/Terminal/Size_hsc_make -fuse-ld=gold
error: clang: error: invalid linker name in argument '-fuse-ld=gold'
```
But providing the `-fuse-ld=ld` flag succeeds:
```
> % hsc2hs Basement/Terminal/Size.hsc -I cbits -L-fuse-ld=ld
# no output
```
The only way I am able to compile my project or basement with cabal/stack is using cabal and `--hsc2hs-options=-L-fuse-ld=ld`.
## Expected behavior
I expected it to use ld by default. Even more when the settings file of the GHC specifies ld as ld command:
```
> ~ % cat .ghcup/ghc/8.10.4/lib/ghc-8.10.4/lib/settings | grep ld
,("ld command", "ld")
,("ld flags", "")
,("ld supports compact unwind", "YES")
,("ld supports build-id", "NO")
,("ld supports filelist", "YES")
,("ld is GNU ld", "NO")
,("Merge objects command", "ld")
```
## Environment
* GHC version used: 8.8.4 to build 8.10.4
```
% cabal --version
cabal-install version 3.2.0.0
compiled using version 3.2.0.0 of the Cabal library
% stack --version
Version 2.5.1, Git revision d6ab861544918185236cf826cb2028abb266d6d5 x86_64 hpack-0.33.0
```
Optional:
* Operating System: Mac OS
* System Architecture: x86_64https://gitlab.haskell.org/ghc/ghc/-/issues/19533Windows installer does not compile2021-04-09T05:08:48Zw41g87Windows installer does not compile## Summary
Running "make install" command yields following messages:
Makefile:4: mk/install.mk: No such file or directory
Makefile:5: mk/config.mk: No such file or directory
## Steps to reproduce
Download and unpack ghc-9.0.1-x86_64-u...## Summary
Running "make install" command yields following messages:
Makefile:4: mk/install.mk: No such file or directory
Makefile:5: mk/config.mk: No such file or directory
## Steps to reproduce
Download and unpack ghc-9.0.1-x86_64-unknown-mingw32.tar.xz
Run make install under the directory.
## Expected behavior
The program compiles with no error message
## Environment
Compiled under Windows using MinGW
* GHC version used:
9.0.1
Optional:
* Operating System: Windows 10
* System Architecture: x86_64https://gitlab.haskell.org/ghc/ghc/-/issues/19512Publish Homebrew bottle for Apple Silicon Architecture2021-06-11T06:45:18ZMichael D. HoylePublish Homebrew bottle for Apple Silicon Architecture## Motivation
There are some homebrew bottles that depend on the ghc bottle (e.g. shellcheck), but can't be installed with `brew` because there's no `ghc` bottle for Apple Silicon architecture. So compiling and publishing a Homebrew Bo...## Motivation
There are some homebrew bottles that depend on the ghc bottle (e.g. shellcheck), but can't be installed with `brew` because there's no `ghc` bottle for Apple Silicon architecture. So compiling and publishing a Homebrew Bottle for `ghc` on Apple Silicon would enable a lot of these projects to support the new architecture.
## Proposal
Publish an Apple Silicon architecture bottle for `ghc`. I was able to install ghc via `ghcup`, and then compile a downstream project from source with it, on an M1-powered laptop, so that makes me think it should be possible to do this, but I'm not very familiar with how `ghcup` works or what's involved in compiling and publishing a homebrew bottle.
## Additional Context
This is the output I get when I try to install `ghc` via homebrew, in case that's helpful:
```
> brew install ghc
Updating Homebrew...
==> Auto-updated Homebrew!
Updated 1 tap (homebrew/core).
==> New Formulae
tomcat@9
==> Updated Formulae
Updated 61 formulae.
Error: ghc: no bottle available!
You can try to install from source with:
brew install --build-from-source ghc
Please note building from source is unsupported. You will encounter build
failures with some formulae. If you experience any issues please create pull
requests instead of asking for help on Homebrew's GitHub, Twitter or any other
official channels.
```
and installing from source
```
> brew install --build-from-source ghc
<a bunch of downloading stuff redacted>
==> ./configure --prefix=/opt/homebrew/Cellar/ghc/8.10.4/libexec/integer-gmp --with-pic --disable-shared --build=arm_vortex_tempest-apple-darwin20
Last 15 lines from /Users/hoylemd/Library/Logs/Homebrew/ghc/01.configure:
2021-03-09 11:29:43 -0500
./configure
--prefix=/opt/homebrew/Cellar/ghc/8.10.4/libexec/integer-gmp
--with-pic
--disable-shared
--build=arm_vortex_tempest-apple-darwin20
checking build system type... Invalid configuration `arm_vortex_tempest-apple-darwin20': machine `arm_vortex_tempest-apple' not recognized
configure: error: /bin/sh ./config.sub arm_vortex_tempest-apple-darwin20 failed
Do not report this issue to Homebrew/brew or Homebrew/core!
```https://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/19164ghc 8.10.3 osx build doesn't have source links in the provided haddocks2021-09-29T09:50:14ZCarter Schonwaldghc 8.10.3 osx build doesn't have source links in the provided haddocksghc 8.10.3 osx build doesn't have source links in the provided haddocksghc 8.10.3 osx build doesn't have source links in the provided haddocks8.10.7Ben 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/19924Post ghc on Hackage?2022-02-24T15:31:27ZRichard Eisenbergrae@richarde.devPost ghc on Hackage?I want to make a video about writing a type-checker plugin, and I wanted to start by looking at the documentation for plugins. After some internal debate, I thought it was more useful to talk about writing a plugin for 9.0 than for 8.10....I want to make a video about writing a type-checker plugin, and I wanted to start by looking at the documentation for plugins. After some internal debate, I thought it was more useful to talk about writing a plugin for 9.0 than for 8.10. But I discover I can't find rendered documentation for the GHC 9.0 API.
If I look at https://hackage.haskell.org/package/ghc, the most recent `ghc` library upload is 8.10.2. Should there be more recent uploads? Or is there another place to look for rendered documentation for the GHC API.9.4.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/21190GHC-9.2.2 binary tarball (window, x86_64, lz) doesn't include profiling libra...2022-04-12T15:51:16ZBruno DamourGHC-9.2.2 binary tarball (window, x86_64, lz) doesn't include profiling librariesThanks for this new release !
AFAIK the tarball (lz) I downloaded doesn't include profiling versions for the core libraries, is it deliberate ?Thanks for this new release !
AFAIK the tarball (lz) I downloaded doesn't include profiling versions for the core libraries, is it deliberate ?ZubinZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/20287Non-hermetic build "Couldn't find #define HS_CONSTANTS"2022-04-17T06:59:20ZGreg SteuckNon-hermetic build "Couldn't find #define HS_CONSTANTS"## Summary
Building ghc-9.2.1-rc1 on OpenBSD fails with:
```
===--- building phase 0
gmake --no-print-directory -f ghc.mk phase=0 phase_0_builds
gmake[1]: Nothing to be done for 'phase_0_builds'.
===--- building phase 1
gmake --no-print...## Summary
Building ghc-9.2.1-rc1 on OpenBSD fails with:
```
===--- building phase 0
gmake --no-print-directory -f ghc.mk phase=0 phase_0_builds
gmake[1]: Nothing to be done for 'phase_0_builds'.
===--- building phase 1
gmake --no-print-directory -f ghc.mk phase=1 phase_1_builds
gmake[1]: Nothing to be done for 'phase_1_builds'.
===--- building final phase
gmake --no-print-directory -f ghc.mk phase=final install
... below reflowed for clarity
"inplace/bin/ghc-cabal" register libraries/ghc-prim dist-install \
"/usr/ports/pobj/ghc-9.2.0.20210821/fake-amd64/usr/local/lib/ghc/bin/ghc" \
"/usr/ports/pobj/ghc-9.2.0.20210821/fake-amd64/usr/local/lib/ghc/bin/ghc-pkg" \
"/usr/ports/pobj/ghc-9.2.0.20210821/fake-amd64/usr/local/lib/ghc" \
'/usr/ports/pobj/ghc-9.2.0.20210821/fake-amd64' \
'/usr/local' '/usr/local/lib/ghc' '/usr/local/share/doc/ghc/html/libraries' \
NO
ghc-cabal:
'/usr/ports/pobj/ghc-9.2.0.20210821/fake-amd64/usr/local/lib/ghc/bin/ghc'
exited with an error:
ghc: panic! (the 'impossible' happened)
(GHC version 9.2.0.20210821:
Couldn't find #define HS_CONSTANTS " in
/usr/local/lib/ghc/include/DerivedConstants.h
CallStack (from HasCallStack):
error, called at compiler/stage2/build/GHC/Platform/Constants.hs:143:20 in
ghc:GHC.Platform.Constants
```
Notice the reported file path: `/usr/local/lib/ghc` is the previous version of ghc installed on the system and isn't even supposed to be used by the build (because the bootstrap is provided separately). I would expect the intermediate (fake) installation directory to be used everywhere in the install process, but something isn't hermetic.
This used to work with 9.2.1-alpha1 package which I previously built from https://github.com/blackgnezdo/ports/commits/ghc-9.2 (almost, the `libHSrts_l` hack isn't automated on that branch). The timeline is aligned with the submission of 9c762f27 which makes it a likely culprit (FYI @hsyl20).
## Steps to reproduce
The ports tree snapshot is at https://github.com/blackgnezdo/ports/commits/ghc-9.2.1-rc1. Running `make package` in `lang/ghc` should be enough to reproduce.
## Expected behavior
A working build independent of the previously installed local system packages.
## Environment
* GHC version used: 8.10.3 is used as a bootstrap
Optional:
* Operating System: OpenBSD 7.0-beta
* System Architecture: amd64Sylvain HenrySylvain Henryhttps://gitlab.haskell.org/ghc/ghc/-/issues/21022Binaries for macOS on AArch64 are not sufficiently signed2022-05-19T19:28:39ZRichard Eisenbergrae@richarde.devBinaries for macOS on AArch64 are not sufficiently signedWhen I downloaded https://downloads.haskell.org/ghc/9.2.1/ghc-9.2.1-aarch64-apple-darwin.tar.xz, I had to manually enable my computer to execute each package that ships with GHC, once during the installation process and then again when l...When I downloaded https://downloads.haskell.org/ghc/9.2.1/ghc-9.2.1-aarch64-apple-darwin.tar.xz, I had to manually enable my computer to execute each package that ships with GHC, once during the installation process and then again when launching GHC for the first time. This is annoying, and it does not inspire confidence. I can understand that I've just downloaded strange software over the internet and that it requires me to assert that I know what I'm doing... but is it possible to do this just once instead of about 20 times? If not, then I think we should direct users (strongly) to get their GHCs via another mechanism.
Some context: I like to download GHC directly instead of using e.g. `ghcup`, so that I can move GHCs in and out of place with [stow](https://www.gnu.org/software/stow/). Maybe `ghcup` replicates that functionality, but I use `stow` for lots of things, and it's nice to centralize my installed-version control.https://gitlab.haskell.org/ghc/ghc/-/issues/21643What determines whether or not a function in `base` has unfolding?2022-06-01T07:59:54ZZiyang Liuunsafefixio@gmail.comWhat determines whether or not a function in `base` has unfolding?I was compiling a function `f` whose definition uses `Data.Monoid.getFirst`, and it turns out when I use `cabal build`, the unfolding of `getFirst` is available to the simplifier, and so in `f`'s unfolding, `getFirst` is inlined into a `...I was compiling a function `f` whose definition uses `Data.Monoid.getFirst`, and it turns out when I use `cabal build`, the unfolding of `getFirst` is available to the simplifier, and so in `f`'s unfolding, `getFirst` is inlined into a `Coercion`; whereas when I use `nix build`, the unfolding is not available. The GHC version and the set of optimisation flags are the same.
Since `base` ships with GHC I thought it should always behave exactly the same way with the same GHC version, but apparently it doesn't. What could possibly cause this to happen?https://gitlab.haskell.org/ghc/ghc/-/issues/21733profiling/packaging: Distribute profiled ghc executable2022-06-20T10:12:20ZMatthew Pickeringprofiling/packaging: Distribute profiled ghc executableWe already distribute all the profiling libraries for ghc so we might as well distribute a ghc binary linked against these profiling libraries. Then if a user has a bug report they can easily provide us with a profile themselves so inves...We already distribute all the profiling libraries for ghc so we might as well distribute a ghc binary linked against these profiling libraries. Then if a user has a bug report they can easily provide us with a profile themselves so investigating compiler performance issues is much easier.
We could even distribute a wrapper script which contains `Main.hs` and compiles it on the fly using profiling in order to not have to distribute a large statically linked executable to users.https://gitlab.haskell.org/ghc/ghc/-/issues/21876Fully-static Alpine/i386 build fails due to non-ABS relocations2022-07-17T05:05:51ZBen GamariFully-static Alpine/i386 build fails due to non-ABS relocationsCurrently attempting to build the `validate+fully_static` flavour on i386/Alpine 3.12 fails when building the `lint-notes` executable (although this is merely a sign that the compiler is broken):
```
ld.lld: error: Hpc.c:(.debug_info+0x5...Currently attempting to build the `validate+fully_static` flavour on i386/Alpine 3.12 fails when building the `lint-notes` executable (although this is merely a sign that the compiler is broken):
```
ld.lld: error: Hpc.c:(.debug_info+0x59005): has non-ABS relocation R_386_GOTOFF against symbol '.LC15'
ld.lld: error: Hash.c:(.debug_info+0x225EB): has non-ABS relocation R_386_GOTOFF against symbol 'XXH3_kSecret'
collect2: error: ld returned 1 exit status
ld.lld: error: Hpc.c:(.debug_info+0x59005): has non-ABS relocation R_386_GOTOFF against symbol '.LC15'
ld.lld: error: Hash.c:(.debug_info+0x225EB): has non-ABS relocation R_386_GOTOFF against symbol 'XXH3_kSecret'
collect2: error: ld returned 1 exit status
ghc-9.5.20220714: `gcc' failed in phase `Linker'. (Exit code: 1)
ghc-9.5.20220714: `gcc' failed in phase `Linker'. (Exit code: 1)
Development.Shake.cmd, system command failed
Command line: /home/ghc/ghc/_build/install/bin/ghc -package array -package base -package bytestring -package containers -package directory -package process -package text -o /home/ghc/ghc/_build/test/bin/lint-notes /home/ghc/ghc/linters/lint-notes/Main.hs -ilinters/lint-notes
Exit code: 1
Stderr:
ld.lld: error: Hpc.c:(.debug_info+0x59005): has non-ABS relocation R_386_GOTOFF against symbol '.LC15'
ld.lld: error: Hash.c:(.debug_info+0x225EB): has non-ABS relocation R_386_GOTOFF against symbol 'XXH3_kSecret'
collect2: error: ld returned 1 exit status
ghc-9.5.20220714: `gcc' failed in phase `Linker'. (Exit code: 1)
Build failed.
hadrian/build-cabal --flavour=validate+fully_static -j24 --broken-test= --bignum=gmp --test-verbose=3 test --summary-junit=./junit.xml --test-have-intree-files --test-compiler=/home/ghc/ghc/_build/install/bin/ghc runtest.opts+= failed
```
In particular, it appears that the C compiler produced some relocations that aren't compatible with static linking. This manifested here in `libHSrts` although I suspect all C compilation products are similarly affected.https://gitlab.haskell.org/ghc/ghc/-/issues/21895ghc should not depend on stm package2022-07-26T14:44:03ZDouglas Wilsondouglas@well-typed.comghc should not depend on stm packageCurrently we have `build-depends: stm` in ghc.cabal. However this is an unnecessary dependency. The `stm` library is just a shim over base, we would be better to depend on base directly.Currently we have `build-depends: stm` in ghc.cabal. However this is an unnecessary dependency. The `stm` library is just a shim over base, we would be better to depend on base directly.Douglas Wilsondouglas@well-typed.comDouglas Wilsondouglas@well-typed.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/21626source-dist: Hadrian requires to ./boot before building2022-08-02T08:25:47ZMatthew Pickeringsource-dist: Hadrian requires to ./boot before buildingThe hadrian source dist requires you to `./boot` before `configure`, which adds an additional dependency on `python` and `autoreconf`.
This probably isn't a serious problem but is now noted in a ticket.The hadrian source dist requires you to `./boot` before `configure`, which adds an additional dependency on `python` and `autoreconf`.
This probably isn't a serious problem but is now noted in a ticket.9.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/20395libffi.a is unnecessarily duplicated2022-08-09T18:59:34ZBen Gamarilibffi.a is unnecessarily duplicatedWhile looking into the build system logic for `libffi` I noticed that the static archive built in the non-`--with-system-libffi` case is duplicated nearly a dozen times. This seems to be because `Cffi` is added to the Cabal `extra-bundle...While looking into the build system logic for `libffi` I noticed that the static archive built in the non-`--with-system-libffi` case is duplicated nearly a dozen times. This seems to be because `Cffi` is added to the Cabal `extra-bundled-libraries` field, which for some reason adds it to `hs-libraries` in the package registration (as documented in the [Cabal user's guide](https://gitlab.haskell.org/haskell/cabal/-/blob/3b7655f2ad4cd1030f6869a6053a5ff8483eb7e9/doc/cabal-package.rst#L2131)). `hs-libraries` is a list of objects which are treated as linkables in the final link but, because they are Haskell objects, must carry a way suffix (as described in https://gitlab.haskell.org/ghc/ghc/-/blob/d99fc2508204c59cfc83d8a68718cf930ccc74b2/docs/users_guide/packages.rst#L1351).
This is very strange since `libffi` isn't a Haskell object. Is there a reason why this is necessary? It would be nice if we didn't need to package `libffi` a dozen identical times.Moritz AngermannMoritz Angermann