Re: Help needed: Updating GHC to 8.4.3

[Timothy Sample <samplet@ngyro.com>]

Hello,

Timothy Sample <samplet@ngyro.com> writes:

> Hi Again,
>
> I’ve attached an updated patch that builds a working GHC 8.4.3 (that is,
> it compiles “hello.hs” in a pure environment).  It might need a bit more
> work yet.  See notes below.

It turns out that it wasn’t a pure environment.  I was running Guix on
top of Debian, and GCC was presumably finding “as” and its other
run-time dependencies in hard-coded locations.  It does not work in a
pure environment on top of GuixSD.  (Next time I will use “-C” instead
of “--pure”!)

> Timothy Sample <samplet@ngyro.com> writes:
>
> [...]
>
>> I had some success with GHC 8.4.3.  It turns out that the warnings exist
>> for 8.0.2 as well.  I’m not sure what they are about, but they are not a
>> new problem.
>>
>> The new problem is that the stage-2 GHC compiler is not using the
>> ld-wrapper.  This is due to some changes to their Autoconf scripts which
>> add “-fuse-ld=bfd” to the later-stage compilers’ “gcc” invocations by
>> default.  Since “ld.bfd” does not point to the ld-wrapper, the wrapper
>> gets bypassed.
>>
>> There are two easy solutions to this:
>>
>>   1. Use the “--disable-ld-override” configure flag.
>>   2. Set the “LD” environment variable.
>>
>> I got the package to build using option 1.  However, it didn’t work
>> because it expected all the build tools (“gcc”, “ld”, etc.) to be in
>> “PATH”.  They traded “AC_PATH_” for “AC_CHECK_”, setting the variables
>> to just the command names.  Nix uses option 2 and sets explicit paths
>> for all the tools via environment variables.  I think we have to do the
>> same.
>
> I followed Nix’s example, and set environment variables.  I didn’t set
> the same ones as Nix, since some of them are Windows- or Clang-specific,
> and one of them (“ar”) didn’t work.
>
> These tools need to be used by the resulting compiler, so I made sure
> that they are “inputs” rather than “native-inputs”.  I don’t know if GHC
> can be cross compiled, but I think something like this is necessary for
> it.  To be honest, I’m not sure I did this correctly, so do take a
> careful look.

I think I may have gone overboard here.  It turns out GHC 8.0.2 does not
work in a pure environment, either.  It finds all of its immediate
dependencies (like GCC), but the transitive dependencies (like GCC
calling “as”) do not work.  After getting into the weeds with GCC’s “-B”
flag, I realized that even our GCC package doesn’t work in a pure
environment.  It doesn’t know how to find “as” in the store.  That’s why
the “gcc-toolchain” package exists.

To summarize, there are three problems with the original patch:

  1. it uses “ld.bfd” instead of “ld” (skipping the wrapper);
  2. it references native tools instead of target tools; and
  3. it requires certain tools to be available from “PATH”.

Problems 2 and 3 affect GHC 8.0.2 too.  Problem 1 is new.  At this
point, I’m thinking that using either “--disable-ld-override” or “LD=ld”
might be the most reasonable approach (they do the same thing, but the
second one is clearer IMO).  It means that GHC will look for GCC and
friends in “PATH”, but this is how GCC itself works currently with
“binutils”.  It has the added benefit that these will likely be the
tools for the target platform.

WDYT?


-- Tim

> [...]