GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-02-27T13:56:51Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/12720Remove ghcii.sh2024-02-27T13:56:51ZTamar ChristinaRemove ghcii.shOn Windows we have an extra script `ghcii.sh` that is recommended when we run in a console that does not use `conhost`. e.g mintty from msys2 or the cygwin shell.
This is because the sigINT signal is being swallowed by these consoles.
...On Windows we have an extra script `ghcii.sh` that is recommended when we run in a console that does not use `conhost`. e.g mintty from msys2 or the cygwin shell.
This is because the sigINT signal is being swallowed by these consoles.
I believe we can work around this by listening to Window messages as well. These consoles do their own drawings, which means they load `gdi32.dll`.
Which means they have a message pump so should be receiving Window events. See https://msdn.microsoft.com/en-us/library/windows/desktop/ms686016(v=vs.85).aspx
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Remoce ghcii.sh","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"On Windows we have an extra script `ghcii.sh` that is recommended when we run in a console that does not use `conhost`. e.g mintty from msys2 or the cygwin shell.\r\n\r\nThis is because the sigINT signal is being swallowed by these consoles.\r\n\r\nI believe we can work around this by listening to Window messages as well. These consoles do their own drawings, which means they load `gdi32.dll`.\r\n\r\nWhich means they have a message pump so should be receiving Window events. See https://msdn.microsoft.com/en-us/library/windows/desktop/ms686016(v=vs.85).aspx","type_of_failure":"OtherFailure","blocking":[]} -->https://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/16901GHC needs to distribute .hie files for base libraries2023-06-27T15:12:24ZMatthew PickeringGHC needs to distribute .hie files for base libraries`.hie` files need to be distributed as part of the release process so that projects using `.hie` files work with
the base libraries.
For example, go-to definition should work for functions defined in the base libraries as well as userl...`.hie` files need to be distributed as part of the release process so that projects using `.hie` files work with
the base libraries.
For example, go-to definition should work for functions defined in the base libraries as well as userland.
The best way to do this might be to distribute a separate tarball which just contains the `.hie` files which can be downloaded and installed separately to the usual bindists. Another option is to include the `.hie` files in the bindists, just like how we do for other documentation.
I made a MR !1337 towards this direction in the expectation of some refinement.ZubinZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/17051GHC 8.6.5 is quite a bit larger on aarch64 than x862022-11-22T03:32:26ZGraham ChristensenGHC 8.6.5 is quite a bit larger on aarch64 than x86I'm not sure "bug" or "feature requests right, so not sure about either template.
The NixOS build farm has a maximum output size of 2GiB, and the aarch64 build of GHC has been pushing over that limit.
On x86-64 we see output sizes arou...I'm not sure "bug" or "feature requests right, so not sure about either template.
The NixOS build farm has a maximum output size of 2GiB, and the aarch64 build of GHC has been pushing over that limit.
On x86-64 we see output sizes around 1600 MiB. On Aarch64, when it passes, the output is 400-500MiB larger at 2040 MiB.
Unfortunately when it goes over the limit, we're not able to provide any precompiled haskell toolchain for our aarch64 users.
Here is a summary of the difference in file sizes by bytes:
<details><summary><strong><em>Click to expand</em></strong> Column #1 is (size on aarch64 - size on x86) in bytes </summary>
```
808080 ./lib/ghc-8.6.5/array-0.5.3.0/HSarray-0.5.3.0.o
1273470 ./lib/ghc-8.6.5/array-0.5.3.0/libHSarray-0.5.3.0.a
262504 ./lib/ghc-8.6.5/array-0.5.3.0/libHSarray-0.5.3.0-ghc8.6.5.so
1131398 ./lib/ghc-8.6.5/array-0.5.3.0/libHSarray-0.5.3.0_p.a
11321848 ./lib/ghc-8.6.5/base-4.12.0.0/HSbase-4.12.0.0.o
15788724 ./lib/ghc-8.6.5/base-4.12.0.0/libHSbase-4.12.0.0.a
3826600 ./lib/ghc-8.6.5/base-4.12.0.0/libHSbase-4.12.0.0-ghc8.6.5.so
11769012 ./lib/ghc-8.6.5/base-4.12.0.0/libHSbase-4.12.0.0_p.a
784128 ./lib/ghc-8.6.5/binary-0.8.6.0/HSbinary-0.8.6.0.o
1086308 ./lib/ghc-8.6.5/binary-0.8.6.0/libHSbinary-0.8.6.0.a
238440 ./lib/ghc-8.6.5/binary-0.8.6.0/libHSbinary-0.8.6.0-ghc8.6.5.so
828596 ./lib/ghc-8.6.5/binary-0.8.6.0/libHSbinary-0.8.6.0_p.a
1030168 ./lib/ghc-8.6.5/bin/ghc
18132544 ./lib/ghc-8.6.5/bin/ghc-iserv
1640 ./lib/ghc-8.6.5/bin/ghc-iserv-dyn
16180144 ./lib/ghc-8.6.5/bin/ghc-iserv-prof
199864 ./lib/ghc-8.6.5/bin/ghc-pkg
3034800 ./lib/ghc-8.6.5/bin/haddock
330416 ./lib/ghc-8.6.5/bin/hpc
330392 ./lib/ghc-8.6.5/bin/hsc2hs
9296 ./lib/ghc-8.6.5/bin/runghc
1092536 ./lib/ghc-8.6.5/bytestring-0.10.8.2/HSbytestring-0.10.8.2.o
1620280 ./lib/ghc-8.6.5/bytestring-0.10.8.2/libHSbytestring-0.10.8.2.a
370384 ./lib/ghc-8.6.5/bytestring-0.10.8.2/libHSbytestring-0.10.8.2-ghc8.6.5.so
1293880 ./lib/ghc-8.6.5/bytestring-0.10.8.2/libHSbytestring-0.10.8.2_p.a
29456952 ./lib/ghc-8.6.5/Cabal-2.4.0.1/HSCabal-2.4.0.1.o
43209942 ./lib/ghc-8.6.5/Cabal-2.4.0.1/libHSCabal-2.4.0.1.a
7772504 ./lib/ghc-8.6.5/Cabal-2.4.0.1/libHSCabal-2.4.0.1-ghc8.6.5.so
31671894 ./lib/ghc-8.6.5/Cabal-2.4.0.1/libHSCabal-2.4.0.1_p.a
4128896 ./lib/ghc-8.6.5/containers-0.6.0.1/HScontainers-0.6.0.1.o
6536772 ./lib/ghc-8.6.5/containers-0.6.0.1/libHScontainers-0.6.0.1.a
1073024 ./lib/ghc-8.6.5/containers-0.6.0.1/libHScontainers-0.6.0.1-ghc8.6.5.so
5128692 ./lib/ghc-8.6.5/containers-0.6.0.1/libHScontainers-0.6.0.1_p.a
102240 ./lib/ghc-8.6.5/deepseq-1.4.4.0/HSdeepseq-1.4.4.0.o
144690 ./lib/ghc-8.6.5/deepseq-1.4.4.0/libHSdeepseq-1.4.4.0.a
49160 ./lib/ghc-8.6.5/deepseq-1.4.4.0/libHSdeepseq-1.4.4.0-ghc8.6.5.so
120714 ./lib/ghc-8.6.5/deepseq-1.4.4.0/libHSdeepseq-1.4.4.0_p.a
436736 ./lib/ghc-8.6.5/directory-1.3.3.0/HSdirectory-1.3.3.0.o
606946 ./lib/ghc-8.6.5/directory-1.3.3.0/libHSdirectory-1.3.3.0.a
156736 ./lib/ghc-8.6.5/directory-1.3.3.0/libHSdirectory-1.3.3.0-ghc8.6.5.so
449378 ./lib/ghc-8.6.5/directory-1.3.3.0/libHSdirectory-1.3.3.0_p.a
230632 ./lib/ghc-8.6.5/filepath-1.4.2.1/HSfilepath-1.4.2.1.o
342050 ./lib/ghc-8.6.5/filepath-1.4.2.1/libHSfilepath-1.4.2.1.a
73824 ./lib/ghc-8.6.5/filepath-1.4.2.1/libHSfilepath-1.4.2.1-ghc8.6.5.so
286650 ./lib/ghc-8.6.5/filepath-1.4.2.1/libHSfilepath-1.4.2.1_p.a
84961630 ./lib/ghc-8.6.5/ghc-8.6.5/libHSghc-8.6.5.a
19685920 ./lib/ghc-8.6.5/ghc-8.6.5/libHSghc-8.6.5-ghc8.6.5.so
49841666 ./lib/ghc-8.6.5/ghc-8.6.5/libHSghc-8.6.5_p.a
489504 ./lib/ghc-8.6.5/ghc-boot-8.6.5/HSghc-boot-8.6.5.o
692496 ./lib/ghc-8.6.5/ghc-boot-8.6.5/libHSghc-boot-8.6.5.a
143816 ./lib/ghc-8.6.5/ghc-boot-8.6.5/libHSghc-boot-8.6.5-ghc8.6.5.so
449376 ./lib/ghc-8.6.5/ghc-boot-8.6.5/libHSghc-boot-8.6.5_p.a
139864 ./lib/ghc-8.6.5/ghc-boot-th-8.6.5/HSghc-boot-th-8.6.5.o
202648 ./lib/ghc-8.6.5/ghc-boot-th-8.6.5/libHSghc-boot-th-8.6.5.a
39216 ./lib/ghc-8.6.5/ghc-boot-th-8.6.5/libHSghc-boot-th-8.6.5-ghc8.6.5.so
161512 ./lib/ghc-8.6.5/ghc-boot-th-8.6.5/libHSghc-boot-th-8.6.5_p.a
36240 ./lib/ghc-8.6.5/ghc-compact-0.1.0.0/HSghc-compact-0.1.0.0.o
62388 ./lib/ghc-8.6.5/ghc-compact-0.1.0.0/libHSghc-compact-0.1.0.0.a
4048 ./lib/ghc-8.6.5/ghc-compact-0.1.0.0/libHSghc-compact-0.1.0.0-ghc8.6.5.so
51332 ./lib/ghc-8.6.5/ghc-compact-0.1.0.0/libHSghc-compact-0.1.0.0_p.a
287688 ./lib/ghc-8.6.5/ghc-heap-8.6.5/HSghc-heap-8.6.5.o
388632 ./lib/ghc-8.6.5/ghc-heap-8.6.5/libHSghc-heap-8.6.5.a
90352 ./lib/ghc-8.6.5/ghc-heap-8.6.5/libHSghc-heap-8.6.5-ghc8.6.5.so
248256 ./lib/ghc-8.6.5/ghc-heap-8.6.5/libHSghc-heap-8.6.5_p.a
2768944 ./lib/ghc-8.6.5/ghci-8.6.5/HSghci-8.6.5.o
3884458 ./lib/ghc-8.6.5/ghci-8.6.5/libHSghci-8.6.5.a
864216 ./lib/ghc-8.6.5/ghci-8.6.5/libHSghci-8.6.5-ghc8.6.5.so
2815098 ./lib/ghc-8.6.5/ghci-8.6.5/libHSghci-8.6.5_p.a
2060696 ./lib/ghc-8.6.5/ghc-prim-0.5.3/HSghc-prim-0.5.3.o
3041242 ./lib/ghc-8.6.5/ghc-prim-0.5.3/libHSghc-prim-0.5.3.a
831656 ./lib/ghc-8.6.5/ghc-prim-0.5.3/libHSghc-prim-0.5.3-ghc8.6.5.so
2719874 ./lib/ghc-8.6.5/ghc-prim-0.5.3/libHSghc-prim-0.5.3_p.a
1972592 ./lib/ghc-8.6.5/haskeline-0.7.4.3/HShaskeline-0.7.4.3.o
2771732 ./lib/ghc-8.6.5/haskeline-0.7.4.3/libHShaskeline-0.7.4.3.a
572536 ./lib/ghc-8.6.5/haskeline-0.7.4.3/libHShaskeline-0.7.4.3-ghc8.6.5.so
1778020 ./lib/ghc-8.6.5/haskeline-0.7.4.3/libHShaskeline-0.7.4.3_p.a
241464 ./lib/ghc-8.6.5/hpc-0.6.0.3/HShpc-0.6.0.3.o
344410 ./lib/ghc-8.6.5/hpc-0.6.0.3/libHShpc-0.6.0.3.a
86464 ./lib/ghc-8.6.5/hpc-0.6.0.3/libHShpc-0.6.0.3-ghc8.6.5.so
266522 ./lib/ghc-8.6.5/hpc-0.6.0.3/libHShpc-0.6.0.3_p.a
316024 ./lib/ghc-8.6.5/integer-gmp-1.0.2.0/HSinteger-gmp-1.0.2.0.o
511096 ./lib/ghc-8.6.5/integer-gmp-1.0.2.0/libHSinteger-gmp-1.0.2.0.a
110632 ./lib/ghc-8.6.5/integer-gmp-1.0.2.0/libHSinteger-gmp-1.0.2.0-ghc8.6.5.so
484296 ./lib/ghc-8.6.5/integer-gmp-1.0.2.0/libHSinteger-gmp-1.0.2.0_p.a
24192 ./lib/ghc-8.6.5/libiserv-8.6.3/HSlibiserv-8.6.3.o
38756 ./lib/ghc-8.6.5/libiserv-8.6.3/libHSlibiserv-8.6.3.a
34396 ./lib/ghc-8.6.5/libiserv-8.6.3/libHSlibiserv-8.6.3_p.a
247616 ./lib/ghc-8.6.5/mtl-2.2.2/HSmtl-2.2.2.o
304900 ./lib/ghc-8.6.5/mtl-2.2.2/libHSmtl-2.2.2.a
110696 ./lib/ghc-8.6.5/mtl-2.2.2/libHSmtl-2.2.2-ghc8.6.5.so
216148 ./lib/ghc-8.6.5/mtl-2.2.2/libHSmtl-2.2.2_p.a
912784 ./lib/ghc-8.6.5/parsec-3.1.13.0/HSparsec-3.1.13.0.o
1299202 ./lib/ghc-8.6.5/parsec-3.1.13.0/libHSparsec-3.1.13.0.a
295632 ./lib/ghc-8.6.5/parsec-3.1.13.0/libHSparsec-3.1.13.0-ghc8.6.5.so
882882 ./lib/ghc-8.6.5/parsec-3.1.13.0/libHSparsec-3.1.13.0_p.a
479640 ./lib/ghc-8.6.5/pretty-1.1.3.6/HSpretty-1.1.3.6.o
668336 ./lib/ghc-8.6.5/pretty-1.1.3.6/libHSpretty-1.1.3.6.a
173648 ./lib/ghc-8.6.5/pretty-1.1.3.6/libHSpretty-1.1.3.6-ghc8.6.5.so
513784 ./lib/ghc-8.6.5/pretty-1.1.3.6/libHSpretty-1.1.3.6_p.a
283216 ./lib/ghc-8.6.5/process-1.6.5.0/HSprocess-1.6.5.0.o
449196 ./lib/ghc-8.6.5/process-1.6.5.0/libHSprocess-1.6.5.0.a
65888 ./lib/ghc-8.6.5/process-1.6.5.0/libHSprocess-1.6.5.0-ghc8.6.5.so
371676 ./lib/ghc-8.6.5/process-1.6.5.0/libHSprocess-1.6.5.0_p.a
30172 ./lib/ghc-8.6.5/rts/libHSrts.a
120844 ./lib/ghc-8.6.5/rts/libHSrts_debug.a
77280 ./lib/ghc-8.6.5/rts/libHSrts_debug-ghc8.6.5.so
57488 ./lib/ghc-8.6.5/rts/libHSrts-ghc8.6.5.so
23932 ./lib/ghc-8.6.5/rts/libHSrts_l.a
42984 ./lib/ghc-8.6.5/rts/libHSrts_l-ghc8.6.5.so
30674 ./lib/ghc-8.6.5/rts/libHSrts_thr.a
139618 ./lib/ghc-8.6.5/rts/libHSrts_thr_debug.a
90400 ./lib/ghc-8.6.5/rts/libHSrts_thr_debug-ghc8.6.5.so
43232 ./lib/ghc-8.6.5/rts/libHSrts_thr-ghc8.6.5.so
25844 ./lib/ghc-8.6.5/rts/libHSrts_thr_l.a
45368 ./lib/ghc-8.6.5/rts/libHSrts_thr_l-ghc8.6.5.so
113048 ./lib/ghc-8.6.5/stm-2.5.0.0/HSstm-2.5.0.0.o
180264 ./lib/ghc-8.6.5/stm-2.5.0.0/libHSstm-2.5.0.0.a
36984 ./lib/ghc-8.6.5/stm-2.5.0.0/libHSstm-2.5.0.0-ghc8.6.5.so
161528 ./lib/ghc-8.6.5/stm-2.5.0.0/libHSstm-2.5.0.0_p.a
4177528 ./lib/ghc-8.6.5/template-haskell-2.14.0.0/HStemplate-haskell-2.14.0.0.o
5914574 ./lib/ghc-8.6.5/template-haskell-2.14.0.0/libHStemplate-haskell-2.14.0.0.a
1334408 ./lib/ghc-8.6.5/template-haskell-2.14.0.0/libHStemplate-haskell-2.14.0.0-ghc8.6.5.so
4455486 ./lib/ghc-8.6.5/template-haskell-2.14.0.0/libHStemplate-haskell-2.14.0.0_p.a
229912 ./lib/ghc-8.6.5/terminfo-0.4.1.2/HSterminfo-0.4.1.2.o
333404 ./lib/ghc-8.6.5/terminfo-0.4.1.2/libHSterminfo-0.4.1.2.a
86176 ./lib/ghc-8.6.5/terminfo-0.4.1.2/libHSterminfo-0.4.1.2-ghc8.6.5.so
264620 ./lib/ghc-8.6.5/terminfo-0.4.1.2/libHSterminfo-0.4.1.2_p.a
2705960 ./lib/ghc-8.6.5/text-1.2.3.1/HStext-1.2.3.1.o
4307484 ./lib/ghc-8.6.5/text-1.2.3.1/libHStext-1.2.3.1.a
625512 ./lib/ghc-8.6.5/text-1.2.3.1/libHStext-1.2.3.1-ghc8.6.5.so
3389124 ./lib/ghc-8.6.5/text-1.2.3.1/libHStext-1.2.3.1_p.a
1101176 ./lib/ghc-8.6.5/time-1.8.0.2/HStime-1.8.0.2.o
1598870 ./lib/ghc-8.6.5/time-1.8.0.2/libHStime-1.8.0.2.a
359504 ./lib/ghc-8.6.5/time-1.8.0.2/libHStime-1.8.0.2-ghc8.6.5.so
1224438 ./lib/ghc-8.6.5/time-1.8.0.2/libHStime-1.8.0.2_p.a
1655968 ./lib/ghc-8.6.5/transformers-0.5.6.2/HStransformers-0.5.6.2.o
2056668 ./lib/ghc-8.6.5/transformers-0.5.6.2/libHStransformers-0.5.6.2.a
615616 ./lib/ghc-8.6.5/transformers-0.5.6.2/libHStransformers-0.5.6.2-ghc8.6.5.so
1364948 ./lib/ghc-8.6.5/transformers-0.5.6.2/libHStransformers-0.5.6.2_p.a
804816 ./lib/ghc-8.6.5/unix-2.7.2.2/HSunix-2.7.2.2.o
1166896 ./lib/ghc-8.6.5/unix-2.7.2.2/libHSunix-2.7.2.2.a
337008 ./lib/ghc-8.6.5/unix-2.7.2.2/libHSunix-2.7.2.2-ghc8.6.5.so
944232 ./lib/ghc-8.6.5/unix-2.7.2.2/libHSunix-2.7.2.2_p.a
355520 ./lib/ghc-8.6.5/xhtml-3000.2.2.1/HSxhtml-3000.2.2.1.o
470372 ./lib/ghc-8.6.5/xhtml-3000.2.2.1/libHSxhtml-3000.2.2.1.a
160304 ./lib/ghc-8.6.5/xhtml-3000.2.2.1/libHSxhtml-3000.2.2.1-ghc8.6.5.so
356892 ./lib/ghc-8.6.5/xhtml-3000.2.2.1/libHSxhtml-3000.2.2.1_p.a
```
</details>
<details><summary><strong><em>Click to expand</em></strong> same list, sorted by diff:</summary>
````
84961630 ./lib/ghc-8.6.5/ghc-8.6.5/libHSghc-8.6.5.a
49841666 ./lib/ghc-8.6.5/ghc-8.6.5/libHSghc-8.6.5_p.a
43209942 ./lib/ghc-8.6.5/Cabal-2.4.0.1/libHSCabal-2.4.0.1.a
31671894 ./lib/ghc-8.6.5/Cabal-2.4.0.1/libHSCabal-2.4.0.1_p.a
29456952 ./lib/ghc-8.6.5/Cabal-2.4.0.1/HSCabal-2.4.0.1.o
19685920 ./lib/ghc-8.6.5/ghc-8.6.5/libHSghc-8.6.5-ghc8.6.5.so
18132544 ./lib/ghc-8.6.5/bin/ghc-iserv
16180144 ./lib/ghc-8.6.5/bin/ghc-iserv-prof
15788724 ./lib/ghc-8.6.5/base-4.12.0.0/libHSbase-4.12.0.0.a
11769012 ./lib/ghc-8.6.5/base-4.12.0.0/libHSbase-4.12.0.0_p.a
11321848 ./lib/ghc-8.6.5/base-4.12.0.0/HSbase-4.12.0.0.o
7772504 ./lib/ghc-8.6.5/Cabal-2.4.0.1/libHSCabal-2.4.0.1-ghc8.6.5.so
6536772 ./lib/ghc-8.6.5/containers-0.6.0.1/libHScontainers-0.6.0.1.a
5914574 ./lib/ghc-8.6.5/template-haskell-2.14.0.0/libHStemplate-haskell-2.14.0.0.a
5128692 ./lib/ghc-8.6.5/containers-0.6.0.1/libHScontainers-0.6.0.1_p.a
4455486 ./lib/ghc-8.6.5/template-haskell-2.14.0.0/libHStemplate-haskell-2.14.0.0_p.a
4307484 ./lib/ghc-8.6.5/text-1.2.3.1/libHStext-1.2.3.1.a
4177528 ./lib/ghc-8.6.5/template-haskell-2.14.0.0/HStemplate-haskell-2.14.0.0.o
4128896 ./lib/ghc-8.6.5/containers-0.6.0.1/HScontainers-0.6.0.1.o
3884458 ./lib/ghc-8.6.5/ghci-8.6.5/libHSghci-8.6.5.a
3826600 ./lib/ghc-8.6.5/base-4.12.0.0/libHSbase-4.12.0.0-ghc8.6.5.so
3389124 ./lib/ghc-8.6.5/text-1.2.3.1/libHStext-1.2.3.1_p.a
3041242 ./lib/ghc-8.6.5/ghc-prim-0.5.3/libHSghc-prim-0.5.3.a
3034800 ./lib/ghc-8.6.5/bin/haddock
2815098 ./lib/ghc-8.6.5/ghci-8.6.5/libHSghci-8.6.5_p.a
2771732 ./lib/ghc-8.6.5/haskeline-0.7.4.3/libHShaskeline-0.7.4.3.a
2768944 ./lib/ghc-8.6.5/ghci-8.6.5/HSghci-8.6.5.o
2719874 ./lib/ghc-8.6.5/ghc-prim-0.5.3/libHSghc-prim-0.5.3_p.a
2705960 ./lib/ghc-8.6.5/text-1.2.3.1/HStext-1.2.3.1.o
2060696 ./lib/ghc-8.6.5/ghc-prim-0.5.3/HSghc-prim-0.5.3.o
2056668 ./lib/ghc-8.6.5/transformers-0.5.6.2/libHStransformers-0.5.6.2.a
1972592 ./lib/ghc-8.6.5/haskeline-0.7.4.3/HShaskeline-0.7.4.3.o
1778020 ./lib/ghc-8.6.5/haskeline-0.7.4.3/libHShaskeline-0.7.4.3_p.a
1655968 ./lib/ghc-8.6.5/transformers-0.5.6.2/HStransformers-0.5.6.2.o
1620280 ./lib/ghc-8.6.5/bytestring-0.10.8.2/libHSbytestring-0.10.8.2.a
1598870 ./lib/ghc-8.6.5/time-1.8.0.2/libHStime-1.8.0.2.a
1364948 ./lib/ghc-8.6.5/transformers-0.5.6.2/libHStransformers-0.5.6.2_p.a
1334408 ./lib/ghc-8.6.5/template-haskell-2.14.0.0/libHStemplate-haskell-2.14.0.0-ghc8.6.5.so
1299202 ./lib/ghc-8.6.5/parsec-3.1.13.0/libHSparsec-3.1.13.0.a
1293880 ./lib/ghc-8.6.5/bytestring-0.10.8.2/libHSbytestring-0.10.8.2_p.a
1273470 ./lib/ghc-8.6.5/array-0.5.3.0/libHSarray-0.5.3.0.a
1224438 ./lib/ghc-8.6.5/time-1.8.0.2/libHStime-1.8.0.2_p.a
1166896 ./lib/ghc-8.6.5/unix-2.7.2.2/libHSunix-2.7.2.2.a
1131398 ./lib/ghc-8.6.5/array-0.5.3.0/libHSarray-0.5.3.0_p.a
1101176 ./lib/ghc-8.6.5/time-1.8.0.2/HStime-1.8.0.2.o
1092536 ./lib/ghc-8.6.5/bytestring-0.10.8.2/HSbytestring-0.10.8.2.o
1086308 ./lib/ghc-8.6.5/binary-0.8.6.0/libHSbinary-0.8.6.0.a
1073024 ./lib/ghc-8.6.5/containers-0.6.0.1/libHScontainers-0.6.0.1-ghc8.6.5.so
1030168 ./lib/ghc-8.6.5/bin/ghc
944232 ./lib/ghc-8.6.5/unix-2.7.2.2/libHSunix-2.7.2.2_p.a
912784 ./lib/ghc-8.6.5/parsec-3.1.13.0/HSparsec-3.1.13.0.o
882882 ./lib/ghc-8.6.5/parsec-3.1.13.0/libHSparsec-3.1.13.0_p.a
864216 ./lib/ghc-8.6.5/ghci-8.6.5/libHSghci-8.6.5-ghc8.6.5.so
831656 ./lib/ghc-8.6.5/ghc-prim-0.5.3/libHSghc-prim-0.5.3-ghc8.6.5.so
828596 ./lib/ghc-8.6.5/binary-0.8.6.0/libHSbinary-0.8.6.0_p.a
808080 ./lib/ghc-8.6.5/array-0.5.3.0/HSarray-0.5.3.0.o
804816 ./lib/ghc-8.6.5/unix-2.7.2.2/HSunix-2.7.2.2.o
784128 ./lib/ghc-8.6.5/binary-0.8.6.0/HSbinary-0.8.6.0.o
692496 ./lib/ghc-8.6.5/ghc-boot-8.6.5/libHSghc-boot-8.6.5.a
668336 ./lib/ghc-8.6.5/pretty-1.1.3.6/libHSpretty-1.1.3.6.a
625512 ./lib/ghc-8.6.5/text-1.2.3.1/libHStext-1.2.3.1-ghc8.6.5.so
615616 ./lib/ghc-8.6.5/transformers-0.5.6.2/libHStransformers-0.5.6.2-ghc8.6.5.so
606946 ./lib/ghc-8.6.5/directory-1.3.3.0/libHSdirectory-1.3.3.0.a
572536 ./lib/ghc-8.6.5/haskeline-0.7.4.3/libHShaskeline-0.7.4.3-ghc8.6.5.so
513784 ./lib/ghc-8.6.5/pretty-1.1.3.6/libHSpretty-1.1.3.6_p.a
511096 ./lib/ghc-8.6.5/integer-gmp-1.0.2.0/libHSinteger-gmp-1.0.2.0.a
489504 ./lib/ghc-8.6.5/ghc-boot-8.6.5/HSghc-boot-8.6.5.o
484296 ./lib/ghc-8.6.5/integer-gmp-1.0.2.0/libHSinteger-gmp-1.0.2.0_p.a
479640 ./lib/ghc-8.6.5/pretty-1.1.3.6/HSpretty-1.1.3.6.o
470372 ./lib/ghc-8.6.5/xhtml-3000.2.2.1/libHSxhtml-3000.2.2.1.a
449378 ./lib/ghc-8.6.5/directory-1.3.3.0/libHSdirectory-1.3.3.0_p.a
449376 ./lib/ghc-8.6.5/ghc-boot-8.6.5/libHSghc-boot-8.6.5_p.a
449196 ./lib/ghc-8.6.5/process-1.6.5.0/libHSprocess-1.6.5.0.a
436736 ./lib/ghc-8.6.5/directory-1.3.3.0/HSdirectory-1.3.3.0.o
388632 ./lib/ghc-8.6.5/ghc-heap-8.6.5/libHSghc-heap-8.6.5.a
371676 ./lib/ghc-8.6.5/process-1.6.5.0/libHSprocess-1.6.5.0_p.a
370384 ./lib/ghc-8.6.5/bytestring-0.10.8.2/libHSbytestring-0.10.8.2-ghc8.6.5.so
359504 ./lib/ghc-8.6.5/time-1.8.0.2/libHStime-1.8.0.2-ghc8.6.5.so
356892 ./lib/ghc-8.6.5/xhtml-3000.2.2.1/libHSxhtml-3000.2.2.1_p.a
355520 ./lib/ghc-8.6.5/xhtml-3000.2.2.1/HSxhtml-3000.2.2.1.o
344410 ./lib/ghc-8.6.5/hpc-0.6.0.3/libHShpc-0.6.0.3.a
342050 ./lib/ghc-8.6.5/filepath-1.4.2.1/libHSfilepath-1.4.2.1.a
337008 ./lib/ghc-8.6.5/unix-2.7.2.2/libHSunix-2.7.2.2-ghc8.6.5.so
333404 ./lib/ghc-8.6.5/terminfo-0.4.1.2/libHSterminfo-0.4.1.2.a
330416 ./lib/ghc-8.6.5/bin/hpc
330392 ./lib/ghc-8.6.5/bin/hsc2hs
316024 ./lib/ghc-8.6.5/integer-gmp-1.0.2.0/HSinteger-gmp-1.0.2.0.o
304900 ./lib/ghc-8.6.5/mtl-2.2.2/libHSmtl-2.2.2.a
295632 ./lib/ghc-8.6.5/parsec-3.1.13.0/libHSparsec-3.1.13.0-ghc8.6.5.so
287688 ./lib/ghc-8.6.5/ghc-heap-8.6.5/HSghc-heap-8.6.5.o
286650 ./lib/ghc-8.6.5/filepath-1.4.2.1/libHSfilepath-1.4.2.1_p.a
283216 ./lib/ghc-8.6.5/process-1.6.5.0/HSprocess-1.6.5.0.o
266522 ./lib/ghc-8.6.5/hpc-0.6.0.3/libHShpc-0.6.0.3_p.a
264620 ./lib/ghc-8.6.5/terminfo-0.4.1.2/libHSterminfo-0.4.1.2_p.a
262504 ./lib/ghc-8.6.5/array-0.5.3.0/libHSarray-0.5.3.0-ghc8.6.5.so
248256 ./lib/ghc-8.6.5/ghc-heap-8.6.5/libHSghc-heap-8.6.5_p.a
247616 ./lib/ghc-8.6.5/mtl-2.2.2/HSmtl-2.2.2.o
241464 ./lib/ghc-8.6.5/hpc-0.6.0.3/HShpc-0.6.0.3.o
238440 ./lib/ghc-8.6.5/binary-0.8.6.0/libHSbinary-0.8.6.0-ghc8.6.5.so
230632 ./lib/ghc-8.6.5/filepath-1.4.2.1/HSfilepath-1.4.2.1.o
229912 ./lib/ghc-8.6.5/terminfo-0.4.1.2/HSterminfo-0.4.1.2.o
216148 ./lib/ghc-8.6.5/mtl-2.2.2/libHSmtl-2.2.2_p.a
202648 ./lib/ghc-8.6.5/ghc-boot-th-8.6.5/libHSghc-boot-th-8.6.5.a
199864 ./lib/ghc-8.6.5/bin/ghc-pkg
180264 ./lib/ghc-8.6.5/stm-2.5.0.0/libHSstm-2.5.0.0.a
173648 ./lib/ghc-8.6.5/pretty-1.1.3.6/libHSpretty-1.1.3.6-ghc8.6.5.so
161528 ./lib/ghc-8.6.5/stm-2.5.0.0/libHSstm-2.5.0.0_p.a
161512 ./lib/ghc-8.6.5/ghc-boot-th-8.6.5/libHSghc-boot-th-8.6.5_p.a
160304 ./lib/ghc-8.6.5/xhtml-3000.2.2.1/libHSxhtml-3000.2.2.1-ghc8.6.5.so
156736 ./lib/ghc-8.6.5/directory-1.3.3.0/libHSdirectory-1.3.3.0-ghc8.6.5.so
144690 ./lib/ghc-8.6.5/deepseq-1.4.4.0/libHSdeepseq-1.4.4.0.a
143816 ./lib/ghc-8.6.5/ghc-boot-8.6.5/libHSghc-boot-8.6.5-ghc8.6.5.so
139864 ./lib/ghc-8.6.5/ghc-boot-th-8.6.5/HSghc-boot-th-8.6.5.o
139618 ./lib/ghc-8.6.5/rts/libHSrts_thr_debug.a
120844 ./lib/ghc-8.6.5/rts/libHSrts_debug.a
120714 ./lib/ghc-8.6.5/deepseq-1.4.4.0/libHSdeepseq-1.4.4.0_p.a
113048 ./lib/ghc-8.6.5/stm-2.5.0.0/HSstm-2.5.0.0.o
110696 ./lib/ghc-8.6.5/mtl-2.2.2/libHSmtl-2.2.2-ghc8.6.5.so
110632 ./lib/ghc-8.6.5/integer-gmp-1.0.2.0/libHSinteger-gmp-1.0.2.0-ghc8.6.5.so
102240 ./lib/ghc-8.6.5/deepseq-1.4.4.0/HSdeepseq-1.4.4.0.o
90400 ./lib/ghc-8.6.5/rts/libHSrts_thr_debug-ghc8.6.5.so
90352 ./lib/ghc-8.6.5/ghc-heap-8.6.5/libHSghc-heap-8.6.5-ghc8.6.5.so
86464 ./lib/ghc-8.6.5/hpc-0.6.0.3/libHShpc-0.6.0.3-ghc8.6.5.so
86176 ./lib/ghc-8.6.5/terminfo-0.4.1.2/libHSterminfo-0.4.1.2-ghc8.6.5.so
77280 ./lib/ghc-8.6.5/rts/libHSrts_debug-ghc8.6.5.so
73824 ./lib/ghc-8.6.5/filepath-1.4.2.1/libHSfilepath-1.4.2.1-ghc8.6.5.so
65888 ./lib/ghc-8.6.5/process-1.6.5.0/libHSprocess-1.6.5.0-ghc8.6.5.so
62388 ./lib/ghc-8.6.5/ghc-compact-0.1.0.0/libHSghc-compact-0.1.0.0.a
57488 ./lib/ghc-8.6.5/rts/libHSrts-ghc8.6.5.so
51332 ./lib/ghc-8.6.5/ghc-compact-0.1.0.0/libHSghc-compact-0.1.0.0_p.a
49160 ./lib/ghc-8.6.5/deepseq-1.4.4.0/libHSdeepseq-1.4.4.0-ghc8.6.5.so
45368 ./lib/ghc-8.6.5/rts/libHSrts_thr_l-ghc8.6.5.so
43232 ./lib/ghc-8.6.5/rts/libHSrts_thr-ghc8.6.5.so
42984 ./lib/ghc-8.6.5/rts/libHSrts_l-ghc8.6.5.so
39216 ./lib/ghc-8.6.5/ghc-boot-th-8.6.5/libHSghc-boot-th-8.6.5-ghc8.6.5.so
38756 ./lib/ghc-8.6.5/libiserv-8.6.3/libHSlibiserv-8.6.3.a
36984 ./lib/ghc-8.6.5/stm-2.5.0.0/libHSstm-2.5.0.0-ghc8.6.5.so
36240 ./lib/ghc-8.6.5/ghc-compact-0.1.0.0/HSghc-compact-0.1.0.0.o
34396 ./lib/ghc-8.6.5/libiserv-8.6.3/libHSlibiserv-8.6.3_p.a
30674 ./lib/ghc-8.6.5/rts/libHSrts_thr.a
30172 ./lib/ghc-8.6.5/rts/libHSrts.a
25844 ./lib/ghc-8.6.5/rts/libHSrts_thr_l.a
24192 ./lib/ghc-8.6.5/libiserv-8.6.3/HSlibiserv-8.6.3.o
23932 ./lib/ghc-8.6.5/rts/libHSrts_l.a
9296 ./lib/ghc-8.6.5/bin/runghc
4048 ./lib/ghc-8.6.5/ghc-compact-0.1.0.0/libHSghc-compact-0.1.0.0-ghc8.6.5.so
1640 ./lib/ghc-8.6.5/bin/ghc-iserv-dyn
```
</details>
I can provide access to a powerful aarch64 builder if anybody needs it for testing: https://github.com/nix-community/aarch64-build-boxhttps://gitlab.haskell.org/ghc/ghc/-/issues/17418MacOS notarization2024-02-27T13:56:51ZBen GamariMacOS notarizationIt seems that macOS Catalina may [require](https://appletoolbox.com/everything-you-need-to-know-about-app-notarization-in-macos-catalina/) that all "Apps" (which I believe covers GHC, although it is such a vague term that it is hard to t...It seems that macOS Catalina may [require](https://appletoolbox.com/everything-you-need-to-know-about-app-notarization-in-macos-catalina/) that all "Apps" (which I believe covers GHC, although it is such a vague term that it is hard to tell) must be ["notarized"](https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution). I suppose this is yet another hoop that we will have to jump through. Sigh...
# Temporary workaround
Users can explicitly mark the binary distribution as trusted after extraction by running `xattr -rc $path_to_bindist_directory`.
# References
* [NodeJS issue](https://github.com/nodejs/node/issues/29216)
* [golang issue](https://github.com/golang/go/issues/34986)
* [GraalVM issue](https://github.com/oracle/graal/issues/1724)
* [Mono issue](https://github.com/mono/mono/issues/15333)
* [a potential workaround](https://news.ycombinator.com/item?id=21180185) although apparently this requires that the user have `root`
* [macports thread](https://lists.macports.org/pipermail/macports-dev/2019-April/040593.html)
* [a useful StackOverflow question](https://apple.stackexchange.com/questions/356994/how-will-apples-notarization-impact-programs-written-in-python)
* [bit of prose from Apple](https://developer.apple.com/news/?id=09032019a) which states that all software released after Jan 2020 will need to use the [hardened runtime](https://developer.apple.com/documentation/security/hardened_runtime_entitlements)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/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/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/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/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/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/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/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/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/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/20322release hadrian on Hackage2023-08-15T11:48:04ZJens Petersenrelease hadrian on HackageAs Hadrian becomes more important, it would help distros if hadrian was packaged and uploaded to Hackage.
Packaging manual sdist's from git snapshots is not really much fun to maintain or track...
This might require moving hadrian into...As Hadrian becomes more important, it would help distros if hadrian was packaged and uploaded to Hackage.
Packaging manual sdist's from git snapshots is not really much fun to maintain or track...
This might require moving hadrian into its own git module, perhaps?Post-makehttps://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 Angermannhttps://gitlab.haskell.org/ghc/ghc/-/issues/20748Allow RTS to be reinstalled2023-09-26T04:01:52ZJohn EricsonAllow RTS to be reinstalledThis is the natural companion to #19896. The other libraries are hopefully most the way there already.
With #17191 pretty close, we can start thinking about the next steps:
- [ ] Don't bake decisions about libraries in rts.cabal. Eithe...This is the natural companion to #19896. The other libraries are hopefully most the way there already.
With #17191 pretty close, we can start thinking about the next steps:
- [ ] Don't bake decisions about libraries in rts.cabal. Either we extend Cabal so that flags can be determined by configure in the `rts.buildinfo`, or we rip out the flags (oh well) and rewrite all the logic (not just the detection) in the RTS configure script output the underlying `cc-options`, `ld-options`, etc. in `rts.buildinfo`.
- [ ] What can build the RTS? Does Cabal know how to build `cmm-sources`, or just install them? I think it wouldn't be too hard to hack up part of the make build system
- [ ] Split `settings` files: Some of the options in there are about how the RTS is built (e.g. is it unregisterized) it would be unsafe for a separately-configure RTS and `settings` file to disagree, so these settings should be installed as part of the RTS. @hsyl20 I am tempted to undo part of 085983e63bfe6af23f8b85fbfcca8db4872d2f60 at that point, because if we are already planning on configuring and shipping RTS the derived constants setting file is clearer than the the big define in the C header.https://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/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/21407Add support for splitting debug symbols2024-02-27T13:58:43ZZubinAdd support for splitting debug symbolsCurrently we offer builds with debug/DWARF information embedded in them. Ideally these wouldn't be separate builds but just packages containing debug symbols that would be compatible with the regular distributions.
We would need to figu...Currently we offer builds with debug/DWARF information embedded in them. Ideally these wouldn't be separate builds but just packages containing debug symbols that would be compatible with the regular distributions.
We would need to figure out how to support splitting out and emitting the debug information separately while compiling code.
In the future we could also use this to offer a [debuginfod](https://wiki.debian.org/Debuginfod) server for profiling and debugging GHC/boot libraries.https://gitlab.haskell.org/ghc/ghc/-/issues/21590Record ABI hash/info for official bindists2023-02-13T17:13:49ZJulian OspaldRecord ABI hash/info for official bindistsGiven that there has been issues with the updated bindists for 9.0.2 (because of missing profiling libs) wrt ABI, I suggest to add a separate file that has explicit information about ABI for every bindist.
The format (as in: what consti...Given that there has been issues with the updated bindists for 9.0.2 (because of missing profiling libs) wrt ABI, I suggest to add a separate file that has explicit information about ABI for every bindist.
The format (as in: what constitutes the ABI hash) probably could be debated, an example is in the [HLS wrapper script](https://github.com/haskell/haskell-language-server/blob/eeb1d2057d595ab8a478c0b19904987a990365f1/bindist/wrapper.in#L76).
Even if there is no re-upload of bindists, this would allow to quickly check compatibility with other bindists without unpacking.https://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/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/21732profiling: Build profiling libraries we distribute with -fprof-late2024-02-28T15:57:51ZMatthew Pickeringprofiling: Build profiling libraries we distribute with -fprof-lateThe profiling libraries we currently build are pretty useless for profiling because they don't contain any cost centres. We should add cost centres using -fprof-late and distribute those so profile outputs are more useful for anyone tryi...The profiling libraries we currently build are pretty useless for profiling because they don't contain any cost centres. We should add cost centres using -fprof-late and distribute those so profile outputs are more useful for anyone trying to profile.9.12.1Matthew PickeringMatthew Pickeringhttps://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/21738template-haskell-2.19.0.0 depends on filepath2023-05-30T05:51:53ZOleg Grenrustemplate-haskell-2.19.0.0 depends on filepathWhich makes `filepath` non-upgradable package (as virtually everything depends on `template-haskell`).
This is a regression. Given that `template-haskell` needs only `</>` (though hard to tell, as an unqualified open import is used), I'...Which makes `filepath` non-upgradable package (as virtually everything depends on `template-haskell`).
This is a regression. Given that `template-haskell` needs only `</>` (though hard to tell, as an unqualified open import is used), I'd suggest to vendor it in `template-haskell` until the story about reinstalling `template-haskell` is proven to work.Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/21821Drop `integer-gmp` package2023-02-12T11:42:31ZSylvain HenryDrop `integer-gmp` packageSince GHC 9.0 the `integer-gmp` package is provided for backward compatibility only (the real work is done in `ghc-bignum`).
We should drop it at some point. Perhaps for the 9.6 release?
If someone is interested in maintaining it, that...Since GHC 9.0 the `integer-gmp` package is provided for backward compatibility only (the real work is done in `ghc-bignum`).
We should drop it at some point. Perhaps for the 9.6 release?
If someone is interested in maintaining it, that could be done independently of GHC.https://gitlab.haskell.org/ghc/ghc/-/issues/21841GHC 9.0.3 release?2022-11-02T10:51:43ZBen GamariGHC 9.0.3 release?%9.0.2 unfortunately shipped with no profiling information. We made an effort to mitigate this by releasing a set of 9.0.2a binary distributions. However, this has caused a few problems for downstream users:
* https://github.com/commer...%9.0.2 unfortunately shipped with no profiling information. We made an effort to mitigate this by releasing a set of 9.0.2a binary distributions. However, this has caused a few problems for downstream users:
* https://github.com/commercialhaskell/stackage-content/pull/102
* https://github.com/haskell/haskell-language-server/issues/2857
In hindsight, I think it's clear that releasing the `9.0.2a` revision wasn't the right way to handle the initial packaging issue since we the two 9.0.2 versions may differ in ABI. I suspect there is sufficient demand to warrant a %9.0.3.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/21887Update ghci and hpc on Hackage2022-10-23T22:15:26ZKobayashiUpdate ghci and hpc on Hackage<!--
READ THIS FIRST: If the feature you are proposing changes the language that GHC accepts
or adds any warnings to `-Wall`, it should be written as a [GHC Proposal](https://github.com/ghc-proposals/ghc-proposals/).
Other features, appr...<!--
READ THIS FIRST: If the feature you are proposing changes the language that GHC accepts
or adds any warnings to `-Wall`, it should be written as a [GHC Proposal](https://github.com/ghc-proposals/ghc-proposals/).
Other features, appropriate for a GitLab feature request, include GHC API/plugin
innovations, new low-impact compiler flags, or other similar additions to GHC.
-->
## Motivation
`ghci` and `hpc` is outdated on Hackage, latest versions for them are:
- `ghci`: `8.10.2`
- `hpc`: `0.6.0.3`
The problem occurs if your project depends on (either directly or indirectly) `ghc`, which in turn depends on `ghci` and `hpc`. As `ghci` and `hpc` doesn't have their latest source code on Hackage, this means the packages used by `ghci` or `hpc` can not be upgraded. Take `filepath-1.4.100.0` as an example. Even though it supports GHC 9.2.3, it can not be used in a project that requires the library `ghc`. This makes migration to `OsPath` unnecessarily harder, and this applies for all future changes made to `filepath`, `directory`, `containers`, `bytestring`, etc.
## Proposal
Just make all core libraries up to date on Hackage.ZubinZubinhttps://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/21912template-haskell.cabal is rejected by Hackage2022-10-23T20:59:19ZBen Gamaritemplate-haskell.cabal is rejected by HackageCurrently `template-haskell-2.19.0.0` shipping with 9.4.1-rc1 cannot be uploaded to Hackage as the cabal file is rejected by Hackage's package check:
```
Uploading hackage_docs/template-haskell-2.19.0.0.tar.gz...
Error uploading hackage...Currently `template-haskell-2.19.0.0` shipping with 9.4.1-rc1 cannot be uploaded to Hackage as the cabal file is rejected by Hackage's package check:
```
Uploading hackage_docs/template-haskell-2.19.0.0.tar.gz...
Error uploading hackage_docs/template-haskell-2.19.0.0.tar.gz: http code 400
Error: Invalid package
Invalid unix file name in tar archive:
"template-haskell-2.19.0.0/../filepath/System/". For portability, hackage
requires that file names be valid on both Unix and Windows systems, and not
refer outside of the tarball.
```9.4.1Douglas Wilsondouglas@well-typed.comDouglas Wilsondouglas@well-typed.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/21970Cross-compiler binary distribution configure script requires --target flag2024-03-07T14:24:54ZBen GamariCross-compiler binary distribution configure script requires --target flagCurrently when one attempts to install a cross-compiler bindist, one must pass `--target=...` to the bindist `configure`. Ideally the `configure` script would already know the target platform.Currently when one attempts to install a cross-compiler bindist, one must pass `--target=...` to the bindist `configure`. Ideally the `configure` script would already know the target platform.9.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/22117'Included libraries' part of the GHC 9.4.1, GHC 9.4.2 User's Guide is not com...2022-08-30T13:47:51ZMike Pilgrem'Included libraries' part of the GHC 9.4.1, GHC 9.4.2 User's Guide is not complete## Summary
The GHC User's Guide for 9.4.1 omitted 'Included libraries' but that is included in the GHC User's Guide for 9.4.2. However, the list appears to be incomplete for GHC 9.4.1 (in part 2.2.9.1) and GHC 9.4.2 (in part 2.1.1.1).
...## Summary
The GHC User's Guide for 9.4.1 omitted 'Included libraries' but that is included in the GHC User's Guide for 9.4.2. However, the list appears to be incomplete for GHC 9.4.1 (in part 2.2.9.1) and GHC 9.4.2 (in part 2.1.1.1).
In particular, the following are not listed (but are listed by `ghc-pkg list` on Windows and at https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/libraries/version-history - which covers up to GHC 9.4.1):
* `ghc-bignum-1.3`
* `rts-1.0.2`
* `system-css-std-lib-1.0` (this is mentioned in GHC 9.4.1 User's Guide: https://downloads.haskell.org/ghc/9.4.1/docs/users_guide/9.4.1-notes.html#packaging)
## Proposed improvements or changes
Include a complete 'Included libraries' part to every released GHC User's Guide.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/22334darwin binary distributions missing users guide2023-08-21T07:37:55Zelaforgedarwin binary distributions missing users guide## Summary
Darwin distros such as https://downloads.haskell.org/~ghc/9.4.2/ghc-9.4.2-x86_64-apple-darwin.tar.xz seem to be missing `doc/html/users_guide`. They do include an `index.html` with a broken link, which implies they meant to ...## Summary
Darwin distros such as https://downloads.haskell.org/~ghc/9.4.2/ghc-9.4.2-x86_64-apple-darwin.tar.xz seem to be missing `doc/html/users_guide`. They do include an `index.html` with a broken link, which implies they meant to have the guide. Also Linux ones seem to have it, at least https://downloads.haskell.org/~ghc/9.4.2/ghc-9.4.2-x86_64-deb11-linux.tar.xz does:
```
% s ghc-9.4.2-x86_64-apple-darwin/doc
archives/ html/
% s ghc-9.4.2-x86_64-unknown-linux/doc
Haddock.pdf archives/ html/ users_guide/ users_guide.pdf
```
This seems to go back several versions, I haven't downloaded them all but at least 9.2.2 and 9.2.4 are missing users guide.
## Proposed improvements or changes
Would like users_guide please :) Haddock would be nice too!Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/22691bindist configure doesn't fail if `find` is missing (9.4.4)2023-04-11T05:25:01ZJulian Ospaldbindist configure doesn't fail if `find` is missing (9.4.4)## Summary
Bindist configure doesn't require `find`, then `make install` fails with an obscure error, because some make variable is undefined and the resulting command is `.`:
```
sh-4.4# ./configure --prefix=/usr/local
checking build ...## Summary
Bindist configure doesn't require `find`, then `make install` fails with an obscure error, because some make variable is undefined and the resulting command is `.`:
```
sh-4.4# ./configure --prefix=/usr/local
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... x86_64-pc-linux-gnu
build platform inferred as: x86_64-unknown-linux
host platform inferred as: x86_64-unknown-linux
target platform inferred as: x86_64-unknown-linux
configure: GHC build : x86_64-unknown-linux
configure: GHC host : x86_64-unknown-linux
configure: GHC target : x86_64-unknown-linux
checking for path to top of build tree... /root/.ghcup/cache/ghc-9.4.4-x86_64-unknown-linux
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking for gsed... sed
checking for python3... /usr/bin/python3
checking for gfind... no
checking for find... no
configure: WARNING: find looks like a non-*nix find, ignoring it
checking for find... no
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking how to run the C preprocessor... gcc -E
checking for gcc option to accept ISO C99... none needed
checking for gcc option to accept ISO C99... none needed
checking for gcc option to accept ISO C99... none needed
checking for -ld.lld... no
checking for ld.lld... no
checking for -ld.gold... no
checking for ld.gold... ld.gold
checking whether C compiler supports -fuse-ld=gold... yes
checking for ld.gold object merging bug (binutils 22266)... ./configure: line 6264: 1578 Aborted (core dumped) ./conftest
affected
configure: ld.gold is broken due to binutils 22266, looking for another linker...
checking for -ld... no
checking for ld... ld
checking for ld.gold object merging bug (binutils 22266)... checking whether ld is GNU ld... YES
checking whether ld understands --build-id... yes
checking whether ld understands -no_compact_unwind... yes
checking whether ld understands -filelist... no
checking for -strip... no
checking for strip... strip
checking for gawk... gawk
checking for llc-14... no
checking for llc-14.0... no
checking for llc14... no
checking for llc-13... no
checking for llc-13.0... no
checking for llc13... no
checking for llc-12... no
checking for llc-12.0... no
checking for llc12... no
checking for llc-11... no
checking for llc-11.0... no
checking for llc11... no
checking for llc-10... no
checking for llc-10.0... no
checking for llc10... no
checking for llc... no
checking for opt-14... no
checking for opt-14.0... no
checking for opt14... no
checking for opt-13... no
checking for opt-13.0... no
checking for opt13... no
checking for opt-12... no
checking for opt-12.0... no
checking for opt12... no
checking for opt-11... no
checking for opt-11.0... no
checking for opt11... no
checking for opt-10... no
checking for opt-10.0... no
checking for opt10... no
checking for opt... no
checking version of gcc... checking version of gcc... 7.3.1
7.3.1
checking whether CC supports -no-pie... yes
checking for extra options to pass gcc when compiling via C...
checking Setting up CFLAGS, LDFLAGS, IGNORE_LINKER_LD_FLAGS and CPPFLAGS... done
checking Setting up CONF_CC_OPTS_STAGE0, CONF_GCC_LINKER_OPTS_STAGE0, CONF_LD_LINKER_OPTS_STAGE0 and CONF_CPP_OPTS_STAGE0... done
checking Setting up CONF_CC_OPTS_STAGE1, CONF_GCC_LINKER_OPTS_STAGE1, CONF_LD_LINKER_OPTS_STAGE1 and CONF_CPP_OPTS_STAGE1... done
checking Setting up CONF_CC_OPTS_STAGE2, CONF_GCC_LINKER_OPTS_STAGE2, CONF_LD_LINKER_OPTS_STAGE2 and CONF_CPP_OPTS_STAGE2... done
checking C++ standard library flavour... libstdc++
checking for linkage against 'stdc++'... success
checking for .subsections_via_symbols... no
checking whether your assembler supports .ident directive... yes
checking for GNU non-executable stack support... yes
checking whether gcc supports --target... no
checking whether gcc supports --target... no
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking size of void *... 8
checking whether byte ordering is bigendian... no
checking for -ar... no
checking for ar... ar
checking whether ar is GNU ar... yes
checking for ar arguments... q
checking whether ar supports @file... yes
checking whether ar supports -L... ar: conftest.a: No such file or directory
no
checking for ranlib... ranlib
configure: creating ./config.status
config.status: creating mk/system-cxx-std-lib-1.0.conf
config.status: creating mk/config.mk
config.status: creating mk/install.mk
****************************************************
Configuration done, ready to 'make install'
(see README and INSTALL files for more info.)
****************************************************
sh-4.4# make install
Copying binaries to /usr/local/lib/ghc-9.4.4/bin
/usr/bin/install -c -m 755 -d "/usr/local/lib/ghc-9.4.4/bin"
for i in ./bin/runghc-9.4.4 ./bin/ghc-iserv ./bin/runhaskell-9.4.4 ./bin/runhaskell ./bin/runghc ./bin/ghc-pkg-9.4.4 ./bin/ghc-iserv-prof-ghc-9.4.4 ./bin/hsc2hs-ghc-9.4.4 ./bin/ghc-pkg ./bin/hp2ps ./bin/haddock-ghc-9.4.4 ./bin/hpc ./bin/unlit-ghc-9.4.4 ./bin/ghc-iserv-dyn ./bin/ghc-9.4.4 ./bin/ghc-iserv-ghc-9.4.4 ./bin/ghc ./bin/hpc-ghc-9.4.4 ./bin/hsc2hs ./bin/ghc-iserv-prof ./bin/hp2ps-ghc-9.4.4 ./bin/unlit ./bin/haddock ./bin/ghc-iserv-dyn-ghc-9.4.4; do \
if test -L "$i"; then \
cp -RP "$i" "/usr/local/lib/ghc-9.4.4/bin"; \
else \
/usr/bin/install -c -m 755 "$i" "/usr/local/lib/ghc-9.4.4/bin"; \
fi; \
done
# Work around #17418 on Darwin
if [ -e "" ]; then "" -c -r "/usr/local/lib/ghc-9.4.4/bin"; fi
Installing wrapper scripts
/usr/bin/install -c -m 755 -d "/usr/local/bin"
for p in `cd wrappers; . ! -type d`; do \
mk/install_script.sh "$p" "//usr/local/bin/$p" "/usr/local/bin" "/usr/local/lib/ghc-9.4.4/bin" "/usr/local/lib/ghc-9.4.4/bin/$p" "/usr/local/lib/ghc-9.4.4/lib" "/usr/local/share/doc/ghc-9.4.4" "/usr/local/include"; \
done
/bin/sh: line 0: .: !: file not found
Copying libraries to /usr/local/lib/ghc-9.4.4/lib
/usr/bin/install -c -m 755 -d "/usr/local/lib/ghc-9.4.4/lib"
/bin/sh: line 2: .: -t: invalid option
.: usage: . filename [arguments]
chmod: cannot access '/usr/local/lib/ghc-9.4.4/lib/bin/*': No such file or directory
make: *** [Makefile:161: install_lib] Error 1
sh-4.4# find --help
sh: find: command not found
```
## Steps to reproduce
1. start docker container with fedora:27
2. install `curl bash git which gcc gcc-c++ gmp gmp-devel make ncurses ncurses-compat-libs xz perl`
3. download and unpack https://downloads.haskell.org/ghc/9.4.4/ghc-9.4.4-x86_64-centos7-linux.tar.xz
4. run `./configure && make install`
## Environment
* GHC version used: 9.4.4
Optional:
* Operating System: Fedora
* System Architecture: x86_64ZubinZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/22697Duplicate binaries in Apple Darwin bindist2023-09-25T21:06:15ZBryan Rbryan@haskell.foundationDuplicate binaries in Apple Darwin bindistI mention "Apple Darwin" in the title because that's the one I happen to be looking at. I have not looked at the others.
Symptom: 4 files show up twice in the tarball. They are identical as evidenced by their sha sums:
```
bryan@omena ...I mention "Apple Darwin" in the title because that's the one I happen to be looking at. I have not looked at the others.
Symptom: 4 files show up twice in the tarball. They are identical as evidenced by their sha sums:
```
bryan@omena ghc-9.4.3-aarch64-apple-darwin % shasum -a 256 bin/{ghc-iserv*,unlit}-ghc-9.4.3 | sort
1f65443aa85d341f0c5e6fd20b3125b932ad478a37f60878bf5d5a2fa741d5b6 bin/ghc-iserv-prof-ghc-9.4.3
59de9e6176a122089c8285f9f265230465dbc13f9767f36ff619eb5ddc918ef5 bin/ghc-iserv-ghc-9.4.3
afd9f444da7cd6d1741f7d726720ed370936ad58d7ccd0b0f7f014b02620d5c5 bin/unlit-ghc-9.4.3
b7eb46e29a8d7bc49121ba5040b7f70a971e1287566350b17f628e25ec094920 bin/ghc-iserv-dyn-ghc-9.4.3
bryan@omena ghc-9.4.3-aarch64-apple-darwin % shasum -a 256 lib/bin/* | sort
1f65443aa85d341f0c5e6fd20b3125b932ad478a37f60878bf5d5a2fa741d5b6 lib/bin/ghc-iserv-prof
59de9e6176a122089c8285f9f265230465dbc13f9767f36ff619eb5ddc918ef5 lib/bin/ghc-iserv
afd9f444da7cd6d1741f7d726720ed370936ad58d7ccd0b0f7f014b02620d5c5 lib/bin/unlit
b7eb46e29a8d7bc49121ba5040b7f70a971e1287566350b17f628e25ec094920 lib/bin/ghc-iserv-dyn
```
Note that every file in lib/bin is a duplicate. I wonder if they should be symlinks? Is this a variation of #22062?
These are big binaries representing, in sum, 4% (80/1930 MB) of the entire unpacked tarball.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/22723Bindist testsuite is missing files2024-03-16T08:04:15ZJulian OspaldBindist testsuite is missing files1. `wget https://downloads.haskell.org/ghc/9.4.4/ghc-9.4.4-testsuite.tar.xz`
2. `tar xf ghc-9.4.4-testsuite.tar.xz`
3. `cd ghc-9.4.4/testsuite`
4. `ghcup run --ghc 9.4.4 -- make TEST=Rename1 WAY=optasm SKIP_PERF_TESTS=YES`
Result:
```
...1. `wget https://downloads.haskell.org/ghc/9.4.4/ghc-9.4.4-testsuite.tar.xz`
2. `tar xf ghc-9.4.4-testsuite.tar.xz`
3. `cd ghc-9.4.4/testsuite`
4. `ghcup run --ghc 9.4.4 -- make TEST=Rename1 WAY=optasm SKIP_PERF_TESTS=YES`
Result:
```
make -C ./tests all
make[1]: Entering directory '/home/hasufell/tmp/ttt/ghc-9.4.4/testsuite/tests'
PYTHON="python3" "python3" ../driver/runtests.py -e "ghc_compiler_always_flags='-dcore-lint -dstg-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output'" -e "config.compiler_debugged=False" -e ghc_with_native_codegen=True -e "config.leading_underscore=False" -e ghc_with_threaded_rts=True -e ghc_with_dynamic_rts=True -e config.have_interp=True -e config.unregisterised=False -e config.have_gdb=True -e config.have_readelf=True -e config.have_fast_bignum=False -e config.ghc_dynamic=True -e ghc_with_smp=True -e config.have_RTS_linker=True -e config.libdir="r\"/home/hasufell/.ghcup/ghc/9.4.4/lib/ghc-9.4.4/lib\"" -e windows=False -e darwin=False -e config.in_tree_compiler=False --skip-perf-tests -e config.cleanup=True -e config.local=True --rootdir=. --config-file=../config/ghc --top="/home/hasufell/tmp/ttt/ghc-9.4.4/testsuite" -e 'config.platform="x86_64-unknown-linux"' -e 'config.os="linux"' -e 'config.arch="x86_64"' -e 'config.wordsize="64"' -e 'config.timeout=int() or config.timeout' -e 'config.exeext=""' --config 'compiler="/home/hasufell/.ghcup/tmp/ghcup-ghc-9.4.4/ghc"' --config 'ghc_pkg="/home/hasufell/.ghcup/tmp/ghcup-ghc-9.4.4/ghc-pkg"' --config 'haddock="/home/hasufell/.ghcup/tmp/ghcup-ghc-9.4.4/haddock"' --config 'hp2ps="/home/hasufell/.ghcup/tmp/ghcup-ghc-9.4.4/hp2ps"' --config 'hpc="/home/hasufell/.ghcup/tmp/ghcup-ghc-9.4.4/hpc"' --config 'gs="gs"' --config 'timeout_prog="../timeout/install-inplace/bin/timeout"' --config 'stats_files_dir=../tests/perf/haddock' -e "config.stage=2" \
--only=Rename1 \
\
--way=optasm \
\
\
\
fatal: not a git repository (or any of the parent directories): .git
Failed to find `llc` command; skipping LLVM ways...
Timeout is 300
Known ways: prof, normal_h, prof_hc_hb, prof_hb, prof_hd, prof_hy, prof_hr, sanity, threaded1_ls, threaded2_hT, debug_numa, llvm, debugllvm, profllvm, profoptllvm, profthreadedllvm, debug, ghci-ext, ghci-ext-prof, ext-interp, nonmoving, nonmoving_thr, nonmoving_thr_sanity, nonmoving_thr_ghc, compacting_gc
Run ways: normal, hpc, optasm, ghci, threaded1, threaded2, dyn, profasm, profthreaded
Compile ways: normal, hpc, optasm, profasm
Failed to get allowed metric changes from the HEAD git commit message.
Allowing performance changes in:
Found 519 .T files...
Beginning test run at Sat Jan 7 23:42:45 2023
Detected CPU features: {'xgetbv1', 'arch_capabilities', 'hwp_notify', 'cx16', 'pclmulqdq', 'erms', 'clflush', 'vpid', 'pse', 'sse2', 'aperfmperf', 'ht', 'x2apic', 'sse3', 'hwp_epp', 'f16c', 'pdcm', 'ospke', 'ept_ad', 'invpcid_single', 'art', 'dtherm', 'xtopology', 'tm2', 'rdseed', 'msr', 'md_clear', ':', 'ibrs_enhanced', 'pge', 'fsgsbase', 'tpr_shadow', 'constant_tsc', 'xtpr', 'flags', 'pebs', 'intel_pt', 'sse4_2', 'pbe', 'ssse3', 'bts', 'mce', 'mca', 'lahf_lm', 'tsc', 'pku', 'cpuid_fault', 'tm', 'nx', 'vmx', 'syscall', 'sse4_1', 'xsavec', 'nopl', 'movbe', 'cpuid', 'ept', 'nonstop_tsc', 'aes', 'stibp', 'avx2', 'arch_perfmon', 'invpcid', 'xsaveopt', 'vme', 'rdrand', 'dtes64', 'fma', 'sgx_lc', 'sdbg', 'hwp_act_window', 'sse', 'fpu', 'pts', 'cx8', 'clflushopt', 'ss', 'mmx', 'smep', 'ssbd', 'smap', 'arat', 'lm', 'ds_cpl', 'ida', 'fxsr', 'flush_l1d', 'rdtscp', 'xsaves', 'pdpe1gb', 'adx', 'pat', 'est', 'pae', 'acpi', 'tsc_deadline_timer', 'popcnt', 'vnmi', 'hwp', 'apic', 'dts', 'mtrr', 'monitor', 'tsc_adjust', 'xsave', '3dnowprefetch', 'mpx', 'sgx', 'pse36', 'sep', 'rep_good', 'pcid', 'flexpriority', 'abm', 'epb', 'bmi1', 'ibpb', 'avx', 'cmov', 'ibrs', 'pln', 'de', 'bmi2'}
Found CPU features: xgetbv1 arch_capabilities hwp_notify cx16 pclmulqdq erms clflush vpid pse sse2 aperfmperf ht x2apic sse3 hwp_epp f16c pdcm ospke ept_ad invpcid_single art dtherm xtopology tm2 rdseed msr md_clear : ibrs_enhanced pge fsgsbase tpr_shadow constant_tsc xtpr flags pebs intel_pt sse4_2 pbe ssse3 bts mce mca lahf_lm tsc pku cpuid_fault tm nx vmx syscall sse4_1 xsavec nopl movbe cpuid ept nonstop_tsc aes stibp avx2 arch_perfmon invpcid xsaveopt vme rdrand dtes64 fma sgx_lc sdbg hwp_act_window sse fpu pts cx8 clflushopt ss mmx smep ssbd smap arat lm ds_cpl ida fxsr flush_l1d rdtscp xsaves pdpe1gb adx pat est pae acpi tsc_deadline_timer popcnt vnmi hwp apic dts mtrr monitor tsc_adjust xsave 3dnowprefetch mpx sgx pse36 sep rep_good pcid flexpriority abm epb bmi1 ibpb avx cmov ibrs pln de bmi2
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
=====> 1 of 1 [0, 0, 0]
Wrong exit code for Rename1()(expected 0 , actual 2 )
Stderr ( Rename1 ):
/bin/sh: line 1: /home/hasufell/tmp/ttt/ghc-9.4.4/inplace/bin/check-exact: No such file or directory
make[2]: *** [Makefile:28: Rename1] Error 127
*** unexpected failure for Rename1(optasm)
Performance Metrics (test environment: local):
None collected.
Unexpected results from:
TEST="Rename1"
SUMMARY for test run started at Sat Jan 7 23:42:45 2023
0:00:00.414214 spent to go through
1 total tests, which gave rise to
13 test cases, of which
8 were skipped
0 had missing libraries
0 expected passes
0 expected failures
0 caused framework failures
0 caused framework warnings
0 unexpected passes
1 unexpected failures
0 unexpected stat failures
0 fragile tests
Unexpected failures:
ghc-api/exactprint/Rename1.run Rename1 [bad exit code (2)] (optasm)
make[1]: *** [../mk/test.mk:344: test] Error 1
make[1]: Leaving directory '/home/hasufell/tmp/ttt/ghc-9.4.4/testsuite/tests'
make: *** [Makefile:20: all] Error 2
```
It is looking for `/home/hasufell/tmp/ttt/ghc-9.4.4/inplace/bin/check-exact`, which does not exist. There are more tests with other files missing e.g. `/home/hasufell/tmp/ttt/ghc-9.4.4/inplace/bin/check-ppr`.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/22726Test bindist expects STAGE1_GHC to be set2023-01-17T16:33:38ZJulian OspaldTest bindist expects STAGE1_GHC to be setThis is also nowhere documented.
```
$ make Sun 11:19
./ghc-config/ghc-config "/home/hasufell/.ghcup/bin/...This is also nowhere documented.
```
$ make Sun 11:19
./ghc-config/ghc-config "/home/hasufell/.ghcup/bin/ghc" >"mk/ghcconfig_home_hasufell_.ghcup_bin_ghc.mk"; if [ "$?" != "0" ]; then rm -f "mk/ghcconfig_home_hasufell_.ghcup_bin_ghc.mk"; exit 1; fi
make -C ./tests all
make[1]: Entering directory '/home/hasufell/.ghcup/tmp/ghcup-a50aa16327ccbe22/ghc-9.4.4/testsuite/tests'
ghc-pkg: cannot find package ghc-bignum
Looks like you don't have timeout, building it first...
make -C ../timeout all
make[2]: Entering directory '/home/hasufell/.ghcup/tmp/ghcup-a50aa16327ccbe22/ghc-9.4.4/testsuite/timeout'
rm -f -f TimeMe.o TimeMe.hi TimeMe TimeMe.exe
python3 calibrate '' > calibrate.out
Traceback (most recent call last):
File "/home/hasufell/.ghcup/tmp/ghcup-a50aa16327ccbe22/ghc-9.4.4/testsuite/timeout/calibrate", line 19, in <module>
spawnl(os.P_WAIT, compiler,
File "/usr/lib64/python3.10/os.py", line 928, in spawnl
return spawnv(mode, file, args)
File "/usr/lib64/python3.10/os.py", line 879, in spawnv
return _spawnvef(mode, file, args, None, execv)
File "/usr/lib64/python3.10/os.py", line 850, in _spawnvef
raise ValueError('argv first element cannot be empty')
ValueError: argv first element cannot be empty
make[2]: *** [Makefile:54: calibrate.out] Error 1
make[2]: Leaving directory '/home/hasufell/.ghcup/tmp/ghcup-a50aa16327ccbe22/ghc-9.4.4/testsuite/timeout'
make[1]: *** [../mk/test.mk:338: ../timeout/install-inplace/bin/timeout] Error 2
make[1]: Leaving directory '/home/hasufell/.ghcup/tmp/ghcup-a50aa16327ccbe22/ghc-9.4.4/testsuite/tests'
make: *** [Makefile:20: all] Error 2
```
Then:
```
$ STAGE1_GHC=ghc make 704ms Sun 11:19
make -C ./tests all
make[1]: Entering directory '/home/hasufell/.ghcup/tmp/ghcup-a50aa16327ccbe22/ghc-9.4.4/testsuite/tests'
ghc-pkg: cannot find package ghc-bignum
Looks like you don't have timeout, building it first...
make -C ../timeout all
make[2]: Entering directory '/home/hasufell/.ghcup/tmp/ghcup-a50aa16327ccbe22/ghc-9.4.4/testsuite/timeout'
rm -rf install-inplace
mkdir install-inplace
mkdir install-inplace/bin
cp timeout.py install-inplace/bin/timeout.py
echo '#!/bin/sh' > install-inplace/bin/timeout
echo 'exec "python3" $0.py "$@"' >> install-inplace/bin/timeout
chmod +x install-inplace/bin/timeout
make[2]: Leaving directory '/home/hasufell/.ghcup/tmp/ghcup-a50aa16327ccbe22/ghc-9.4.4/testsuite/timeout'
PYTHON="python3" "python3" ../driver/runtests.py -e "ghc_compiler_always_flags='-dcore-lint -dstg-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output'" -e "config.compiler_debugged=False" -e ghc_with_native_codegen=True -e "config.leading_underscore=False" -e ghc_with_threaded_rts=True -e ghc_with_dynamic_rts=True -e config.have_interp=True -e config.unregisterised=False -e config.have_gdb=True -e config.have_readelf=True -e config.have_fast_bignum=False -e config.ghc_dynamic=True -e ghc_with_smp=True -e config.have_RTS_linker=True -e config.libdir="r\"/home/hasufell/.ghcup/ghc/8.10.7/lib/ghc-8.10.7\"" -e windows=False -e darwin=False -e config.in_tree_compiler=False -e config.cleanup=True -e config.local=True --rootdir=. --config-file=../config/ghc --top="/home/hasufell/.ghcup/tmp/ghcup-a50aa16327ccbe22/ghc-9.4.4/testsuite" -e 'config.platform="x86_64-unknown-linux"' -e 'config.os="linux"' -e 'config.arch="x86_64"' -e 'config.wordsize="64"' -e 'config.timeout=int() or config.timeout' -e 'config.exeext=""' --config 'compiler="/home/hasufell/.ghcup/bin/ghc"' --config 'ghc_pkg="/home/hasufell/.ghcup/bin/ghc-pkg"' --config 'haddock="/home/hasufell/.ghcup/bin/haddock"' --config 'hp2ps="/home/hasufell/.ghcup/bin/hp2ps"' --config 'hpc="/home/hasufell/.ghcup/bin/hpc"' --config 'gs="gs"' --config 'timeout_prog="../timeout/install-inplace/bin/timeout"' --config 'stats_files_dir=../tests/perf/haddock' -e "config.stage=2" \
\
\
\
\
\
\
fatal: not a git repository (or any of the parent directories): .git
Failed to find `llc` command; skipping LLVM ways...
```Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/22748Include release file manifests and track them in a changelog2023-02-07T17:33:30ZDavid Thrane ChristiansenInclude release file manifests and track them in a changelog<!--
READ THIS FIRST: If the feature you are proposing changes the language that GHC accepts
or adds any warnings to `-Wall`, it should be written as a [GHC Proposal](https://github.com/ghc-proposals/ghc-proposals/).
Other features, appr...<!--
READ THIS FIRST: If the feature you are proposing changes the language that GHC accepts
or adds any warnings to `-Wall`, it should be written as a [GHC Proposal](https://github.com/ghc-proposals/ghc-proposals/).
Other features, appropriate for a GitLab feature request, include GHC API/plugin
innovations, new low-impact compiler flags, or other similar additions to GHC.
-->
## Motivation
Packagers and redistributors of GHC, such as Linux distributions, have automation that is sensitive to the internal structure of GHC release files. When this changes, they need to adapt their tools, but today it can be difficult to know that a change has occurred or to find out what needs to be done without lots of experimentation.
## Proposal
1. Release files should contain a manifest describing their contents
2. Changes to these manifests between releases should be documented in the changelog
3. CI should be used to ensure that the manifest changes are documented and that the manifests are accurate
This is from the GHC prioritization process.https://gitlab.haskell.org/ghc/ghc/-/issues/22790Consider whether native bignum backend should be used by default2023-02-12T12:26:31ZBen GamariConsider whether native bignum backend should be used by defaultIn the past week have have three distinct tickets which were traceable back to `gmp`'s lack of releases: one undefined behavior issue (#22497), one exploitable buffer overflow (#22789), and one WebAssembly-specific stack overflow (#22602...In the past week have have three distinct tickets which were traceable back to `gmp`'s lack of releases: one undefined behavior issue (#22497), one exploitable buffer overflow (#22789), and one WebAssembly-specific stack overflow (#22602). This, coupled with the fact that `gmp` adds complexity to our packaging story, makes me wonder whether we wouldn't be better off simply switching our binary distributions to use the Haskell-native bignum backend by default. Last I recall, the `native` backend implements most common operations reasonably efficiency and bignum operations constitute a vanishingly small fraction of CPU time in most programs.https://gitlab.haskell.org/ghc/ghc/-/issues/22972Providing IPE-enabled bindists in the release pipeline2023-09-07T10:56:34ZHécate MoonlightProviding IPE-enabled bindists in the release pipelineIt would significantly improve the usability of info-table profiling if IPE-enabled bindists were provided by our release pipeline.It would significantly improve the usability of info-table profiling if IPE-enabled bindists were provided by our release pipeline.9.10.1Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/22973[FOREIGN] Have ghcup distribute IPE-enabled bindists2023-02-14T15:12:11ZHécate Moonlight[FOREIGN] Have ghcup distribute IPE-enabled bindistsThis ticket will track the integration of IPE-enabled bindists into ghcup, when #22972 is doneThis ticket will track the integration of IPE-enabled bindists into ghcup, when #22972 is doneMatthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/22999Support stack-protector in new clang based toolchain2023-08-16T01:40:54ZTamar ChristinaSupport stack-protector in new clang based toolchainThe move to the clang based toolchain inadvertedly regressed being able to link against sources compiled with `-fstack-protector` which requires the ability to be able to link against the libssp support functions [1][2].
With the GCC ba...The move to the clang based toolchain inadvertedly regressed being able to link against sources compiled with `-fstack-protector` which requires the ability to be able to link against the libssp support functions [1][2].
With the GCC based toolchains we got this because GCC builds `libssp` as that's part of it's built tree. Clang doesn't and instead relies on the libc to provide the symbols. Typically on Linux this is provided by glibc.
However at the time the clang package was chosen for GHC the `mingw-w64-crt` did not provide this yet, but it does now [3]
So a couple of things:
1. For newer GHC releases we should upgrade the packaged clang and crt to at least clang 10. (It's currently 9.)
2. For current and newer GHCs we should provide `mingw-w64-clang-x86_64-libssp` as part of the packaging. Which version is ***very very important***.
* For the clang 9 based toolchains we ***require*** version `7.3.0-1` as this one will contain the import library that is missing from the crt.
* For clang 10+ we require at least version `7.3.0-3` as this resolves a symbol conflict because the crt is now providing the symbols.
For this to work it requires the recent fixes @bgamari made such that the `-L` paths of the base toolchain is taken over that of the system one, otherwise you'll get the symbol conflict with the crt if your system clang is too new.
[1] https://github.com/fjvallarino/monomer/issues/258
[2] https://github.com/haskell-game/sdl2/issues/277
[3] https://packages.msys2.org/package/mingw-w64-clang-x86_64-crt-git?repo=clang64Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/23014LTS bindists2023-02-21T16:47:41ZJulian OspaldLTS bindistsIt would be nice to have a release that provides long-term support for the bindist portion of a release. That means this is unrelated to code backports, but may include:
1. creating new bindists for an existing platform (e.g. a new debi...It would be nice to have a release that provides long-term support for the bindist portion of a release. That means this is unrelated to code backports, but may include:
1. creating new bindists for an existing platform (e.g. a new debian version)
- this would be optimally done by GHC devs in collaboration with GHCup/Stack maintainers
- motivation: recent Fedora dropping ncurses-compat-libs (and then adding it back later) made me think that this would simply be good form to do prematurely
2. creating new bindists for a new platform (e.g. void linux)
- this would have to be initiated by a contributor
- GHC devs would however support the PR by investigating and fixing test issues (to an extent)
- motivation: the "unknown linux" in GHCup is already the most fragile part of the redistribution, so adding new distros in case they turn out to be popular amongst Haskellers can make sense
3. backporting bindist code fixes (e.g. configure or Makefile issues)
The support window should be at least 3 years, in my opinion. Point 1. and 2. would also be forward ported to the latest GHC release and/or the upcoming one.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/23114`ghc-pkg check` reports non-existent include-dirs warnings2023-03-13T17:10:27ZBen Gamari`ghc-pkg check` reports non-existent include-dirs warningsIn the GHC 9.6.1 bindist `ghc-pkg check` reports that `directory`'s package registration's `include-dir` field refers to a non-existent path:
```
$ ghc-pkg check
Warning: include-dirs: /nix/store/78g7mg8ni9y3ph1yvf7qxkiig32nb1wi-ghc-9.6...In the GHC 9.6.1 bindist `ghc-pkg check` reports that `directory`'s package registration's `include-dir` field refers to a non-existent path:
```
$ ghc-pkg check
Warning: include-dirs: /nix/store/78g7mg8ni9y3ph1yvf7qxkiig32nb1wi-ghc-9.6.1-alpha1/lib/ghc-9.6.0.20230111/lib/../lib/x86_64-linux-ghc-9.6.0.20230111/directory-1.3.8.0/include doesn't exist or isn't a directory
```9.6.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/23490Fix cabal-install of ghc package2023-09-27T18:27:58ZMatthew PickeringFix cabal-install of ghc packagehttps://gitlab.haskell.org/ghc/ghc/-/merge_requests/10547 has regressed support for building `ghc` library using `cabal-install` as part of the build now needs to be generated using a python script (which is not called from Setup.hs).
E...https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10547 has regressed support for building `ghc` library using `cabal-install` as part of the build now needs to be generated using a python script (which is not called from Setup.hs).
Either we need to revert this patch or fix the Setup.hs.
I am not sure if we should add a build dependency on python like this though. An alternative is to rewrite the generation script in Haskell so we can depend on it using build-tool-depends like the normal primops generation logic.https://gitlab.haskell.org/ghc/ghc/-/issues/23519RISC-V binary packages2023-06-20T14:37:11ZFrancesco Gazzettafgaz@fgaz.meRISC-V binary packagesAffordable and powerful enough RISC-V machines are starting to pop up. Having official RISC-V binary tarballs would make native bootstrapping easier.Affordable and powerful enough RISC-V machines are starting to pop up. Having official RISC-V binary tarballs would make native bootstrapping easier.https://gitlab.haskell.org/ghc/ghc/-/issues/23594GHC 9.6 bindists for Aarch64 linux have a broken install of directory package2023-10-10T15:55:22ZAlex MasonGHC 9.6 bindists for Aarch64 linux have a broken install of directory package## Summary
Installing GHC 9.6.1 and 9.6.2 on Aarch64 ubuntu using GHCup leads to a broken installation of the directory package.
## Steps to reproduce
1. Install ghcup
2. `ghcup install ghc 9.6.2` (or 9.6.1)
3. `ghcup set ghc 9.6.2`
4...## Summary
Installing GHC 9.6.1 and 9.6.2 on Aarch64 ubuntu using GHCup leads to a broken installation of the directory package.
## Steps to reproduce
1. Install ghcup
2. `ghcup install ghc 9.6.2` (or 9.6.1)
3. `ghcup set ghc 9.6.2`
4. `ghc-pkg check --verbose`
```shell
> ghc-pkg check --verbose
GHC package manager version 9.6.2
Timestamp 2023-07-02 11:06:19.951587334 UTC for /data/home/ubuntu/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/package.conf.d/package.cache
using cache: /data/home/ubuntu/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/package.conf.d/package.cache
db stack: ["/data/home/ubuntu/.ghc/aarch64-linux-9.6.2/package.conf.d","/data/home/ubuntu/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/package.conf.d"]
flag db stack: ["/data/home/ubuntu/.ghc/aarch64-linux-9.6.2/package.conf.d","/data/home/ubuntu/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/package.conf.d"]
Warning: include-dirs: /data/home/ubuntu/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/aarch64-linux-ghc-9.6.2/directory-1.3.8.1/include doesn't exist or isn't a directory
```
```shell
> tree $HOME/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/aarch64-linux-ghc-9.6.2/directory-1.3.8.1/
/data/home/ubuntu/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/../lib/aarch64-linux-ghc-9.6.2/directory-1.3.8.1/
├── System
│ ├── Directory
│ │ ├── Internal
│ │ │ ├── C_utimensat.dyn_hi
│ │ │ ├── C_utimensat.hi
│ │ │ ├── C_utimensat.p_hi
│ │ │ ├── Common.dyn_hi
│ │ │ ├── Common.hi
│ │ │ ├── Common.p_hi
│ │ │ ├── Config.dyn_hi
│ │ │ ├── Config.hi
│ │ │ ├── Config.p_hi
│ │ │ ├── Posix.dyn_hi
│ │ │ ├── Posix.hi
│ │ │ ├── Posix.p_hi
│ │ │ ├── Prelude.dyn_hi
│ │ │ ├── Prelude.hi
│ │ │ ├── Prelude.p_hi
│ │ │ ├── Windows.dyn_hi
│ │ │ ├── Windows.hi
│ │ │ └── Windows.p_hi
│ │ ├── Internal.dyn_hi
│ │ ├── Internal.hi
│ │ ├── Internal.p_hi
│ │ ├── OsPath.dyn_hi
│ │ ├── OsPath.hi
│ │ └── OsPath.p_hi
│ ├── Directory.dyn_hi
│ ├── Directory.hi
│ └── Directory.p_hi
├── libHSdirectory-1.3.8.1.a
└── libHSdirectory-1.3.8.1_p.a
3 directories, 29 files
```
```shell
> cat $HOME/.ghcup/ghc/9.6.2/lib/ghc-9.6.2/lib/package.conf.d/directory-1.3.8.1.conf
...
data-dir:
${pkgroot}/../share/aarch64-linux-ghc-9.6.2/directory-1.3.8.1
hs-libraries: HSdirectory-1.3.8.1
include-dirs:
${pkgroot}/../lib/aarch64-linux-ghc-9.6.2/directory-1.3.8.1/include
depends:
base-4.18.0.0 filepath-1.4.100.1 time-1.12.2 unix-2.8.1.0
...
```
## Expected behavior
I assume the include directory should exist, or the package config shouldn't include the above include-dirs directive:
```shell
> cat $HOME/.ghcup/ghc/9.4.5/lib/ghc-9.4.5/lib/package.conf.d/directory-1.3.7.1.conf
...
data-dir:
${pkgroot}/../share/aarch64-linux-ghc-9.4.5/directory-1.3.7.1
hs-libraries: HSdirectory-1.3.7.1
depends: base-4.17.1.0 filepath-1.4.2.2 time-1.12.2 unix-2.7.3
...
```
## Environment
```shell
> uname -a
Linux ip-172-31-17-153 5.19.0-1025-aws #26~22.04.1-Ubuntu SMP Mon Apr 24 01:58:03 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux
> ghcup --version
The GHCup Haskell installer, version 0.1.19.4
> ghc --version
The Glorious Glasgow Haskell Compilation System, version 9.6.2
```9.8.2ZubinBen GamariZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/23601ghcup-metadata: In nightly pipelines, still generate the metadata even if som...2023-09-25T11:13:57ZMatthew Pickeringghcup-metadata: In nightly pipelines, still generate the metadata even if some of the jobs failAt the moment if one of the jobs fails (ie Centos7) then the metadata generation script fails to run. We should instead for the nightly builds just omit that part of the metadata if the relevant job doesn't exist, so the nightly can stil...At the moment if one of the jobs fails (ie Centos7) then the metadata generation script fails to run. We should instead for the nightly builds just omit that part of the metadata if the relevant job doesn't exist, so the nightly can still be uploaded for all the platforms where things do work.
This would have fall-out effects later on in the pipeline when the metadata we generated is tested (`ghcup-ci`) but if this situation happens then the pipeline will already be failing.
OTOH, this might just be a bad idea because if you are trying to rely on the nightly pipelines it could be a bit unpredictable which bindist ghcup will try and install as if your "normal" bindist isn't available it will try the fallback (rocky8) which may or may not work for your platform.
We should at least requires that certain platforms pass CI (these ones are tested on normal validate pipelines anyway):
* darwin (x86/aarch64)
* windows
* fedora33
* deb10
* rocky8 (the fallback)
cc @maerwald who requested this.Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/23608$tooldir variable in settings should not exist2023-08-23T17:44:01ZMatthew Pickering$tooldir variable in settings should not existAfter a call with @alt-romes we discussed why 5d76846405240c051b00cddcda9d8d02c880968e introduced support for the `$tooldir` variable in a settings file.
It seems that this support for finding the tooldir (see `findToolDir` which looks...After a call with @alt-romes we discussed why 5d76846405240c051b00cddcda9d8d02c880968e introduced support for the `$tooldir` variable in a settings file.
It seems that this support for finding the tooldir (see `findToolDir` which looks upwards two directories) was implemented as workaround for the fact that the bundled mingw toolchain exists in two diffent places during a build and in the bindist.
1. During a build `mingw` exists at `$topdir/../../mingw` because the bundled toolchain is placed in `_build/mingw` rather than `_build/stageN/mingw`, and topdir is `_build/stageN/lib`.
2. In a bindist the `mingw` folder is in `$topdir/../mingw`
It seems that a better solution is to have a different settings file for build time and install time
* The settings file during a build points to `$topdir/../../mingw`
* The settings file in the bindist points to `$topdir/../mingw`
This situation mirrors the same situation as with linux builds where we have one settings file which is used during the build process and then a generate a different settings file at install time. The difference is that on windows we can generate this "install time" settings file at build time because it's the same for all installations.
cc @alt-romeshttps://gitlab.haskell.org/ghc/ghc/-/issues/23615Remove x86_64 deb9 bindists2023-08-24T19:20:19ZMatthew PickeringRemove x86_64 deb9 bindistsUbuntu 18 and Linux Mint 19 are now EOL so debian 9 bindists are on their last legs (deb9 is also now EOL).
If something happens to the deb9 build we should just retire these bindists rather than attempt to fix it again.
cc @maerwaldUbuntu 18 and Linux Mint 19 are now EOL so debian 9 bindists are on their last legs (deb9 is also now EOL).
If something happens to the deb9 build we should just retire these bindists rather than attempt to fix it again.
cc @maerwaldhttps://gitlab.haskell.org/ghc/ghc/-/issues/23714Release ghc-toolchain and ghc-platform on hackage2023-08-03T18:29:29ZRodrigo MesquitaRelease ghc-toolchain and ghc-platform on hackageWe should release the two recently-introduced packages on hackage
* We should, when !9263, !10903, and the fixes in !10901 land, upload ghc-toolchain to hackage.
* ghc-platform has already landed on master - we should upload it to hackag...We should release the two recently-introduced packages on hackage
* We should, when !9263, !10903, and the fixes in !10901 land, upload ghc-toolchain to hackage.
* ghc-platform has already landed on master - we should upload it to hackage.
See also the related comment in https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10696#note_513029 asking for ghc-platform to be uploaded ASAP.9.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/23828Provide dynamically linked alpine binary distributions.2023-08-15T13:43:14ZOleg GrenrusProvide dynamically linked alpine binary distributions.My primary use for Alpine is to produce staticly linked linux binaries. But I don't care how GHC itself is linked, as long as it can produce (both C and Hs) static binaries.
E.g. I don't need https://gitlab.haskell.org/ghc/ghc/-/issues/...My primary use for Alpine is to produce staticly linked linux binaries. But I don't care how GHC itself is linked, as long as it can produce (both C and Hs) static binaries.
E.g. I don't need https://gitlab.haskell.org/ghc/ghc/-/issues/23043 to be resolved, which as far as I understand is a hard issue, but apparently building dynamically linked alpine distibution is not impossible (@maerwald comment https://gitlab.haskell.org/ghc/ghc/-/issues/23043#note_513809).
I'd welcome the official dynamic alpine bindists.https://gitlab.haskell.org/ghc/ghc/-/issues/23854ghc-toolchain binary not in cross-compiler bindists2023-08-22T14:58:04ZMatthew Pickeringghc-toolchain binary not in cross-compiler bindistsSee: https://gitlab.haskell.org/ghc/ghc/-/jobs/1641836
```
./configure: line 12232: bin/ghc-toolchain-bin: No such file or directory
./configure: line 12401: bin/ghc-toolchain-bin: No such file or directory
./configure: line 12410: bin/...See: https://gitlab.haskell.org/ghc/ghc/-/jobs/1641836
```
./configure: line 12232: bin/ghc-toolchain-bin: No such file or directory
./configure: line 12401: bin/ghc-toolchain-bin: No such file or directory
./configure: line 12410: bin/ghc-toolchain-bin: No such file or directory
./configure: line 12411: bin/ghc-toolchain-bin: No such file or directory
```Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/23871Testing ghc-toolchain in packaging environments2023-08-24T07:21:20ZMatthew PickeringTesting ghc-toolchain in packaging environmentsWe want to test that ghc-toolchain works in as many situations as possible. This will require building ghc with the `--enable-strict-ghc-toolchain-check` configure flag and verifying that the output produced by ghc-toolchain is the same ...We want to test that ghc-toolchain works in as many situations as possible. This will require building ghc with the `--enable-strict-ghc-toolchain-check` configure flag and verifying that the output produced by ghc-toolchain is the same as the configure script.
Here are a list of potential places where we will want to test this:
- [x] GHC CI itself ( !10976 )
- [ ] Fedora packaging (cc @juhp)
- [ ] Debian packaging
- [ ] Homebrew packaging
- [ ] Haskell.nix packaging
- [ ] nixpkgs packaging
Perhaps people have some other ideas about places where GHC is built from source we should also be testing.Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/24007relpath.sh script produces wrong results2023-10-03T21:40:13ZIlias Tsitsimpisrelpath.sh script produces wrong results## Summary
The mk/relpath.sh script is supposed to be a shell implementation of realpath, but produces wrong results.
## Steps to reproduce
```
$ ./mk/relpath.sh /usr/lib/ghc/lib /usr/lib/ghc-doc
..-doc
```
## Expected behavior
```
...## Summary
The mk/relpath.sh script is supposed to be a shell implementation of realpath, but produces wrong results.
## Steps to reproduce
```
$ ./mk/relpath.sh /usr/lib/ghc/lib /usr/lib/ghc-doc
..-doc
```
## Expected behavior
```
$ realpath --relative-to=/usr/lib/ghc/lib /usr/lib/ghc-doc
../../ghc-doc
```9.8.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24028Missing users_guide for the Windows distributions of GHC 9.6.*2024-01-09T10:32:10ZHai / @BestYeenMissing users_guide for the Windows distributions of GHC 9.6.*## Summary
In the past, the users_guide doc directory was shipped with the Windows distro of GHC, and that was very handy.
At the moment, it's not shipped anymore, but there's still a link to it in the shipped docs, which is now dead.
...## Summary
In the past, the users_guide doc directory was shipped with the Windows distro of GHC, and that was very handy.
At the moment, it's not shipped anymore, but there's still a link to it in the shipped docs, which is now dead.
A short discussion about it is here: https://discourse.haskell.org/t/ghc-9-6-3-is-now-released/7682
I'm using this documentation a lot when working with Haskell, and I prefer the docs I use to be easy to obtain for offline use.
Please include it again. It's extremely useful to have. Sorry for being a Windows user in this case. :)9.8.2Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/24093user_guide.pdf not present in doc tarball2024-03-17T23:54:24ZBen Gamariuser_guide.pdf not present in doc tarballIn 9.8.1 the PDF version of the user-guide did not make it into the doc-tarball which gets uploaded to `downloads.haskell.org`.In 9.8.1 the PDF version of the user-guide did not make it into the doc-tarball which gets uploaded to `downloads.haskell.org`.9.10.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/241219.8.1 hadrian installs libraries LICENSE files into /usr/lib64/ghc-9.8.1/shar...2023-10-31T15:02:42ZJens Petersen9.8.1 hadrian installs libraries LICENSE files into /usr/lib64/ghc-9.8.1/share/doc/x86_64-linux-ghc-9.8.1/*/## Summary
## Steps to reproduce
The general Fedora steps are in ghc9.8.spec here:
https://src.fedoraproject.org/rpms/ghc9.8/tree/rawhide
But currently it works around this problem by just removing the said files at the end.
So curren...## Summary
## Steps to reproduce
The general Fedora steps are in ghc9.8.spec here:
https://src.fedoraproject.org/rpms/ghc9.8/tree/rawhide
But currently it works around this problem by just removing the said files at the end.
So currently it is not a high priority - though the file path seems unsatisfactory to me.
## Expected behavior
The LICENSE files are platform dependent so they could be installed in `/usr/lib64/ghc-9.8.1/share/doc/*/` at least.
Normally they should live around `/usr/share/{doc,licenses}/ghc-9.8.1/*/` instead.
## Environment
* GHC version used: 9.8.1
Optional:
* Operating System: Fedora Linux
* System Architecture: x86_649.8.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24122Boot library version history table is missing 9.4.x entries for x>42023-10-31T15:04:20ZBryan Rbryan@haskell.foundationBoot library version history table is missing 9.4.x entries for x>4https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/libraries/version-history only goes up to 9.4.4.https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/libraries/version-history only goes up to 9.4.4.ZubinZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/24129GHC doc build broken by sphinx 72023-11-01T08:10:39ZsterniGHC doc build broken by sphinx 7## Summary
Building the GHC documentation fails with
```
Theme error:
An error happened in rendering the page 9.0.1-notes.
Reason: UndefinedError("'style' is undefined")
```
After upgrading to sphinx 7.2.6.
## Steps to reproduce
Bui...## Summary
Building the GHC documentation fails with
```
Theme error:
An error happened in rendering the page 9.0.1-notes.
Reason: UndefinedError("'style' is undefined")
```
After upgrading to sphinx 7.2.6.
## Steps to reproduce
Build GHC with sphinx 7.2.6, e.g. by building any `ghc*` (non `Binary` ofc) attribute under `haskell.compiler` on nixpkgs `6515b811b82a83f551988dd25ec6ef587fa93ef0`.
Example logs:
- https://hydra.nixos.org/build/239488473/nixlog/1
- https://hydra.nixos.org/build/239551789/nixlog/1
## Expected behavior
Build succeeds.
## Environment
* GHC version used: 9.0.2, 9.4.7
Optional:
* Operating System: NixOS
* System Architecture: x86_64-linux, aarch64-darwinMatthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/242009.2.8 armv7 bindist is broken2023-11-22T04:02:21ZJulian Ospald9.2.8 armv7 bindist is broken`make install` of bindist https://downloads.haskell.org/~ghc/9.2.8/ghc-9.2.8-armv7-deb10-linux.tar.xz fails with
```
/usr/bin/install -c -m 755 -d "/root/.ghcup/tmp/ghcup-c90a8b5e/root/.ghcup/ghc/9.2.8/lib/ghc-9.2.8"
for i in driver/g...`make install` of bindist https://downloads.haskell.org/~ghc/9.2.8/ghc-9.2.8-armv7-deb10-linux.tar.xz fails with
```
/usr/bin/install -c -m 755 -d "/root/.ghcup/tmp/ghcup-c90a8b5e/root/.ghcup/ghc/9.2.8/lib/ghc-9.2.8"
for i in driver/ghc-usage.txt driver/ghci-usage.txt includes/dist/build/settings llvm-targets llvm-passes; do case $i in *.a) /usr/bin/install -c
-m 644 $i "/root/.ghcup/tmp/ghcup-c90a8b5e/root/.ghcup/ghc/9.2.8/lib/ghc-9.2.8"; true "/root/.ghcup/tmp/ghcup-c90a8b5e/root/.ghcup/ghc/9.2.8/lib
/ghc-9.2.8"/`basename $i` ;; *.dll) /usr/bin/install -c -m 755 $i "/root/.ghcup/tmp/ghcup-c90a8b5e/root/.ghcup/ghc/9.2.8/lib/ghc-9.2.8" ; : "/ro
ot/.ghcup/tmp/ghcup-c90a8b5e/root/.ghcup/ghc/9.2.8/lib/ghc-9.2.8"/`basename $i` ;; *.so) /usr/bin/install -c -m 755 $i "/root/.ghcup/tmp/ghcup-c9
0a8b5e/root/.ghcup/ghc/9.2.8/lib/ghc-9.2.8" ;; *.dylib) /usr/bin/install -c -m 755 $i "/root/.ghcup/tmp/ghcup-c90a8b5e/root/.ghcup/ghc/9.2.8/lib/
ghc-9.2.8";; *) /usr/bin/install -c -m 644 $i "/root/.ghcup/tmp/ghcup-c90a8b5e/root/.ghcup/ghc/9.2.8/lib/ghc-9.2.8"; esac; done
gcc -E -undef -traditional -P -DINSTALLING -DLIB_DIR='"/root/.ghcup/ghc/9.2.8/lib/ghc-9.2.8"' -DINCLUDE_DIR='"/root/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/
include"' -DFFI_INCLUDE_DIR= -DFFI_LIB_DIR= '-DFFI_LIB="Cffi"' -DLIBDW_INCLUDE_DIR= -DLIBDW_LIB_DIR= -Iincludes -Iincludes/dist -Iincludes/dist-der
ivedconstants/header -Iincludes/dist-ghcconstants/header -Iincludes/dist-install/build -x c rts/package.conf.in -o rts/dist/package.conf.install.ra
w
grep -v '^#pragma GCC' rts/dist/package.conf.install.raw | sed -e 's/""//g' -e 's/:[ ]*,/: /g' >rts/dist/package.conf.install
make[1]: *** No rule to make target 'utils/unlit/dist-install/build/tmp/unlit', needed by 'install_libexecs'. Stop.
make: *** [Makefile:51: install] Error 2
```
----
Building 9.2.8 from source and trying to package/install it results in linking errors, because this hsc2hs bug has not been backported: https://gitlab.haskell.org/ghc/ghc/-/commit/99623358754d812b8b4bdfcdc57190d38617b9cc
I fixed all of that downstream: https://downloads.haskell.org/~ghcup/unofficial-bindists/ghc/9.2.8/ghc-9.2.8-armv7-deb10-linux-gnueabihf.tar.xzhttps://gitlab.haskell.org/ghc/ghc/-/issues/24276The global package db directory of GHC has duplicate files (*.copy)2024-01-09T15:13:57ZOleg GrenrusThe global package db directory of GHC has duplicate files (*.copy)```
/opt/ghc/9.8.1/lib/ghc-9.8.1/lib/package.conf.d % ll
total 1272
-rw-r--r-- 1 phadej phadej 1788 loka 10 10:56 array-0.5.6.0-88aa.conf
-rw-rw-r-- 1 phadej phadej 1788 loka 10 10:56 array-0.5.6.0-88aa.conf....```
/opt/ghc/9.8.1/lib/ghc-9.8.1/lib/package.conf.d % ll
total 1272
-rw-r--r-- 1 phadej phadej 1788 loka 10 10:56 array-0.5.6.0-88aa.conf
-rw-rw-r-- 1 phadej phadej 1788 loka 10 10:56 array-0.5.6.0-88aa.conf.copy
```
I checked versions 9.4.6, 9.6.2 and 9.8.1. All have these `*.copy` files. The 9.2.8 doesn't have.Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/24356Install bash completion file2024-03-05T09:53:22ZBryan Rbryan@haskell.foundationInstall bash completion file#20802 included ghc.bash in the bindist, but it might be nice to actually install it with `make install`, too. At the very least, that would make the script available to GHCup users, though they would still need to manually source it in ...#20802 included ghc.bash in the bindist, but it might be nice to actually install it with `make install`, too. At the very least, that would make the script available to GHCup users, though they would still need to manually source it in their rc files. (Plus, they would need to know where to find it.)https://gitlab.haskell.org/ghc/ghc/-/issues/24525Windows bindists are quite broken2024-03-13T22:32:58ZBen GamariWindows bindists are quite brokenmingw32 binary distributions are currently quite broken:
```bash
$ wget https://gitlab.haskell.org/ghc/ghc/-/jobs/1805153/artifacts/raw/ghc-x86_64-windows-release.tar.xz
$ tar -xf ../ghc-x86_64-windows-release.tar.xz
$ cd ghc-9.10.0.2024...mingw32 binary distributions are currently quite broken:
```bash
$ wget https://gitlab.haskell.org/ghc/ghc/-/jobs/1805153/artifacts/raw/ghc-x86_64-windows-release.tar.xz
$ tar -xf ../ghc-x86_64-windows-release.tar.xz
$ cd ghc-9.10.0.20240310-x86_64-unknown-mingw32/
$ bin/ghc --info
ghc-9.10.0.20240310.exe: could not detect mingw toolchain in the following paths: ["C:\\msys64\\home\\ben\\tmp\\ghc-9.10.0.20240310-x86_64-unknown-mingw32\\lib\\..\\mingw","C:\\msys64\\home\\ben\\tmp\\ghc-9.10.0.20240310-x86_64-unknown-mingw32\\lib\\..\\..\\mingw","C:\\msys64\\home\\ben\\tmp\\ghc-9.10.0.20240310-x86_64-unknown-mingw32\\lib\\..\\..\\..\\mingw"]
```
It appears that many things that should be in the root of the binary distribution are instead now in `lib` (including `mingw/`):
```bash
$ ls lib/
a.exe config.guess config.status default.host.target.in doc ghc-usage.txt install-sh llvm-targets mk README x86_64-windows-ghc-9.10.0.20240310
bin config.log config.sub default.target docs-utils html latex Makefile package.conf.d settings
build.mk config.mk configure default.target.ghc-toolchain ghc-interp.js include lib manpage post-link.mjs template-hsc.h
completion config.mk.in default.host.target default.target.in ghci-usage.txt INSTALL llvm-passes mingw prelude.js wrappers
```
Moving `lib/mingw` to the root of the distribution appears to be sufficient to make the compiler functional.9.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/24529Binary distribution build on Windows fails2024-03-11T02:35:10ZBen GamariBinary distribution build on Windows failsIt appears that the `reloc-binary-dist` target is broken in at least some situations on Windows. Specifically, the `configure` invocation performed by `Rules.BinaryDist.installTo` fails to find the in-place mingw toolchain, causing `ghc-...It appears that the `reloc-binary-dist` target is broken in at least some situations on Windows. Specifically, the `configure` invocation performed by `Rules.BinaryDist.installTo` fails to find the in-place mingw toolchain, causing `ghc-toolchain` to conclude that there is no valid object merging tool available:
```
[Error {errorMessage = "Neither a object-merging tool (e.g. ld -r) nor an ar that supports -L is available", errorLogContexts = []}]
```
What is perplexing is that this appears to work in CI: the build system manages to produce a binary distribution, albeit a broken one for unrelated reasons (#24525).https://gitlab.haskell.org/ghc/ghc/-/issues/24531Runtime failure on windows with zlib-0.7.0.0 when missing zlib library2024-03-12T15:28:23ZHannes SiebenhandlRuntime failure on windows with zlib-0.7.0.0 when missing zlib libraryFirst reported by https://github.com/haskell/zlib/issues/65
GHC doesn't fail compilation of a binary depending on `zlib-0.7.0.0`, although the linking of the zlib system depedency failed. The issue exists at least on GHC 9.2.8 through G...First reported by https://github.com/haskell/zlib/issues/65
GHC doesn't fail compilation of a binary depending on `zlib-0.7.0.0`, although the linking of the zlib system depedency failed. The issue exists at least on GHC 9.2.8 through GHC 9.6.
There is no message when running `cabal build`, but opening a repl session fails with the message:
```
ghc-9.4.8.exe: Could not load `zlib1.dll'. Reason: addDLL: zlib1.dll or dependencies not loaded. (Win32 error 126)
```
I was able to reproduce the issue on Win 10, GHC 9.4.8 and cabal 3.10.2.1, but was unable to reproduce the issue on any windows GitHub CI runners.
I briefly investigated, the main change seems to be that zlib haskell library switched to using `extra-libraries` on windows, which should alwasy exist as GHC ships with zlib on windows. Likewise, I verified the library exists, too.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24538Windows binary distributions ship with empty package database2024-03-14T15:11:57ZBen GamariWindows binary distributions ship with empty package databaseThe `ghcup` validation job for my most recent 9.10.1-alpha1 candidate (https://gitlab.haskell.org/ghc/ghcup-ci/-/jobs/1807133) reveals that Windows binary distributions are unserviceable, failing to find any of the boot packages during c...The `ghcup` validation job for my most recent 9.10.1-alpha1 candidate (https://gitlab.haskell.org/ghc/ghcup-ci/-/jobs/1807133) reveals that Windows binary distributions are unserviceable, failing to find any of the boot packages during compilation due to all of the package registration files being empty:
```
Unpacking to acme-box-0.0.0.0\
+ cd acme-box-0.0.0.0/
+ ghc Setup.hs
[1 of 2] Compiling Main ( Setup.hs, Setup.o )
Setup.hs:1:1: error: [GHC-87110]
Could not find module `Prelude'.
Use -v to see a list of the files searched for.
|
1 | import Distribution.Simple
| ^
Setup.hs:1:1: error: [GHC-87110]
Could not find module `Distribution.Simple'.
Use -v to see a list of the files searched for.
|
1 | import Distribution.Simple
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
```https://gitlab.haskell.org/ghc/ghc/-/issues/24545GHC 9.10.1-alpha1 .tar.gz download does not extract properly2024-03-14T13:26:23ZRyan ScottGHC 9.10.1-alpha1 .tar.gz download does not extract properlyAfter downloading https://downloads.haskell.org/ghc/9.10.1-alpha1/ghc-9.10.0.20240313-x86_64-fedora33-linux.tar.gz, I attempted to extract it, only to be thwarted by this error:
```
$ tar -xvf ghc-9.10.0.20240313-x86_64-fedora33-linux.t...After downloading https://downloads.haskell.org/ghc/9.10.1-alpha1/ghc-9.10.0.20240313-x86_64-fedora33-linux.tar.gz, I attempted to extract it, only to be thwarted by this error:
```
$ tar -xvf ghc-9.10.0.20240313-x86_64-fedora33-linux.tar.gz
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Exiting with failure status due to previous errors
```
Curiously, this only affects the `.tar.gz` download, as the [`.tar.xz` version](https://downloads.haskell.org/ghc/9.10.1-alpha1/ghc-9.10.0.20240313-x86_64-fedora33-linux.tar.xz) extracts without issue. I haven't tried any other variants of GHC 9.10.1-alpha1.9.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/24546ghcup metadata gives incorrect dlSubdir of testsuite artifact2024-03-14T16:25:16ZBen Gamarighcup metadata gives incorrect dlSubdir of testsuite artifactAs noted in https://github.com/haskell/ghcup-metadata/pull/186#discussion_r1524064965, the `dlSubdir` of the testsuite artifact in the generated ghcup metadata is incorrect. It is listed as `dlSubdir: ghc-$ver` whereas it should be `dlSu...As noted in https://github.com/haskell/ghcup-metadata/pull/186#discussion_r1524064965, the `dlSubdir` of the testsuite artifact in the generated ghcup metadata is incorrect. It is listed as `dlSubdir: ghc-$ver` whereas it should be `dlSubdir: ghc-$ver/testsuite`.9.10.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24547ghcup metadata includes extraneous dlOutput fields2024-03-14T16:32:58ZBen Gamarighcup metadata includes extraneous dlOutput fieldsghcup can apparently infer the output name of an artifact from its URL.
Consequently, we should only include the `dlOutput` field when it would
differ from the filename of `dlUri`, as requested in https://github.com/haskell/ghcup-metadat...ghcup can apparently infer the output name of an artifact from its URL.
Consequently, we should only include the `dlOutput` field when it would
differ from the filename of `dlUri`, as requested in https://github.com/haskell/ghcup-metadata/pull/186/files#diff-b7aa200da91425001d95ee963dc2b97e33c87f584d916569c69fa20b49795887.Ben GamariBen Gamari