From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Thompson, David" Subject: Re: [PATCH 2/5] gnu: Add avr-gcc. Date: Mon, 30 May 2016 13:44:03 -0400 Message-ID: References: <1460639824-9976-1-git-send-email-dthompson2@worcester.edu> <1460639824-9976-3-git-send-email-dthompson2@worcester.edu> <87y48gje6d.fsf@gnu.org> 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]:36091) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b7REY-0004DW-86 for guix-devel@gnu.org; Mon, 30 May 2016 13:44:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b7RES-0006rX-Fg for guix-devel@gnu.org; Mon, 30 May 2016 13:44:09 -0400 Received: from mail-yw0-x243.google.com ([2607:f8b0:4002:c05::243]:36077) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b7RES-0006rO-Af for guix-devel@gnu.org; Mon, 30 May 2016 13:44:04 -0400 Received: by mail-yw0-x243.google.com with SMTP id l126so15614444ywe.3 for ; Mon, 30 May 2016 10:44:04 -0700 (PDT) In-Reply-To: <87y48gje6d.fsf@gnu.org> 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: =?UTF-8?Q?Ludovic_Court=C3=A8s?= Cc: guix-devel On Thu, Apr 14, 2016 at 1:25 PM, Ludovic Court=C3=A8s wrote: > David Thompson skribis: > >> * gnu/packages/avr.scm (avr-gcc): New variable. > > [...] > >> + `(modify-phases ,phases >> + ;; Without a working multilib build, the resulting GCC lac= ks >> + ;; support for nearly every AVR chip. >> + (add-after 'unpack 'fix-genmultilib >> + (lambda _ >> + (substitute* "gcc/genmultilib" >> + (("#!/bin/sh") (string-append "#!" (which "sh")))) > > Just: (patch-shebang "gcc/genmultilib"). > > I think the reason this file is not automatically patched during the > =E2=80=98patch-shebangs=E2=80=99 phase is because it does not have the ex= ecutable bit. > Would be worth mentioning in a comment IMO. > > What=E2=80=99s unclear, though, is why the invalid shebang is a problem a= t all > given that this file is not executable anyway. Thoughts? It turns out that gcc/genmultilib is a script that generates many scripts, and thus has many instances of #!/bin/sh in it. So, patch-shebang was inadequate for the job and I've stuck with the original solution. >> + ((#:configure-flags flags) >> + '(list "--target=3Davr" >> + "--enable-languages=3Dc,c++" >> + "--disable-nls" >> + "--disable-libssp" >> + "--with-dwarf2")))) > > I think we should minimize target-specific changes and justify them in a > comment when they=E2=80=99re unavoidable. > > Here, I think we can safely remove --target and --disable-nls. > --disable-libssp and --enable-languages are already in > =E2=80=98cross-gcc-arguments=E2=80=99, so that leaves us with just --with= -dwarf2, IIUC. > > Why is it needed? I've removed all of these. >> + (native-search-paths >> + (list (search-path-specification >> + (variable "CROSS_CPATH") >> + (files '("avr/include"))) >> + (search-path-specification >> + (variable "CROSS_LIBRARY_PATH") >> + (files '("avr/lib")))))))) > > That these go in =E2=80=98native-search-paths=E2=80=99 feels wrong. > > But I think it=E2=80=99s because we=E2=80=99re trying to build avr-libc l= ike a =E2=80=9Cnormal=E2=80=9D > package with a cross-toolchain as its input. > > Instead, the =E2=80=9Cintended use=E2=80=9D is that libc is treated speci= ally as in > =E2=80=98cross-libc=E2=80=99 in cross-base.scm. Probably we need to: > > 1. Remove #:configure-flags and =E2=80=98native-inputs=E2=80=99 from th= e =E2=80=98avr-libc=E2=80=99 > package. > > 2. Add (supported-systems '()) or similar to the =E2=80=98avr-libc=E2= =80=99 package. > > 3. Use something similar to =E2=80=98cross-libc=E2=80=99 but that uses = avr-libc > instead of glibc in cross-base.scm, thus setting CROSS_CPATH and > CROSS_LIBRARY_PATH appropriately. As explained in the thread about the avr-toolchain, this is a special scenario because the only use for avr-gcc is to cross-compile and you cannot actually port any part of Guix to the AVR architecture. Maybe there's still something to revisit later, but having a working AVR toolchain is a big win for now. Pushed with the other issues addressed. Thanks! - Dave