GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-02-29T12:00:43Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/24431Cross-compiling seems to not pass CC through2024-02-29T12:00:43ZGreg SteuckCross-compiling seems to not pass CC throughI'm having trouble trying to bootstrap OpenBSD-aarch64 from OpenBSD-amd64. I do have a working cross-toolchain (courtesy of LLVM) but it looks like the plumbing in hadrian is not fully laid. At least, when running with
```
export MAKE=gm...I'm having trouble trying to bootstrap OpenBSD-aarch64 from OpenBSD-amd64. I do have a working cross-toolchain (courtesy of LLVM) but it looks like the plumbing in hadrian is not fully laid. At least, when running with
```
export MAKE=gmake \
AUTOCONF_VERSION=2.71 \
AUTOMAKE_VERSION=1.16 \
CC=/usr/local/bin/clang-13 \
LD=/usr/local/bin/ld.lld-13 \
NM=/usr/local/bin/llvm-nm-13 \
OBJDUMP=/usr/local/bin/llvm-objdump-13
./boot
./configure --target=aarch64-none-openbsd --with-cc=/usr/local/bin/clang-13
hadrian/build '*.*.ghc.link.opts+=-L/usr/local/lib' \
--docs=none \
--flavour=quickest \
-j stage1:exe:ghc-bin
```
I see the main configure succeed, but stage0 is already going off the rails when trying to configure the time library which shows in its config.log:
```
$ //home/greg/s/ghc/libraries/time/configure --with-compiler=ghc
'--prefix=${pkgroot}/..' 'CFLAGS=-Qunused-arguments -iquote
/home/greg/s/ghc/libraries/time -Qunused-arguments'
LDFLAGS=--target=aarch64-none-openbsd --host=aarch64-none-openbsd
--with-cc=clang CC=/usr/bin/clang
```
Which clearly mixed up the uses target value for host whereas the compiler is the one for host. This compiler promptly reports:
```
error: unable to create target: 'No available targets are compatible with triple "aarch64-none-openbsd"'
```
because it doesn't have support for aarch64. In fact, it's unclear, where `/usr/bin/clang` even came from. My `configure` command above didn't point at it. Moreover, top level config.log doesn't mention it.
If there's better cross-compilation documentation to follow than https://gitlab.haskell.org/ghc/ghc/-/wikis/building/cross-compiling, I'd love to read that.
Attaching the top level [config.log](/uploads/23b8a2e89089c4b0cc61c7709a59ce82/config.log)
and[time-config.log](/uploads/4f834f246cf60f0d3c1fe38f4d097703/time-config.log).Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/24385Bootstrapping GHC via c2024-02-12T08:09:31ZJames HobsonBootstrapping GHC via cHello! This feature is purely about Hadrian and so shouldn't be too controversial
## Motivation
Bringing GHC up on a new platform has gotten much easier as time has gone on, but this is assuming that you have a cross toolchain. But the...Hello! This feature is purely about Hadrian and so shouldn't be too controversial
## Motivation
Bringing GHC up on a new platform has gotten much easier as time has gone on, but this is assuming that you have a cross toolchain. But there are still a few scenarios where this is not an assumption that we can make.
1. If we are bootstrapping GHC in order to package it
2. If we want GHC to run on a platform without a cross toolchain (In my case, Plan9)
In both of these cases, a solution that comes to mind would be to bring back the old method. Configuring an unregistered build of the compiler, compiling with `-fvia-c` and `-keep-hc` (or something to that effect), copying over to the target system, and letting the c compiler finish the job.
I propose bring this option back (maybe even with some new features) so that GHC can be enjoyed on more fringe platforms than ever before!
## Proposal
1. Add the ability for Hadrian to compile GHC to hc files and generate make files. Maybe even just generate a folder with all this in like it does with the binary dist.
2. (Optionally) use rsync/ssh to automate the configuring of the compiler
3. (Optionally) use rsync/ssh to finish the build on the target platformhttps://gitlab.haskell.org/ghc/ghc/-/issues/24339Add support for executing TH splices on the host platform during cross compil...2024-01-17T11:51:08ZAndreas KlebingerAdd support for executing TH splices on the host platform during cross compilation.## Summary
Currently when using TH we require any splices to be executed on the target platform.
While this simplifies things for GHC in a lot of ways it can make building for different platforms difficult as it requires
either access...## Summary
Currently when using TH we require any splices to be executed on the target platform.
While this simplifies things for GHC in a lot of ways it can make building for different platforms difficult as it requires
either access to target platform hardware or simulation thereof.
I believe for most uses of TH it is possible (although not straight forward) to lift this restriction.
## Ideal workflow for the feature.
Here is how I imagine this could work if I could simply snap my fingers to make it happen:
* GHC would support targeting different platforms at runtime.
* When cross-compiling a project that uses TH we would pass to the build tool both the target platform and `-fsplices-on-host`.
* The build tool compiles all dependencies first for the host (potentially only to bytecode) as one would do today.
* Then GHC is invoked with a cross platform target, passing `-fsplices-on-host`. This would result in splices being executed on the host using the libraries built in the second step.
## Current roadblocks
### Libraries need to be available for both target *and* host platform.
In order to run TH splices on the host all the dependencies of the splice need to be available.
With build tool support this could be achieved on top of https://gitlab.haskell.org/ghc/ghc/-/issues/11470 / https://gitlab.haskell.org/ghc/ghc/-/issues/23682
In practice this would mean compiling most code twice, obviously once for the target platform, but also once
to ensure the dependencies are available for the splices.
### Splices which give different results for different platforms.
Code which relies on things like Int bit-width or other platform dependent behavior can give different results for different platforms. This makes running on the host by default very dangerous as it might introduce subtle breakage.
I believe it's acceptable to allow users to opt-into executing splices on the host implicitly accepting such breakage by doing so.
A more extreme approach would be to define a virtual TH target platform which can be emulated independent of the actual host platform. This would mean TH splices would give the same results independent of the host they are run on.
One example of such an approach in a different project is the External STG Interpreter project, which implemented semantics for most of GHCs primops.https://gitlab.haskell.org/ghc/ghc/-/issues/24289Enable documentation building in cross bindists2024-03-20T10:46:50ZMatthew PickeringEnable documentation building in cross bindistsThere appears to be no inherent reason why we can't build documentation in a cross bindists. The hadrian rules currently bake in some incorrect assumptions about stages of libraries we should generate documentation for but these rules ca...There appears to be no inherent reason why we can't build documentation in a cross bindists. The hadrian rules currently bake in some incorrect assumptions about stages of libraries we should generate documentation for but these rules can probably be generalised to allow documentation to be produced for cross bindists.https://gitlab.haskell.org/ghc/ghc/-/issues/23983Broken aarch64 cross-compiler with Hadrian2023-10-05T16:44:14ZGeorge ThomasBroken aarch64 cross-compiler with HadrianI have previously successfully built a Linux x86_64 to aarch64 cross-compiling GHC using:
```sh
echo '
V=0
BUILD_MAN = NO
BUILD_SPHINX_HTML = NO
BUILD_SPHINX_PDF = NO
HADDOCK_DOCS = NO
Stage1Only = YES
BuildFlavour = quick
WITH_TERMINFO...I have previously successfully built a Linux x86_64 to aarch64 cross-compiling GHC using:
```sh
echo '
V=0
BUILD_MAN = NO
BUILD_SPHINX_HTML = NO
BUILD_SPHINX_PDF = NO
HADDOCK_DOCS = NO
Stage1Only = YES
BuildFlavour = quick
WITH_TERMINFO = NO
BIGNUM_BACKEND = native
' > build.mk
ghcup compile ghc -v 9.2.7 -b 9.0.2 -x aarch64-none-linux-gnu -c $(pwd)/build.mk
```
Where my cross toolchain comes from [this package](https://aur.archlinux.org/packages/aarch64-none-linux-gnu-gcc-9.2-bin), which wraps a binary release direct from ARM themselves.
I'm trying to migrate this to Hadrian now that it's the only option for newer GHCs:
```sh
ghcup compile ghc --hadrian -v 9.6.2 -b 9.6.2 -x aarch64-none-linux-gnu -j $(nproc) --flavour=quick+native_bignum
```
This builds a compiler which, when run on even a trivial program, generates hundreds of errors like:
```
...
Error: expecting operand after ','; got nothing
Error: no such instruction: `b stg_ap_p_fast'
Error: no such instruction: `ldr x18,[ sp,64]'
Error: no such instruction: `ldr x18,[ x18]'
Error: no such instruction: `br x18'
Error: operand size mismatch for `mov'
Error: no such instruction: `ldr x18,[ x19,-16]'
Error: no such instruction: `br x18'
```
Something is clearly _very_ broken. It looks rather like we're trying to run the wrong kind of assembly for the host platform. So I suspected that perhaps what had been built was a stage 2 compiler, with host=aarch64, especially given that my Hadrian command above is missing any equivalent to `Stage1Only = YES` from the Make version. But `aarch64-none-linux-gnu-ghc --print-stage` does output `1`.
If it isn't clear what's going on here, I can go and work out how to invoke Hadrian directly, rather than via GHCUP (this was not obvious, not least because the [cross-compilation wiki page](https://gitlab.haskell.org/ghc/ghc/-/wikis/building/cross-compiling) doesn't even mention Hadrian). It is possible that this is actually a bug in GHCUP. I can also try to avoid the mismatched GHC versions, though I did have unrelated issues getting older GHCs to even build with Hadrian.Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/23975Cross-compilation broken since 9.4.x2023-10-05T17:41:35ZglaubitzCross-compilation broken since 9.4.xIt's no longer possible to cross-compile GHC for a new platform.
Cross-compiling for 32-bit PowerPC fails with:
```
"inplace/bin/ghc-stage1" -static -optc-DTHREADED_RTS -H32m -O -lffi -optl-pthread -O0 -H64m -Wall -this-unit-id rts -...It's no longer possible to cross-compile GHC for a new platform.
Cross-compiling for 32-bit PowerPC fails with:
```
"inplace/bin/ghc-stage1" -static -optc-DTHREADED_RTS -H32m -O -lffi -optl-pthread -O0 -H64m -Wall -this-unit-id rts -optc-DNOSMP -dcmm-lint -package-env - -i -irts -irts/dist-install/
build -Irts/dist-install/build -irts/dist-install/build/./autogen -Irts/dist-install/build/./autogen -Irts/include/../dist-install/build/include -Irts/include/. -Irts/. -optP-DCOMPILING_RTS
-optP-DFS_NAMESPACE=rts -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/dist-install/build/AutoApply.cmm -o rts/dist-install/build/AutoApply.thr_o
"inplace/bin/ghc-stage1" -static -optc-DTHREADED_RTS -optc-DDEBUG -H32m -O -lffi -optl-pthread -O0 -H64m -Wall -this-unit-id rts -optc-DNOSMP -dcmm-lint -package-env - -i -irts -irts/
dist-install/build -Irts/dist-install/build -irts/dist-install/build/./autogen -Irts/dist-install/build/./autogen -Irts/include/../dist-install/build/include -Irts/include/. -Irts/. -optP-D
COMPILING_RTS -optP-DFS_NAMESPACE=rts -O2 -Wcpp-undef -O0 -Wnoncanonical-monad-instances -c rts/dist-install/build/AutoApply.cmm -o rts/dist-install/build/AutoApply.thr_debug_o
powerpc-linux-gnu-ld: skipping incompatible /tmp/ghc32924_0/ghc_10.o when searching for /tmp/ghc32924_0/ghc_10.o
powerpc-linux-gnu-ld: cannot find /tmp/ghc32924_0/ghc_10.o: file in wrong format
powerpc-linux-gnu-ld: skipping incompatible /tmp/ghc32924_0/ghc_10.o when searching for /tmp/ghc32924_0/ghc_10.o
powerpc-linux-gnu-ld: skipping incompatible /tmp/ghc32924_0/ghc_7.p_o when searching for /tmp/ghc32924_0/ghc_7.p_o
powerpc-linux-gnu-ld: cannot find /tmp/ghc32924_0/ghc_7.p_o: file in wrong format
powerpc-linux-gnu-ld: skipping incompatible /tmp/ghc32924_0/ghc_7.p_o when searching for /tmp/ghc32924_0/ghc_7.p_o
`powerpc-linux-gnu-ld' failed in phase `Merge objects'. (Exit code: 1)
```https://gitlab.haskell.org/ghc/ghc/-/issues/23957Segfault in RISC-V programs built by a registerised GHC2023-11-04T12:37:04ZAlex TunstallSegfault in RISC-V programs built by a registerised GHC## Summary
Most interesting programs segfault when compiled by a registerised GHC.
This also includes GHC itself when compiling non-trivial programs.
I have tried cross-compiling GHC 9.2.7, 9.4.5, and 9.6.2, but none of them worked.
I ...## Summary
Most interesting programs segfault when compiled by a registerised GHC.
This also includes GHC itself when compiling non-trivial programs.
I have tried cross-compiling GHC 9.2.7, 9.4.5, and 9.6.2, but none of them worked.
I have also tried natively compiling GHC 9.6.2 using an unregisterised cross-compiled 9.4.5, but that didn't work either.
## Steps to reproduce
Using Nix:
```sh
nix-build -p 'pkgsCross.riscv64.haskell.compiler.native-bignum.ghc945' -I nixpkgs=https://github.com/AlexandreTunstall/nixpkgs/archive/40f2e8f3abc55ff292cc3328ff22d4159893ad20.tar.gz
```
Then try using the resulting GHC to compile pandoc (this may require binfmt emulation or a RISC-V system).
***
Without Nix:
1. Compile one of the affected versions registerised for RISC-V (both cross and native should reproduce this issue)
2. Try using the stage 2 compiler to compile non-trivial software (e.g. pandoc).
I might not have tested native compilation properly, but it can definitely be reproduced with cross.
## Expected behavior
pandoc compiles successfully; this is the case with unregisterised GHC.
## Observed behavior
A segmentation fault with no additional details at some early stage of compiling pandoc.
## Environment
* GHC version used: 9.2.7, 9.4.5, and 9.6.2
Optional:
* Operating System: Linux
* System Architecture: RV64GC (cross) and RV64GC_Zba_Zbb (native)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/23838Allow a BUILD different from HOST2023-09-14T09:04:39ZRodrigo MesquitaAllow a BUILD different from HOSTCurrently, we require that the system building the compiler (BUILD) is the same system running the compiler (HOST), but allow the target of the compiler (TARGET) to be different from the BUILD/HOST.
* Why do we have this limitation in p...Currently, we require that the system building the compiler (BUILD) is the same system running the compiler (HOST), but allow the target of the compiler (TARGET) to be different from the BUILD/HOST.
* Why do we have this limitation in place?
* What do we need to do to lift it?
With the recent advances in the staged build configuration (namely, the `ghc-toolchain` `Target` files) lifting this restriction is likely simpler now.https://gitlab.haskell.org/ghc/ghc/-/issues/23245CROSS_EMULATOR convention needs proper documentation2023-06-09T09:44:51ZCheng ShaoCROSS_EMULATOR convention needs proper documentation!9515 landed preliminary support for using a cross emulator to run target executables when testing a cross GHC. However, it's completely undocumented, and some questions needs more thinking:
- `CROSS_EMULATOR` is currently just an envir...!9515 landed preliminary support for using a cross emulator to run target executables when testing a cross GHC. However, it's completely undocumented, and some questions needs more thinking:
- `CROSS_EMULATOR` is currently just an environment variable picked up by `hadrian test`. Should it be a part of the `configure` process?
- The testsuite driver's cpu feature detection currently doesn't interact with it. IMO host cpu feature set doesn't make a lot of sense when testing a cross GHC.https://gitlab.haskell.org/ghc/ghc/-/issues/23236Test cases that involve Setup.hs doesn't work for cross GHCs yet2023-04-06T23:37:06ZCheng ShaoTest cases that involve Setup.hs doesn't work for cross GHCs yetSome test cases like `ImpSafe*` require custom `pre_cmd` that compiles and uses a custom `Setup.hs`. The current test suite driver still doesn't handle test cases that require both native/cross GHCs yet, and it'll fail as a framework fai...Some test cases like `ImpSafe*` require custom `pre_cmd` that compiles and uses a custom `Setup.hs`. The current test suite driver still doesn't handle test cases that require both native/cross GHCs yet, and it'll fail as a framework failure:
```
*** framework failure for ImpSafeOnly01(normal) pre_cmd failed: 2
** pre_cmd was "$MAKE -s --no-print-directory mkPackageDatabase.ImpSafeOnly01 VANILLA=--enable-library-vanilla PROF=--enable-library-profiling DYN=--disable-shared".
stdout:
stderr: gmake: pdb.ImpSafeOnly01/setup: No such file or directory
gmake: *** [Makefile:18: mkPackageDatabase.ImpSafeOnly01] Error 127
```
I believe this is also the root cause of #22350.https://gitlab.haskell.org/ghc/ghc/-/issues/22514Hadrian doesn't support --enable-distro-toolchain on Windows2022-11-29T15:57:03ZCheng ShaoHadrian doesn't support --enable-distro-toolchain on WindowsWhen GHC is configured with `--enable-distro-toolchain`, hadrian still attempts to copy the inplace toolchain to `_build`, resulting in the following error:
```
| Copy directory: C:/Users/terrorjack/Downloads/ghc/inplace/mingw => _build...When GHC is configured with `--enable-distro-toolchain`, hadrian still attempts to copy the inplace toolchain to `_build`, resulting in the following error:
```
| Copy directory: C:/Users/terrorjack/Downloads/ghc/inplace/mingw => _build
cp: cannot stat 'C:/Users/terrorjack/Downloads/ghc/inplace/mingw': No such file or directory
Development.Shake.cmd, system command failed
Command line: cp -r C:/Users/terrorjack/Downloads/ghc/inplace/mingw _build
Exit code: 1
Stderr:
cp: cannot stat 'C:/Users/terrorjack/Downloads/ghc/inplace/mingw': No such file or directory
Build failed.
```
This is a problem when building cross GHC with windows host, because GHC needs to be configured to use explicitly passed toolchain instead of the auto-downloaded tarballs.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/22467Hadrian unnecessarily builds target libraries when cross-compiling _build/sta...2022-11-24T18:07:30ZCheng ShaoHadrian unnecessarily builds target libraries when cross-compiling _build/stage1/target-ghcWhen I specify `_build/stage1/target-ghc` as the hadrian target when cross compiling, hadrian should simply copy `_build/stage0/target-ghc`. It indeed does that in the end, but also builds a bunch of target libraries in `_build/stage1`, ...When I specify `_build/stage1/target-ghc` as the hadrian target when cross compiling, hadrian should simply copy `_build/stage0/target-ghc`. It indeed does that in the end, but also builds a bunch of target libraries in `_build/stage1`, which is unnecessary, given those libraries won't be linked into the target I specify.https://gitlab.haskell.org/ghc/ghc/-/issues/22090master: cross compiler bindist built from source fails to configure2022-08-23T14:09:36Zsternimaster: cross compiler bindist built from source fails to configure## Summary
I've tried building a GHC cross compiler targeting aarch64-linux with hadrian. When configuring the bindist, I get:
```
configure: WARNING: unrecognized options: --with-curses-includes, --with-curses-libraries, --with-system...## Summary
I've tried building a GHC cross compiler targeting aarch64-linux with hadrian. When configuring the bindist, I get:
```
configure: WARNING: unrecognized options: --with-curses-includes, --with-curses-libraries, --with-system-libffi, --with-ffi-includes, --with-ffi-libraries, --enable-bootstrap-with-devel-snapshot
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... aarch64-unknown-linux-gnu
configure: GHC build : x86_64-unknown-linux
configure: GHC host : x86_64-unknown-linux
configure: GHC target : aarch64-unknown-linux
checking for path to top of build tree... /build/ghc-ab3e0f5/_build/bindist/ghc-9.5.20220819-aarch64-unknown-linux-gnu
checking for a BSD-compatible install... /nix/store/m5n32vy7rbfrqcxigw1p6wyx3cj7smg9-coreutils-9.1/bin/install -c
checking whether ln -s works... yes
checking for gsed... sed
checking for python3... /nix/store/xf1k5k05vg3zn7dfcpfh1qa7ga48hi3m-python3-3.10.6/bin/python3
checking for gfind... no
checking for find... /nix/store/0b6zhyagwcps9qq67sd0qwmsshnjsqs0-findutils-4.9.0/bin/find
checking for x86_64-unknown-linux-gnu-gcc... /nix/store/rs8cbccfb15pmc3gj5yizislva0fwcw8-aarch64-unknown-linux-gnu-stage-final-gcc-wrapper-9.5.0/bin/aarch64-unknown-linux-gnu-cc
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... configure: error: in `/build/ghc-ab3e0f5/_build/bindist/ghc-9.5.20220819-aarch64-unknown-linux-gnu':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
```
## Steps to reproduce
configure flags (passed to the original configure and re-passed to the bindist configure): `--datadir=$doc/share/doc/ghc --with-curses-includes=/nix/store/8ic6v37rpqql3w3mw9wj1mqviidmibi3-ncurses-6.3-p20220507-dev/include --with-curses-libraries=/nix/store/1rbdizyr45spsmig0sl9cykv4bami6lg-ncurses-6.3-p20220507/lib --with-system-libffi --with-ffi-includes=/nix/store/mkn9f0k6kbgpnj69zsxn8mj4bf0xw0wh-libffi-aarch64-unknown-linux-gnu-3.4.2-dev/include --with-ffi-libraries=/nix/store/67wwbmzijk3hyp2s89z9hvh9ijkmp7ii-libffi-aarch64-unknown-linux-gnu-3.4.2/lib --enable-bootstrap-with-devel-snapshot CFLAGS=-fuse-ld=gold CONF_GCC_LINKER_OPTS_STAGE1=-fuse-ld=gold CONF_GCC_LINKER_OPTS_STAGE2=-fuse-ld=gold --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=aarch64-unknown-linux-gnu`
hadrian flags: `--flavour=release+llvm+no_profiled_libs+split_sections --bignum=gmp --docs=no-sphinx`
```hs
-- hadrian UserSettings.hs
```haskell
module UserSettings (
userFlavours, userPackages, userDefaultFlavour,
verboseCommand, buildProgressColour, successColour, finalStage
) where
import Flavour.Type
import Expression
import {-# SOURCE #-} Settings.Default
-- no way to set this via the command line
finalStage :: Stage
finalStage = Stage1
userDefaultFlavour :: String
userDefaultFlavour = "release"
userFlavours :: [Flavour]
userFlavours = []
-- Disable Colours
buildProgressColour :: BuildProgressColour
buildProgressColour = mkBuildProgressColour (Dull Reset)
successColour :: SuccessColour
successColour = mkSuccessColour (Dull Reset)
-- taken from src/UserSettings.hs unchanged, need to be there
userPackages :: [Package]
userPackages = []
verboseCommand :: Predicate
verboseCommand = do
verbosity <- expr getVerbosity
return $ verbosity >= Verbose
```
## Expected behavior
configures and installs normally
## Environment
* GHC version used: ab3e0f5a02f6a1b63407e08bb97a228a76c27abd
Optional:
* Operating System: NixOS
* System Architecture: x86_64-linux (target: aarch64-linux)Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/22006Cross-compilation broken 9.42023-09-18T16:56:34ZJessica Hamiltonjessica.l.hamilton@gmail.comCross-compilation broken 9.4## Summary
Cross-compilation with GHC 9.4 appears to not generate a cross-compiled GHC, whilst trying to cross-compile to Haiku. The issue happens with both `make` and `hadrian`, but only the steps for `make` below. `hadrian` is essenti...## Summary
Cross-compilation with GHC 9.4 appears to not generate a cross-compiled GHC, whilst trying to cross-compile to Haiku. The issue happens with both `make` and `hadrian`, but only the steps for `make` below. `hadrian` is essentially the same. Using 9.4.1 source tarball.
## Steps to reproduce
Haiku cross-compiler can be built using https://github.com/jessicah/cross-compiler:
```
./build-rootfs.sh x86_64 --rootfsdir DIRNAME
$DIRNAME/fetch-packages.sh gmp gmp_devel mpfr mpfr_devel libiconv libiconv_devel libffi libffi_devel
```
```
export PATH=$PATH:DIRNAME/generated/cross-tools-x86_64/bin
./boot.source
./configure --target=x86_64-unknown-haiku --with-system-libffi
make
make binary-dist
```
## Expected behavior
Generate an installable binary-distribution with Haiku-native binaries.
All binary files I could find were all built for the host, not the target.
## Environment
* GHC version used: 9.0.2 via `ghcup`
Optional:
* Operating System: Ubuntu 20.04.4 LTS (Focal Fossa)
* System Architecture: x86_64Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/21970Cross-compiler binary distribution configure script requires --target flag2024-03-20T10:46:50ZBen 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/21932'FFI_DEFAULT_ABI' could not be recognized even if it is provided by ffitarget.h2022-08-15T13:45:27ZJason Wang'FFI_DEFAULT_ABI' could not be recognized even if it is provided by ffitarget.h## Summary
I've provided the ffi.h and its libs when `./configure`. But the hadrian compiler seems not to recognize the definition of `FFI_DEFAULT_ABI` in `ffitarget.h`.
```shell
error: In file included from _build/stage0/libraries/ghc...## Summary
I've provided the ffi.h and its libs when `./configure`. But the hadrian compiler seems not to recognize the definition of `FFI_DEFAULT_ABI` in `ffitarget.h`.
```shell
error: In file included from _build/stage0/libraries/ghci/build/GHCi/FFI_hsc_make.c:1:
FFI.hsc: In function 'main':
FFI.hsc:131:16: error: 'fFI_DEFAULT_ABI' undeclared (first use in this function); did you mean 'FFI_LAST_ABI'?
/opt/workload/build/ghc-9.2.3/_build/stage0/lib/template-hsc.h:45:10: note: in definition of macro 'hsc_const'
45 | if ((x) < 0) \
| ^
FFI.hsc:131:16: note: each undeclared identifier is reported only once for each function it appears in
/opt/workload/build/ghc-9.2.3/_build/stage0/lib/template-hsc.h:45:10: note: in definition of macro 'hsc_const'
45 | if ((x) < 0) \
|
```
## Steps to reproduce
This issue has the same background as issue 21921, so steps are similar to it.
Run `./configure` as below instead.
```shell
./configure \
AR_STAGE0=/usr/bin/ar \
CC_STAGE0=/usr/bin/gcc \
LD_STAGE0=/usr/bin/ld \
CC=${CROSS_TOOLS}/${CROSS_TARGET}-gcc \
CPP=${CROSS_TOOLS}/${CROSS_TARGET}-cpp \
LD=${CROSS_TOOLS}/${CROSS_TARGET}-ld \
NM=${CROSS_TOOLS}/${CROSS_TARGET}-nm \
OBJDUMP=${CROSS_TOOLS}/${CROSS_TARGET}-objdump \
STRIP=${CROSS_TOOLS}/${CROSS_TARGET}-strip \
RANLIB=${CROSS_TOOLS}/${CROSS_TARGET}-ranlib \
CLANG=${CROSS_TOOLS}/clang \
LLC=${CROSS_TOOLS}/llc \
OPT=${CROSS_TOOLS}/opt \
LDFLAGS=-L${BASEDIR}/cross-tools/ \
CPPFLAGS=-I${BASEDIR}/cross-tools/ \
--target=${CROSS_TARGET} \
--with-system-libffi=yes \
--with-ffi-includes=/opt/workload/cross-tools/target/usr/include/ \
--with-ffi-libraries=/opt/workload/cross-tools/target/usr/lib64
```
## Expected behavior
In `FFI.hsc`, 'fFI_DEFAULT_ABI' could be recognized as 'FFI_LAST_ABI', since it has been defined in `ffitarget.h`
## Environment
* GHC version used: 9.2.3
* Operating System: Fedoral Server 36
* System Architecture: x86_64https://gitlab.haskell.org/ghc/ghc/-/issues/21767`ghc-iserv` assertion failed when cross-compiling2022-07-22T13:07:08ZClaudio Bley`ghc-iserv` assertion failed when cross-compiling## Summary
When trying to cross-compile a template haskell source file on x86_64 targeting aarch64 with `-fexternal-interpreter`, `ghc-iserv` crashes:
```
ghc-iserv: internal error: ASSERTION FAILED: file rts/linker/elf_reloc_aarch64.c,...## Summary
When trying to cross-compile a template haskell source file on x86_64 targeting aarch64 with `-fexternal-interpreter`, `ghc-iserv` crashes:
```
ghc-iserv: internal error: ASSERTION FAILED: file rts/linker/elf_reloc_aarch64.c, line 99
(GHC version 9.0.2 for aarch64_unknown_linux)
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```
## Steps to reproduce
Source file:
```hs
{-# LANGUAGE TemplateHaskell #-}
import Language.Haskell.TH.Syntax
main :: IO ()
main = putStrLn $( do liftString ("answer: " ++ show 42) )
```
Compile with:
```
$ aarch64-unknown-linux-gnu-ghc -pgmi /path/to/ghc/lib/aarch64-unknown-linux-gnu-ghc-9.0.2/bin/ghc-iserv -fexternal-interpreter -v thmain.hs
```
Output:
```
Glasgow Haskell Compiler, Version 9.0.2, stage 1 booted by GHC version 8.10.7
*** initializing unit database:
Using binary package database: /nix/store/5j5pldfyaayh1kgymcgwv11d7plmlk63-aarch64-unknown-linux-gnu-ghc-native-bignum-9.0.2/lib/aarch64-unknown-linux-gnu-ghc-9.0.2/package.conf.d/package.cache
package flags []
loading package database /nix/store/5j5pldfyaayh1kgymcgwv11d7plmlk63-aarch64-unknown-linux-gnu-ghc-native-bignum-9.0.2/lib/aarch64-unknown-linux-gnu-ghc-9.0.2/package.conf.d
wired-in package ghc-prim mapped to ghc-prim-0.7.0
wired-in package ghc-bignum mapped to ghc-bignum-1.1
wired-in package base mapped to base-4.15.1.0
wired-in package rts mapped to rts
wired-in package template-haskell mapped to template-haskell-2.17.0.0
wired-in package ghc not found.
!!! initializing unit database: finished in 9.60 milliseconds, allocated 8.889 megabytes
*** initializing unit database:
package flags []
loading package database /nix/store/5j5pldfyaayh1kgymcgwv11d7plmlk63-aarch64-unknown-linux-gnu-ghc-native-bignum-9.0.2/lib/aarch64-unknown-linux-gnu-ghc-9.0.2/package.conf.d
wired-in package ghc-prim mapped to ghc-prim-0.7.0
wired-in package ghc-bignum mapped to ghc-bignum-1.1
wired-in package base mapped to base-4.15.1.0
wired-in package rts mapped to rts-1.0.2
wired-in package template-haskell mapped to template-haskell-2.17.0.0
wired-in package ghc not found.
!!! initializing unit database: finished in 7.79 milliseconds, allocated 2.035 megabytes
*** Chasing dependencies:
Chasing modules from: *thmain.hs
!!! Chasing dependencies: finished in 0.67 milliseconds, allocated 0.696 megabytes
Stable obj: {Main}
Stable BCO: {}
Ready for upsweep
[NONREC
ModSummary {
ms_hs_date = 2022-06-20 12:20:46.437771223 UTC
ms_mod = Main,
ms_textual_imps = [(Nothing, Prelude),
(Nothing, Language.Haskell.TH.Syntax)]
ms_srcimps = []
}]
*** Deleting temp files:
Deleting:
compile: input file thmain.hs
*** Checking old interface for Main (use -ddump-hi-diffs for more details):
[1 of 1] Compiling Main ( thmain.hs, thmain.o )
*** Parser [Main]:
!!! Parser [Main]: finished in 0.37 milliseconds, allocated 0.244 megabytes
*** Renamer/typechecker [Main]:
*** Simplify [expr]:
!!! Simplify [expr]: finished in 0.07 milliseconds, allocated 0.056 megabytes
*** CorePrep [expr]:
!!! CorePrep [expr]: finished in 0.32 milliseconds, allocated 0.795 megabytes
*** GHC.CoreToByteCode [Ghci1]:
Starting /nix/store/5j5pldfyaayh1kgymcgwv11d7plmlk63-aarch64-unknown-linux-gnu-ghc-native-bignum-9.0.2/lib/aarch64-unknown-linux-gnu-ghc-9.0.2/bin/ghc-iserv
!!! GHC.CoreToByteCode [Ghci1]: finished in 2.63 milliseconds, allocated 0.183 megabytes
*** systool:linker:
*** gcc:
/nix/store/8l6s18lnfvsh1ixzza2x62yyn6pfq9gx-aarch64-unknown-linux-gnu-stage-final-gcc-debug-wrapper-9.3.0/bin/aarch64-unknown-linux-gnu-cc '-fuse-ld=gold' -Wl,-z,noexecstack -B/nix/store/5j5pldfyaayh1kgymcgwv11d7plmlk63-aarch64-unknown-linux-gnu-ghc-native-bignum-9.0.2/lib/aarch64-unknown-linux-gnu-ghc-9.0.2/ghc-prim-0.7.0 --print-file-name libc.so
!!! systool:linker: finished in 0.41 milliseconds, allocated 0.098 megabytes
*** systool:linker:
*** gcc:
/nix/store/8l6s18lnfvsh1ixzza2x62yyn6pfq9gx-aarch64-unknown-linux-gnu-stage-final-gcc-debug-wrapper-9.3.0/bin/aarch64-unknown-linux-gnu-cc '-fuse-ld=gold' -Wl,-z,noexecstack -B/nix/store/5j5pldfyaayh1kgymcgwv11d7plmlk63-aarch64-unknown-linux-gnu-ghc-native-bignum-9.0.2/lib/aarch64-unknown-linux-gnu-ghc-9.0.2/ghc-prim-0.7.0 --print-file-name libm.so
!!! systool:linker: finished in 0.22 milliseconds, allocated 0.074 megabytes
Loading package ghc-prim-0.7.0 ... linking ... ghc-iserv: internal error: ASSERTION FAILED: file rts/linker/elf_reloc_aarch64.c, line 99
(GHC version 9.0.2 for aarch64_unknown_linux)
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
*** Deleting temp files:
Deleting:
*** Deleting temp dirs:
Deleting:
ghc: ghc-iserv terminated (-6)
```
(Note: `ghc-iserv` is an aarch64 binary, but I have enabled binfmt_misc support for aarch64 using `qemu-aarch64` so I can run aarch64 binaries transparently on my system)
Backtrace:
```
#0 0x00000055008dca88 in raise () from /nix/store/y3rh7f9mhi5qnv5vci01ds607gjywcad-glibc-aarch64-unknown-linux-gnu-2.33-108/lib/libc.so.6
#1 0x00000055008ca1f4 in abort () from /nix/store/y3rh7f9mhi5qnv5vci01ds607gjywcad-glibc-aarch64-unknown-linux-gnu-2.33-108/lib/libc.so.6
#2 0x0000000001de3870 in rtsFatalInternalErrorFn ()
#3 0x0000000001de39c8 in barf ()
#4 0x0000000001de3a20 in _assertFail ()
#5 0x0000000001e179c0 in encodeAddendAarch64 ()
#6 0x0000000001e17b50 in relocateObjectCodeAarch64 ()
#7 0x0000000001dfd2cc in ocResolve_ELF ()
#8 0x0000000001de0c80 in ocTryLoad ()
#9 0x0000000001de10ec in resolveObjs ()
#10 0x0000000000fe4d78 in ghcizm9zi0zi2_GHCiziObjLink_resolveObjs1_info$def ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
```
## Expected behavior
I would expect the source file to be compiled without errors, I tested this with GHC 8.10.4 and it worked flawlessly.
## Environment
* GHC version used: 9.0.2 native-bignum
Optional:
* Operating System: NixOS / Linux x1 5.17.7-zen1 #1-NixOS ZEN SMP PREEMPT Tue Jan 1 00:00:00 UTC 1980 x86_64 GNU/Linux
* System Architecture: x86_64Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/21614cross-compiling issue with hadrian2023-04-22T18:28:26Zkgardascross-compiling issue with hadrianWhen someone apply fixes for #21601 and #21613 then x64-linux to arm-linux cross-compiler build finishes fine when using `make` build system. When using hadrian it fails with:
```
$ ./hadrian/build --flavour=quick-cross
Up to date
| Run...When someone apply fixes for #21601 and #21613 then x64-linux to arm-linux cross-compiler build finishes fine when using `make` build system. When using hadrian it fails with:
```
$ ./hadrian/build --flavour=quick-cross
Up to date
| Run Cc (FindCDependencies CDep) Stage1: libraries/ghc-bignum/cbits/gmp_wrappers.c => _build/stage1/libraries/ghc-bignum/build/c/cbits/gmp_wrappers.o.d
Command line: /export/home/karel/sfw/x-tools/arm-unknown-linux-gnueabihf/bin//arm-unknown-linux-gnueabihf-gcc -std=c99 -Wall -marm -E -MM -MG -MF _build/stage1/libraries/ghc-bignum/build/c/cbits/gmp_wrappers.o.d -MT _build/stage1/libraries/ghc-bignum/build/c/cbits/gmp_wrappers.o -Irts/include -I_build/stage1/libraries/ghc-bignum/build -I_build/stage1/libraries/ghc-bignum/build/include/ -I_build/stage1/libraries/ghc-bignum/build/include -Ilibraries/ghc-bignum/include/ -Ilibraries/ghc-bignum/include -I/export/home/karel/vcs/ghc-src/arm-linux/ghc/_build/stage1/lib/arm-linux-ghc-9.5.20220521/rts-1.0.2/include -x c libraries/ghc-bignum/cbits/gmp_wrappers.c
===> Command failed with error code: 1
libraries/ghc-bignum/cbits/gmp_wrappers.c:30:3: error: #error __GNU_MP_VERSION not defined
# error __GNU_MP_VERSION not defined
^~~~~
libraries/ghc-bignum/cbits/gmp_wrappers.c:42:3: error: #error WORD_SIZE_IN_BITS != GMP_LIMB_BITS not supported
# error WORD_SIZE_IN_BITS != GMP_LIMB_BITS not supported
^~~~~
Command failed
Build failed.
```
This is probably a sign of hadrian trying to use host gmp instead of cross-compiled one.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/21613cross-compiling issue with process library2022-05-24T17:12:41Zkgardascross-compiling issue with process libraryNot sure what is the sequence of reporting library issues here, but an attempt to cross-compile x64-linux -> arm-linux fails with error in running configure script in process library. The error is already fixed here:
https://github.com/h...Not sure what is the sequence of reporting library issues here, but an attempt to cross-compile x64-linux -> arm-linux fails with error in running configure script in process library. The error is already fixed here:
https://github.com/haskell/process/pull/244
Of course to get to this point you need to fix/workaround #21601. The fix offered there works fine.Ben GamariBen Gamari