From mboxrd@z Thu Jan 1 00:00:00 1970 From: Timothy Sample Subject: Re: Help needed: Updating GHC to 8.4.3 Date: Sun, 26 Aug 2018 10:29:33 -0400 Message-ID: <87pny55hgy.fsf@ngyro.com> References: <87tvnpfir4.fsf@gnu.org> <874lfptjd3.fsf@elephly.net> <87k1of6nlq.fsf@ngyro.com> <87tvni5jq9.fsf@ngyro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36335) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ftw2t-0004Gv-Q8 for guix-devel@gnu.org; Sun, 26 Aug 2018 10:29:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ftw2q-0003M6-JM for guix-devel@gnu.org; Sun, 26 Aug 2018 10:29:39 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:46659) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ftw2q-0003Kh-DB for guix-devel@gnu.org; Sun, 26 Aug 2018 10:29:36 -0400 In-Reply-To: <87tvni5jq9.fsf@ngyro.com> (Timothy Sample's message of "Sat, 25 Aug 2018 15:28:30 -0400") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ricardo Wurmus Cc: guix-devel@gnu.org Hello, Timothy Sample writes: > Hi Again, > > I=E2=80=99ve attached an updated patch that builds a working GHC 8.4.3 (t= hat is, > it compiles =E2=80=9Chello.hs=E2=80=9D in a pure environment). It might = need a bit more > work yet. See notes below. It turns out that it wasn=E2=80=99t a pure environment. I was running Guix= on top of Debian, and GCC was presumably finding =E2=80=9Cas=E2=80=9D 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 =E2=80=9C-C=E2=80= =9D instead of =E2=80=9C--pure=E2=80=9D!) > Timothy Sample writes: > > [...] > >> I had some success with GHC 8.4.3. It turns out that the warnings exist >> for 8.0.2 as well. I=E2=80=99m not sure what they are about, but they a= re 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 =E2=80=9C-fuse-ld=3Dbfd=E2=80=9D to the later-stage compilers=E2=80= =99 =E2=80=9Cgcc=E2=80=9D invocations by >> default. Since =E2=80=9Cld.bfd=E2=80=9D does not point to the ld-wrappe= r, the wrapper >> gets bypassed. >> >> There are two easy solutions to this: >> >> 1. Use the =E2=80=9C--disable-ld-override=E2=80=9D configure flag. >> 2. Set the =E2=80=9CLD=E2=80=9D environment variable. >> >> I got the package to build using option 1. However, it didn=E2=80=99t w= ork >> because it expected all the build tools (=E2=80=9Cgcc=E2=80=9D, =E2=80= =9Cld=E2=80=9D, etc.) to be in >> =E2=80=9CPATH=E2=80=9D. They traded =E2=80=9CAC_PATH_=E2=80=9D for =E2= =80=9CAC_CHECK_=E2=80=9D, 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=E2=80=99s example, and set environment variables. I didn= =E2=80=99t set > the same ones as Nix, since some of them are Windows- or Clang-specific, > and one of them (=E2=80=9Car=E2=80=9D) didn=E2=80=99t work. > > These tools need to be used by the resulting compiler, so I made sure > that they are =E2=80=9Cinputs=E2=80=9D rather than =E2=80=9Cnative-inputs= =E2=80=9D. I don=E2=80=99t know if GHC > can be cross compiled, but I think something like this is necessary for > it. To be honest, I=E2=80=99m 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 =E2=80=9Cas=E2=80=9D) do not work. After getting into the weeds wi= th GCC=E2=80=99s =E2=80=9C-B=E2=80=9D flag, I realized that even our GCC package doesn=E2=80=99t work in a pure environment. It doesn=E2=80=99t know how to find =E2=80=9Cas=E2=80=9D in t= he store. That=E2=80=99s why the =E2=80=9Cgcc-toolchain=E2=80=9D package exists. To summarize, there are three problems with the original patch: 1. it uses =E2=80=9Cld.bfd=E2=80=9D instead of =E2=80=9Cld=E2=80=9D (skip= ping the wrapper); 2. it references native tools instead of target tools; and 3. it requires certain tools to be available from =E2=80=9CPATH=E2=80=9D. Problems 2 and 3 affect GHC 8.0.2 too. Problem 1 is new. At this point, I=E2=80=99m thinking that using either =E2=80=9C--disable-ld-overrid= e=E2=80=9D or =E2=80=9CLD=3Dld=E2=80=9D 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 =E2=80=9CPATH=E2=80=9D, but this is how GCC itself works current= ly with =E2=80=9Cbinutils=E2=80=9D. It has the added benefit that these will likel= y be the tools for the target platform. WDYT? -- Tim > [...]