For the GHC JavaScript backend, we'll use emscripten in place of
targetCC. To avoid having too much special logic for this, we'll make
the emscripten derivation look like the result of wrapCC as far as GHC
is concerned, i.e. we need targetPrefix and bintools.
For bintools, we'll just reexpose emscripten, as it has emar, the only
relevant bintools. That the other ones are missing doesn't matter in
practice, as the GHC build system won't attempt to use them.
targetPrefix can immediately be (ab)used to make sure GHC will correctly
call emcc etc. instead of plain cc.
GHC's js backend depends on systemd via emscripten via closure compiler
via jdk via cups. Before it fails to evaluate, though, since
llvmPackages looks into `targetPackages.stdenv.cc` to determine which
C++ library to use (something that should be rectified in the future).
[Unfortunately], for `pkgsCross.ghcjs`, `stdenv.cc` throws which blows
up evaluating `pkgsCross.buildPackages.llvmPackages.clang`.
This is in principle unnecessary. We want to build
`pkgsCross.ghcjs.buildPackages.haskell.compiler.native-bignum.ghcHEAD`
which depends on `pkgsCross.ghcjs.buildPackages.systemd` which needs
clang and friends only in `nativeBuildInputs`, so
`pkgsCross.ghcjs.buildPackages.buildPackages.llvmPackages.clang`.
Unfortunately, due to the nature of splicing, we first evaluate the
“adjacent” derivation before we can access the spliced derivation we are
actually interested in. If the former
fails (`pkgsCross.ghcjs.buildPackages.llvmPackages.clang`), we can't do
the latter.
The solution is to just not rely on splicing in this case and take
`buildPackages.llvmPackages.clang` directly (relative to
`buildPackages.systemd` in this case!) which avoids the whole problem.
[Unfortunately]: https://github.com/NixOS/nixpkgs/commit/c739c420db5b9d56c335414be1696c57f2dbbb6a#diff-3209527bd27cbc775f579b1e295b0264c850859c7245d526965cec456b8c70a4R61
Finally building a cross compiler using hadrian is possible, but there
are some outstanding issues regarding external libraries in the package
db which causes issues with ghc-bignum.
Just a few comments added:
- added a few one-liners to explore which tools are rebuilt at each
stdenv iteration during bootstrap
- explicitly listed available toolchains and their sources for on each
bootstrap step: glibc, binutils, gcc, coreutils.
- added mention of static libraries linked into gcc
Co-authored-by: Adam Joseph <54836058+amjoseph-nixpkgs@users.noreply.github.com>
sternenseemann