Hello, Timothy Sample <[email protected]> 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 <[email protected]> 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 > [...]
