GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2022-06-17T09:05:28Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/21609Libdir does not contain include/ path when built with Hadrian2022-06-17T09:05:28ZAlexey RadkovLibdir does not contain include/ path when built with Hadrian## Summary
It seems that `$libdir` does not contain */include* path when GHC was built with Hadrian whereas the GHC docs says:
--print-libdir
Print the path to GHC’s library directory. This is the top of the directory tree ...## Summary
It seems that `$libdir` does not contain */include* path when GHC was built with Hadrian whereas the GHC docs says:
--print-libdir
Print the path to GHC’s library directory. This is the top of the directory tree containing GHC’s libraries,
interfaces, and include files (usually something like /usr/local/lib/ghc-5.04 on Unix).
This is the value of $libdir in the package configuration file (see Packages).
I relied on this when configuring a C project that included *HsFFI.h*.
See also https://bugzilla.redhat.com/show_bug.cgi?id=2083958
## Steps to reproduce
Downoad a tarball, say, https://downloads.haskell.org/ghc/9.4.1-alpha1/ghc-9.4.0.20220501-x86_64-fedora33-linux.tar.lz, install it and check that
```
ls $(ghc --print-libdir)
```
does nor contain *include/* - the path will be some levels up, actually.
## Expected behavior
I expect that `ghc --print-libdir` contains *include/HsFFI.h*
## Environment
* GHC version used: 9.4
Optional:
* Operating System:
* System Architecture:Make removalMatthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/21164hadrian bindist documentation directory structure differences2022-07-22T12:18:49ZMatthew Pickeringhadrian bindist documentation directory structure differencesThere are a few inconsistencies with the hadrian vs make bindists which I will document here and then we can decide if we do anything about them.
* hadrian puts docs in `docs` rather than `doc`.
* hadrian puts the pdf documentation in a...There are a few inconsistencies with the hadrian vs make bindists which I will document here and then we can decide if we do anything about them.
* hadrian puts docs in `docs` rather than `doc`.
* hadrian puts the pdf documentation in a `pdfs` folder but make puts the pdfs in the `doc` folder (one level up)
* hadrian calls the `Haddock` html documentation `Haddock`, which is consistent with the output name (as declared by `utils/haddock/doc/conf.py`) but make puts it in a folder called `haddock` (lower case).
At the moment in !7679 I modified `distrib/mkDocs/mkDocs` to just look in the right places in the hadrian bindist.Make removalBen GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/20898ci.sh tries `make binary-dist-prep` even when `make all` fails2022-02-24T13:53:20ZJoachim Breitnermail@joachim-breitner.deci.sh tries `make binary-dist-prep` even when `make all` failsOften when the validate jobs fail I don’t find the failure at the end, but have to scroll up past many lines of `tar` complaining about missing files and other things, often further than visible in the non-raw view, e.g. in https://gitla...Often when the validate jobs fail I don’t find the failure at the end, but have to scroll up past many lines of `tar` complaining about missing files and other things, often further than visible in the non-raw view, e.g. in https://gitlab.haskell.org/ghc/ghc/-/jobs/897731
The interesting lines seem to be
```
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
<<ghc: 152407984 bytes, 36 GCs, 11401801/30518944 avg/max bytes residency (5 samples), 59M in use, 0.000 INIT (0.000 elapsed), 0.122 MUT (0.121 elapsed), 0.209 GC (0.209 elapsed) :ghc>>
compiler/ghc.mk:242: recipe for target 'compiler/stage2/build/GHC/Types/Name/Occurrence.p_o' failed
make[1]: *** [compiler/stage2/build/GHC/Types/Name/Occurrence.p_o] Error 1
make[1]: *** Waiting for unfinished jobs....
<<ghc: 86967936 bytes, 21 GCs, 6151580/13110480 avg/max bytes residency (4 samples), 62M in use, 0.001 INIT (0.000 elapsed), 0.081 MUT (0.132 elapsed), 0.132 GC (0.132 elapsed) :ghc>>
make: *** [all] Error 2
Makefile:123: recipe for target 'all' failed
�[0;31mmake -j8 -Werror V=0 failed�[0m
�[1;34mRunning make -j8 binary-dist-prep TAR_COMP_OPTS=-1...�[0m
rm -f bindist-list
make --no-print-directory -f ghc.mk bindist-list BINDIST=YES
for f in LICENSE; do echo ghc-9.3.20220102/$f >> bindist-list; done
for f in README; do echo ghc-9.3.20220102/$f >> bindist-list; done
```
it seems that the `ci.sh` script tries `make -j8 binary-dist-prep TAR_COMP_OPTS=-1` even if `make -j8 -Werror V=0` failed.
The relevant lines seem to be
```sh
function build_make() {
prepare_build_mk
if [[ -z "$BIN_DIST_PREP_TAR_COMP" ]]; then
fail "BIN_DIST_PREP_TAR_COMP is not set"
fi
if [[ -n "${VERBOSE:-}" ]]; then
MAKE_ARGS="${MAKE_ARGS:-} V=1"
else
MAKE_ARGS="${MAKE_ARGS:-} V=0"
fi
run "$MAKE" -j"$cores" "$MAKE_ARGS"
run "$MAKE" -j"$cores" binary-dist-prep TAR_COMP_OPTS=-1
ls -lh "$BIN_DIST_PREP_TAR_COMP"
}
```
Is that intentional?Make removalZubinZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/20755hadrian: fix `test --test-compiler=stage1` (and making sure it stays that way)2022-04-12T11:35:43ZSebastian Grafhadrian: fix `test --test-compiler=stage1` (and making sure it stays that way)I want to run the testsuite with the stage1 compiler, because at the moment, the stage2 compiler on my branch crashes.
So I do
```
$ hadrian/build --flavour=validate test --test-compiler=stage1
...
Unknown program "_validate/stage0/bin...I want to run the testsuite with the stage1 compiler, because at the moment, the stage2 compiler on my branch crashes.
So I do
```
$ hadrian/build --flavour=validate test --test-compiler=stage1
...
Unknown program "_validate/stage0/bin/runghc"
Build failed.
```
which is worse than last time I tried, when I remembered getting an error at some later point (but still before running a single test). We should make sure that running the testsuite is possible even if the stage2 compiler is broken, perhaps by testing `hadrian/build test --test-compiler=stage1 --only=""` in CI.Make removalZubinZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/20657Hadrian: support cross-compilation to Windows2021-11-17T11:41:12ZSylvain HenryHadrian: support cross-compilation to WindowsHadrian should support cross-compilation to Windows.
## Steps to reproduce
```
./configure --target=x86_64-w64-mingw32
./hadrian/build
```
## Expected behavior
Don't fail.
## Environment
* GHC version used: HEAD
* Operating System:...Hadrian should support cross-compilation to Windows.
## Steps to reproduce
```
./configure --target=x86_64-w64-mingw32
./hadrian/build
```
## Expected behavior
Don't fail.
## Environment
* GHC version used: HEAD
* Operating System: Linux
* System Architecture: x86-64Make removalSylvain HenrySylvain Henryhttps://gitlab.haskell.org/ghc/ghc/-/issues/20579--with-system-ffi hadrian build fails with missing ffi.h2022-05-20T07:20:39ZJens Petersen--with-system-ffi hadrian build fails with missing ffi.h## Summary
Building with hadrian and --with-system-ffi together seems to fail with missing ffi.h in rts/ error.
## Steps to reproduce
```
./configure --with-system-ffi
hadrian
```
## Expected behavior
Success build
## Actual behavi...## Summary
Building with hadrian and --with-system-ffi together seems to fail with missing ffi.h in rts/ error.
## Steps to reproduce
```
./configure --with-system-ffi
hadrian
```
## Expected behavior
Success build
## Actual behavior
```
| Run Ghc CompileHs Stage0: utils/haddock/haddock-library/src/Documentation/Haddock/Markup.hs => _build/stage0/utils/haddock/build/Documentation/Haddock/Markup.o
/----------------------------------------------------------\
| Successfully built program 'ghc-bin' (Stage0). |
| Executable: _build/stage0/bin/ghc |
| Program synopsis: The Glorious Glasgow Haskell Compiler. |
\----------------------------------------------------------/
# cabal-configure (for _build/stage1/rts/setup-config)
# cabal-autogen (for _build/stage1/rts/build/autogen/cabal_macros.h)
Error when running Shake build system:
at action, called at src/Rules.hs:40:19 in main:Rules
at need, called at src/Rules.hs:62:5 in main:Rules
* Depends on: _build/stage1/lib/package.conf.d/ghc-prim-0.8.0.conf
at apply1, called at src/Development/Shake/Internal/Rules/Oracle.hs:159:32 in shake-0.19.5-9pWeYQRoaoQ5ifRBjCBmLp:Development.Shake.Internal.Rules.Oracle
* Depends on: OracleQ (ContextDataKey (Context {stage = Stage1, package = Package {pkgType = Library, pkgName = "ghc-prim", pkgPath = "libraries/ghc-prim"}, way = v}))
at need, called at src/Hadrian/Oracles/Cabal/Rules.hs:54:9 in main:Hadrian.Oracles.Cabal.Rules
* Depends on: _build/stage1/libraries/ghc-prim/setup-config
at need, called at src/Rules/Library.hs:164:18 in main:Rules.Library
* Depends on: _build/stage1/rts/build/ffi.h
at &%>, called at src/Rules/Rts.hs:29:9 in main:Rules.Rts
* Depends on: _build/stage1/rts/build/ffi.h _build/stage1/rts/build/ffitarget.h
at need, called at src/Hadrian/Utilities.hs:319:5 in main:Hadrian.Utilities
* Depends on: ffi.h
at error, called at src/Development/Shake/Internal/Rules/File.hs:179:58 in shake-0.19.5-9pWeYQRoaoQ5ifRBjCBmLp:Development.Shake.Internal.Rules.File
* Raised the exception:
Error, file does not exist and no rule available:
ffi.h
```
Same result [without](https://koji.fedoraproject.org/koji/taskinfo?taskID=78035391) and
[with](https://koji.fedoraproject.org/koji/taskinfo?taskID=78036653) `libffi-tarballs/`.
(These logs will expire after 2 weeks.)
## Environment
* GHC version used: ghc-8.10.5 to build 9.2.1
* Operating System: Fedora Linux
* System Architecture: x86_64Make removalBen GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/20576Hadrian's C dependency file rules are nonsense2021-10-29T18:34:58ZBen GamariHadrian's C dependency file rules are nonsenseHadrian's dependency file rules for C files appears to be utter nonsense, which breaks some newer C compilers. Specifically,
```
| Run Cc FindCDependencies Stage0: utils/unlit/fs.c => _build/stage0/utils/unlit/build/c/fs.o.d
gcc: warning...Hadrian's dependency file rules for C files appears to be utter nonsense, which breaks some newer C compilers. Specifically,
```
| Run Cc FindCDependencies Stage0: utils/unlit/fs.c => _build/stage0/utils/unlit/build/c/fs.o.d
gcc: warning: c: linker input file unused because linking not done
gcc: error: c: linker input file not found: No such file or directory
<command line>: does not exist: /tmp/2848417-92.c
Error when running Shake build system:
at action, called at src/Rules.hs:40:19 in main:Rules
at need, called at src/Rules.hs:62:5 in main:Rules
* Depends on: _build/stage0/lib/bin/unlit
at need, called at src/Rules/Program.hs:125:5 in main:Rules.Program
* Depends on: _build/stage0/utils/unlit/build/c/fs.o
at cmd', called at src/Builder.hs:322:23 in main:Builder
at cmd, called at src/Builder.hs:424:8 in main:Builder
* Raised the exception:
Development.Shake.cmd, system command failed
Command line: /usr/bin/gcc -E -MM -MG -MF _build/stage0/utils/unlit/build/c/fs.o.d -MT _build/stage0/utils/unlit/build/c/fs.o -I_build/stage0/lib -I_build/stage0/utils/unlit/build -I -x c utils/unlit/fs.c
Exit code: 1
```
Notice that in the command line we are passing the path of an object file despite the fact that we are invoking `gcc` in `-M` mode. GCC is quite right to complain about this.Make removalhttps://gitlab.haskell.org/ghc/ghc/-/issues/20267Binary distribution generation for cross-compilers is broken2022-07-21T22:11:15ZBen GamariBinary distribution generation for cross-compilers is brokenIt appears that attempting to build a cross-compiler binary distribution with Hadrian is currently broken (e.g. see https://gitlab.haskell.org/ghc/ghc/-/jobs/768787):
```
...
| Copy directory: _build/stage1/lib/aarch64-linux-ghc-9.3.202...It appears that attempting to build a cross-compiler binary distribution with Hadrian is currently broken (e.g. see https://gitlab.haskell.org/ghc/ghc/-/jobs/768787):
```
...
| Copy directory: _build/stage1/lib/aarch64-linux-ghc-9.3.20210819/rts-1.0.2/include => _build/bindist/ghc-9.3.20210819-aarch64-linux-gnu
# ghc-pkg (for binary-dist-dir)
Error when running Shake build system:
at want, called at src/Main.hs:104:30 in main:Main
* Depends on: binary-dist
at apply1, called at src/Development/Shake/Internal/Rules/Rerun.hs:41:5 in shake-0.19.4-20c6545ab58e09240e1fa246d8fa870a38f1b3f44de1e37fd2fd5ff0f6f94849:Development.Shake.Internal.Rules.Rerun
* Depends on: binary-dist-dir
* Raised the exception:
_build/bindist/ghc-9.3.20210819-aarch64-linux-gnu/bin/ghc-pkg: createProcess: runInteractiveProcess: exec: does not exist (No such file or directory)
hadrian/build-cabal --flavour=validate -j5 --broken-test= --bignum=gmp binary-dist failed
```Make removalhttps://gitlab.haskell.org/ghc/ghc/-/issues/20178make is too eager to rebuild2022-05-23T11:11:34ZKrzysztof Gogolewskimake is too eager to rebuildIf I `make` twice in a row, the second invocation should be doing nothing or little work. In master, I'm getting
```
===--- building phase 0
make --no-print-directory -f ghc.mk phase=0 phase_0_builds
make[1]: Nothing to be done for 'pha...If I `make` twice in a row, the second invocation should be doing nothing or little work. In master, I'm getting
```
===--- building phase 0
make --no-print-directory -f ghc.mk phase=0 phase_0_builds
make[1]: Nothing to be done for 'phase_0_builds'.
===--- building phase 1
make --no-print-directory -f ghc.mk phase=1 phase_1_builds
make[1]: Nothing to be done for 'phase_1_builds'.
===--- building final phase
make --no-print-directory -f ghc.mk phase=final all
"inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -this-unit-id base-4.16.0.0 -hide-all-packages -package-env - -i -ilibraries/base/. -ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/./autogen -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include -Ilibraries/base/dist-install/build/include -optP-include -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h -package-id ghc-bignum-1.2 -package-id ghc-prim-0.8.0 -package-id rts -this-unit-id base -Wcompat -Wnoncanonical-monad-instances -XHaskell2010 -O -dcore-lint -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -outputdir libraries/base/dist-install/build -dynamic-too -c libraries/base/./GHC/Num.hs -o libraries/base/dist-install/build/GHC/Num.o -dyno libraries/base/dist-install/build/GHC/Num.dyn_o
compilation IS NOT required
"inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -this-unit-id base-4.16.0.0 -hide-all-packages -package-env - -i -ilibraries/base/. -ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/./autogen -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include -Ilibraries/base/dist-install/build/include -optP-include -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h -package-id ghc-bignum-1.2 -package-id ghc-prim-0.8.0 -package-id rts -this-unit-id base -Wcompat -Wnoncanonical-monad-instances -XHaskell2010 -O -dcore-lint -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -outputdir libraries/base/dist-install/build -dynamic-too -c libraries/base/./Data/Maybe.hs -o libraries/base/dist-install/build/Data/Maybe.o -dyno libraries/base/dist-install/build/Data/Maybe.dyn_o
compilation IS NOT required
```
and that goes on for a few hundred files. Until recently, this was not the case and I just saw "Nothing to be done".Make removalhttps://gitlab.haskell.org/ghc/ghc/-/issues/19963Non-portable realpath option in hadrian bindist Makefile2022-01-31T02:55:51ZvdukhovniNon-portable realpath option in hadrian bindist MakefileCommit 04b4b98447c36a2d28fffe819c97c32b591479ee added `hadrian/bindist/Makefile` in which one of the rules uses `realpath` with a Linux-specific option:
```
PKG_CONFS = $(shell find "$(ActualLibsDir)/package.conf.d" -name '*.conf' | sed ...Commit 04b4b98447c36a2d28fffe819c97c32b591479ee added `hadrian/bindist/Makefile` in which one of the rules uses `realpath` with a Linux-specific option:
```
PKG_CONFS = $(shell find "$(ActualLibsDir)/package.conf.d" -name '*.conf' | sed 's: :xxx:g')
update_package_db: install_bin install_lib
@echo "$(PKG_CONFS)"
@echo "Updating the package DB"
$(foreach p, $(PKG_CONFS),\
$(call patchpackageconf,$(shell echo $(notdir $p) | sed 's/-\([0-9]*[0-9]\.\)*conf//g'),$(shell echo "$p" | sed 's:xxx: :g'),$(docdir),$(shell realpath --relative-to="$(libdir)" "$(docdir)")))
'$(WrapperBinsDir)/ghc-pkg' recache
```
The `--relative-to` option is not portable. I'm not sure what this code is trying to do, and so not clear whether the use of `realpath` here is merely cosmetic, or actually important...Make removalBen GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/19868Hadrian Windows binary distributions include configure script2021-10-12T06:43:31ZBen GamariHadrian Windows binary distributions include configure scriptUnder the `make` build system Windows binary distributions do not include a installation `configure` script, `Makefile`, or associated paraphenalia. However, it appears that Hadrian's bindist rules treat Windows binary distributions the ...Under the `make` build system Windows binary distributions do not include a installation `configure` script, `Makefile`, or associated paraphenalia. However, it appears that Hadrian's bindist rules treat Windows binary distributions the same way they treat POSIX bindists. Consequently we end up including the `configure` script and `Makefile`, which are unnecessary on Windows.Make removalMatthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/19646Bootstrap of ghc doesn’t do DESTDIR correctly, propagates build dir2022-05-30T17:12:26ZSteve SmithBootstrap of ghc doesn’t do DESTDIR correctly, propagates build dir## Summary
The bootstrap of ghc doesn’t do `DESTDIR` correctly, embeds the build directory into the `ghc` binary, and propagates the build directory to binaries built using bootstrapped ghc.
This is embedded in the `ghc` binary in seve...## Summary
The bootstrap of ghc doesn’t do `DESTDIR` correctly, embeds the build directory into the `ghc` binary, and propagates the build directory to binaries built using bootstrapped ghc.
This is embedded in the `ghc` binary in several places:
> `vi /opt/local/lib/ghc-8.10.4/bin/ghc`
```
^@/opt/local/var/macports/build/_opt_local_ports_lang_ghc/ghc/work/src/ghc-8.10.4/rts/dist/build^@
```
Also:
```bash
fgrep "/opt/local/var/macports/build" /opt/local/lib/ghc-8.10.4/bin/ghc
Binary file /opt/local/lib/ghc-8.10.4/bin/ghc matches
```
Looking at binaries built with this bootstrapped `ghc` shows that the issue propagates.
Here is the binary for `pandoc`, built using `cabal` 3.4.0.0 and this `ghc-8.10.4` binary:
```bash
fgrep "/opt/local/var/macports/build/_opt_local_ports_lang_ghc/ghc/work/src/ghc-8.10.4/rts" /opt/local/bin/pandoc
Binary file /opt/local/bin/pandoc matches
```
## Steps to reproduce
The [Portfile](https://github.com/macports/macports-ports/blob/master/lang/ghc/Portfile) simply implements ghc's basic quick start build instructions.
## Expected behavior
No build directories in the `ghc` binary, or binaries built using it.
## Environment
* GHC version used: 8.10.4
Optional:
* Operating System: macOSMake removalhttps://gitlab.haskell.org/ghc/ghc/-/issues/19485Executables in binary distributions produced by Hadrian contain the build dir...2021-12-17T13:35:24ZBen GamariExecutables in binary distributions produced by Hadrian contain the build directory in RPATHWhile working on bgamari/ghcs.nix>, I found that `nix` failed its output linting phase due to RPATH entries referring to the build directory:
```
patching script interpreter paths in /nix/store/djrafmmk6lr8yr58zw7d19bikav05w1z-ghc-9.0....While working on bgamari/ghcs.nix>, I found that `nix` failed its output linting phase due to RPATH entries referring to the build directory:
```
patching script interpreter paths in /nix/store/djrafmmk6lr8yr58zw7d19bikav05w1z-ghc-9.0.1
checking for references to /build/ in /nix/store/djrafmmk6lr8yr58zw7d19bikav05w1z-ghc-9.0.1...
RPATH of binary /nix/store/djrafmmk6lr8yr58zw7d19bikav05w1z-ghc-9.0.1/lib/ghc-9.0.1/bin/ghc contains a forbidden reference to /build/
builder for '/nix/store/lfxcz00hp0rslmz2x48kgc6s30g7qx10-ghc-9.0.1.drv' failed with exit code 1
```
Examining Hadrian's output from a local build tree confirms this:
```
$ objdump -x _build/stage1/bin/ghc | grep RUNPATH
RUNPATH /opt/exp/ghc/ghc-landing/_build/stage1/lib/../lib/x86_64-linux-ghc-9.1.20210303:/nix/store/pk73wc0x32y2bmbiqiddb084w398ab6y-ncurses-6.2/lib:/nix/store/fphpbj8jpyibz0l2xspidg6s7zm7xyb5-gmp-6.2.0/lib:/nix/store/35v0m2ih9q4x3crhxiyr3pxc8ckn73gi-elfutils-0.180/lib:/nix/store/saghih5p46g1nm8vmvxc5vw5pfj1nc79-numactl-2.0.13/lib:$ORIGIN/../lib/x86_64-linux-ghc-9.1.20210303:$ORIGIN/../../../lib/x86_64-linux-ghc-9.1.20210303:/nix/store/ykig055slngj7raqgdqsg0d94bbyhyrk-ghc-shell-for-ghc-buildenv-9.2-0/lib64:/nix/store/ykig055slngj7raqgdqsg0d94bbyhyrk-ghc-shell-for-ghc-buildenv-9.2-0/lib:/nix/store/s0mblhs5vmjza9dmipn74rwqflxy1fw7-libffi-3.3/lib:/nix/store/9df65igwjmf2wbw0gbrrgair6piqjgmi-glibc-2.31/lib:/nix/store/vran8acwir59772hj4vscr7zribvp7l5-gcc-9.3.0-lib/lib
```
By contrast, if we look at the same executable from the `make` build system we see that `RUNPATH` is relative to `$ORIGIN`:
```
RUNPATH $ORIGIN/../haskeline-0.8.1.0:$ORIGIN/../ghc-9.0.0.20201227:$ORIGIN/../terminfo-0.4.1.4:$ORIGIN/../process-1.6.10.0:$ORIGIN/../hpc-0.6.1.0:$ORIGIN/../ghci-9.0.0.20201227:$ORIGIN/../ghc-heap-9.0.0.20201227:$ORIGIN/../ghc-boot-9.0.0.20201227:$ORIGIN/../exceptions-0.10.4:$ORIGIN/../template-haskell-2.17.0.0:$ORIGIN/../pretty-1.1.3.6:$ORIGIN/../ghc-boot-th-9.0.0.20201227:$ORIGIN/../stm-2.5.0.0:$ORIGIN/../mtl-2.2.2:$ORIGIN/../transformers-0.5.6.2:$ORIGIN/../directory-1.3.6.1:$ORIGIN/../unix-2.7.2.2:$ORIGIN/../time-1.9.3:$ORIGIN/../filepath-1.4.2.1:$ORIGIN/../binary-0.8.8.0:$ORIGIN/../containers-0.6.2.1:$ORIGIN/../bytestring-0.10.12.0:$ORIGIN/../deepseq-1.4.4.0:$ORIGIN/../array-0.5.4.0:$ORIGIN/../base-4.15.0.0:$ORIGIN/../ghc-bignum-1.0:$ORIGIN/../ghc-prim-0.7.0:$ORIGIN/../rts
```Make removalhttps://gitlab.haskell.org/ghc/ghc/-/issues/19339Hadrian doesn't produce ghcii.sh2021-10-19T20:10:53ZBen GamariHadrian doesn't produce ghcii.shOn Windows the `make` build system produces a wrapper script, `ghcii.sh`, which is necessary due to signal handling silliness. Currently `hadrian` does not produce this file. See https://github.com/ghc/ghc/blob/e393f213f5ccff4fd6034d5294...On Windows the `make` build system produces a wrapper script, `ghcii.sh`, which is necessary due to signal handling silliness. Currently `hadrian` does not produce this file. See https://github.com/ghc/ghc/blob/e393f213f5ccff4fd6034d5294e51aa5a2720890/driver/ghci/ghc.mk#L54.Make removalBen GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/19317Hadrian source distributions are incomplete2022-05-25T11:01:09ZBen GamariHadrian source distributions are incompleteHadrian's source distribution target fails to produce the `-testsuite` and `-extra-tarballs` tarballs. It appears that they are currently completely unimplemented.Hadrian's source distribution target fails to produce the `-testsuite` and `-extra-tarballs` tarballs. It appears that they are currently completely unimplemented.Make removalZubinZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/18788Hadrian 'install' requires built docs (regression in comparison with make bui...2022-05-23T10:43:31ZkgardasHadrian 'install' requires built docs (regression in comparison with make build system)## Summary
It looks like hadrian/build install requires docs to be built. Old make build system is not that strict and allows to execute make install even without documentation built.
## Expected behavior
This really depends GHC devel...## Summary
It looks like hadrian/build install requires docs to be built. Old make build system is not that strict and allows to execute make install even without documentation built.
## Expected behavior
This really depends GHC developers, I'm submitting this just for the record.
## Environment
8.10.1 as a bootstrap GHC. Building GHC head as of Oct 1 2020.
Optional:
* Operating System: Ubuntu 18.04 LTS
* System Architecture: AMD64Make removalhttps://gitlab.haskell.org/ghc/ghc/-/issues/18734Hadrian bindists assume existence of ld.lld2022-02-24T15:15:15ZBen GamariHadrian bindists assume existence of ld.lld@RyanGlScott reports that the `validate-x86_64-linux-deb9-hadrian` artifact bindists assume the existence of ld.lld. Need to investigate.
The problem here appears to be that the `settings` file is not regenerated.@RyanGlScott reports that the `validate-x86_64-linux-deb9-hadrian` artifact bindists assume the existence of ld.lld. Need to investigate.
The problem here appears to be that the `settings` file is not regenerated.Make removalBen GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/18679Hadrian `test` falls apart when LANG / LC_ALL are not set correctly.2022-06-07T15:08:34ZMoritz AngermannHadrian `test` falls apart when LANG / LC_ALL are not set correctly.When running
```
$ hadrian/build test
```
and the test produces non ascii characters, as in
```
Converter.hs:113:35: error:
Ambiguous occurrence ‘yield’
It could refer to
either ‘GHC.Data.Stream.yield’,
impor...When running
```
$ hadrian/build test
```
and the test produces non ascii characters, as in
```
Converter.hs:113:35: error:
Ambiguous occurrence ‘yield’
It could refer to
either ‘GHC.Data.Stream.yield’,
imported from ‘GHC.Data.Stream’ at Converter.hs:4:1-22
or ‘Control.Concurrent.yield’,
imported from ‘Control.Concurrent’ at Converter.hs:6:1-25
(and originally defined in ‘GHC.Conc.Sync’)
```
hadrian will fail with:
```
=====> concprog001(threaded2) 1 of 1 [0, 0, 0]
cd "/run/user/1001/ghctest-be7ny599/test spaces/testsuite/tests/concurrent/prog001/concprog001.run" && "/home/angerman/Projects/ghc/_build/stage1/bin/ghc" --make -o concprog001 Mult -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 -O -threaded -eventlog -package ghc<
Compile failed (exit code 1) errors were:
[1 of 6] Compiling Converter ( Converter.hs, Converter.o )
Converter.hs:113:35: error:
Error when running Shake build system:
at want, called at src/Main.hs:102:30 in main:Main
* Depends on: test
* Raised the exception:
fd:141: hGetLine: invalid argument (invalid byte sequence)
```Make removalBen GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/18672Hadrian inexplicably rebuilds when output is redirected2020-09-10T15:03:22ZBen GamariHadrian inexplicably rebuilds when output is redirectedHadrian somehow includes knowledge of whether stdout/stderr are a terminal or not in its recompilation check. For instance,
```
$ hadrian/build-cabal -j9
[build proceeds, finishes]
$ hadrian/build-cabal -j9 >& log
[build starts afres...Hadrian somehow includes knowledge of whether stdout/stderr are a terminal or not in its recompilation check. For instance,
```
$ hadrian/build-cabal -j9
[build proceeds, finishes]
$ hadrian/build-cabal -j9 >& log
[build starts afresh, finishes]
$ hadrian/build-cabal -j9
[build yet again starts afresh, finishes]
```
This is a rather serious issue as it makes debugging *extremely* painful.Make removalBen GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/18669Fix Haddock documentation in Hadrian Windows build2020-12-23T07:30:21ZBen GamariFix Haddock documentation in Hadrian Windows buildI have recently switched our bindist builds on Windows to Hadrian (as `make` is incredibly flaky currently on Windows) but found that Haddock documentation is not packaged in the binary distribution. I haven't confirmed whether this is a...I have recently switched our bindist builds on Windows to Hadrian (as `make` is incredibly flaky currently on Windows) but found that Haddock documentation is not packaged in the binary distribution. I haven't confirmed whether this is also the case on Linux.
Regardless, this is something that will need to be fixed before %9.0.1.Make removalBen GamariBen Gamari