Hi Ricardo, Ricardo Wurmus <[email protected]> writes:
> Hi Ludo, > >> Hello, >> >> Ricardo Wurmus <[email protected]> skribis: >> >>> GHC 8.0 had been patched with >>> "ghc-dont-pass-linker-flags-via-response-files.patch" to avoid using >>> response files with the linker, because our ld-wrapper doesn’t seem to >>> behave right in some edge case that GHC depends on. I tried porting the >>> patch to GHC 8.4.3 by applying this snippet: >> >> I think this patch predates the addition of support for response files >> in ld-wrapper. That support is not entirely faithful (see the FIXME in >> ld-wrapper.in), but I think it’s good enough for GHC. >> >> Could you maybe try removing the patch and see if it works better? > > I did try to build GHC 8.4.3 without any patches first, but this failed > (with the same errors and warnings when trying to set up the tests). > Only then did I try to port the patch from 8.0.x to 8.4.3. 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. Also, I didn’t need the response files patch, and the “native-search-paths” field needs to be updated. Hope that helps! -- Tim
