GHC's build system assumes that the C compiler, tools etc. discovered
during configure can also be used at runtime. This means that the CC,
LD, AR etc. variables given at runtime are used to populate the settings
file which GHC uses to lookup the tools it needs.
The implicit assumption of this mechanism is that the build and runtime
environment of GHC are similar enough and PATH is used to find the
tools. I. e. if we set CC=clang, we wouldn't need to worry about this as
much. We, however, pass absolute paths which is useful since it allows
GHC to work outside of stdenv (as long as e. g. no FFI is involved).
Even so, until now, we didn't really have any problems stemming from
this, as we used pkgsBuildTarget to get everything we need. The
compiler we'd want to execute would in principle need to come
from pkgsHostTarget.
1. For native compilers, all package sets are the same since
build == host == target.
2. For cross compilers build == host, so pkgsBuildTarget
is practically the same as pkgsHostTarget.
When cross-compiling a native compiler, build != host, so we need to
actually ensure that GHC uses different tools at runtime compared to
bootstrapping. There is currently no intended way to achieve this, so we
use a custom tool to edit the settings file. An alternative would be to
patch the build system, but this would be difficult to maintain. We
could go down this route if there's interest from upstream to provide a
proper way to specify the runtime tools.
Co-authored-by: sternenseemann <sternenseemann@systemli.org>
The goal of this commit is basically to eliminate the use of
targetPackages for finding libraries. Instead, we introduce a
`targetLibs` set that can be used instead. The libraries in there
philosophically come from targetPackages since they are used by the core
libs and will be linked against user code. However, when cross compiling
GHC it's always a native compiler, so we can and have to use
pkgsHostTarget (targetPackages would be empty). This is explained more
in the acccompanying comment.
An alternative to this approach is not to pass in the libraries
explicitly via `--with-*` flags and rely on cc-wrapper and splicing to
pick the correct library. This works well for ncurses and probably
merits testing for other libraries as well since it's very simple. It
would need to be verified, however, that configure doesn't discover the
“wrong” library and leaks it somewhere.
Co-authored-by: sternenseemann <sternenseemann@systemli.org>
1. Explicitly set WITH_TERMINFO. We usually match GHC's behavior well,
but it is better to tie the Nix option to make explicitly.
Unfortunately, the same is very complicated to achieve with
hadrian (iirc).
2. Disable enableTerminfo if we are cross-compiling. This matches
the behavior of GHC's build system, so we'll have to match it now.
It also reduces the ncurses-related headache a bit.
3. Stop passing --with-curses* flags. Unfortunately, GHC does not
account for the fact that different platforms need different ncurses
libraries. This is somewhat migitated by the fact that ncurses is
only ever needed for the build platform if we are cross compiling,
but I seem to remember it leaking into the final GHC somehow.
A more reliable alternative is relying on the cc/ld wrapper scripts,
as they'll always pull out the correct ncurses out of the environment
when GHC's build system passes -lcurses.
4. Unconditionally add ncurses to depsBuildBuild. Stage0 unconditionally
builds terminfo (maybe the stage1 compiler needs it?), so we need to
make sure that ncurses for the build platform is available.
Co-authored-by: sternenseemann <sternenseemann@systemli.org>
This is easy in comparison since these tools won't end up in GHC's
settings nor need to be available at runtime, so we can use
the *_FOR_BUILD environment variables.
It is important to add buildCC to depsBuildBuild to engage the
stdenv/wrapper script machinery properly.
Co-authored-by: sternenseemann <sternenseemann@systemli.org>
