From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: bug#24416: avr-gcc@5 is broken Date: Tue, 13 Sep 2016 11:18:22 +0200 Message-ID: <20160913111822.3da1c609@scratchpost.org> References: <20160912084936.25713732@scratchpost.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:49644) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bjjrt-0005EB-G4 for bug-guix@gnu.org; Tue, 13 Sep 2016 05:19:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bjjrq-0003Io-5z for bug-guix@gnu.org; Tue, 13 Sep 2016 05:19:05 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:60490) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bjjrq-0003Ik-34 for bug-guix@gnu.org; Tue, 13 Sep 2016 05:19:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bjjrp-00009W-Uq for bug-guix@gnu.org; Tue, 13 Sep 2016 05:19:01 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: "Thompson, David" Cc: 24416@debbugs.gnu.org On Mon, 12 Sep 2016 11:29:11 -0400 "Thompson, David" wrote: > On Mon, Sep 12, 2016 at 2:49 AM, Danny Milosavljevic > wrote: > > As a workaround, > > > > CPPFLAGS += -I${HOME}/.guix-profile/avr/include > > LDFLAGS += -L${HOME}/.guix-profile/avr/lib/avr5 -L${HOME}/.guix-profile/avr/lib -B${HOME}/.guix-profile/avr/lib > > > > works with avr-gcc 5.3.0. Unfortunately I don't know enough about avr-gcc to be able to permanently fix it. > > > > I fixed part of it (I made it so that atmega32u4 exists in the first place) in master - but no idea what to do with the search path. > > > > I'm pretty sure that if it uses CROSS_CPATH it's incorrect because cross-base has been changed from CROSS_CPATH to CROSS_C_INCLUDE_PATH, CROSS_CPLUS_INCLUDE_PATH etc in order to suppress warnings. If CROSS_C_INCLUDE_PATH overrides CROSS_CPATH (does it?) then setting CROSS_CPATH like avr.scm does does no good. > > > > I propose to change it to the following: > > > > diff --git a/gnu/packages/avr.scm b/gnu/packages/avr.scm > > index 9873477..1e5fd73 100644 > > --- a/gnu/packages/avr.scm > > +++ b/gnu/packages/avr.scm > > @@ -59,9 +59,18 @@ > > #t)))) > > ((#:configure-flags flags) > > `(delete "--disable-multilib" ,flags)))) > > - (native-search-paths > > + (native-search-paths > > (list (search-path-specification > > - (variable "CROSS_CPATH") > > + (variable "CROSS_C_INCLUDE_PATH") > > + (files '("avr/include"))) > > + (search-path-specification > > + (variable "CROSS_CPLUS_INCLUDE_PATH") > > + (files '("avr/include"))) > > + (search-path-specification > > + (variable "CROSS_OBJC_INCLUDE_PATH") > > + (files '("avr/include"))) > > + (search-path-specification > > + (variable "CROSS_OBJCPLUS_INCLUDE_PATH") > > (files '("avr/include"))) > > (search-path-specification > > (variable "CROSS_LIBRARY_PATH") > > I don't know if this will have the intended effect and I cannot > experiment with it right now. Could you test? (The patch: ) Can't test it right now (out of disk space; updating 2 GB texmf is really annoying) - but I tested it in the past and it wasn't sufficient. On the other hand, before the patch is applied, cross-gcc and avr.scm set *different* variables and that's probably incorrect. > The LDFLAGS above > include the path to the device-specific object files (/avr5), but > avr-gcc is supposed to be able to figure that out on its own using a > "normal" library path, so I'm skeptical that simply changing the > search paths for the package is enough. I've used these LDFLAGS (actually used them as global flags for all gcc invocations) for some weeks with daily success. Also, the "-B" is necessary. I think that the "native-search-paths" only affect the build system. As far as I understand, avr-gcc is a "native" compiler in the sense of it-shouldn't-try-to-build-all-Guix-packages-for-it. And it's certainly set up as a "native" compiler. But that means that the avr-gcc port has to hack the search path that gcc usually uses for native compilers to make it search something else - not sure where they do and why it doesn't work for us. It would be good to locate this part. The atmega32u4 comes from avr-libc (!) - that's why I changed avr-libc to use the same compiler (already in master for some months). That made it work much better. I hope someone can shed a light on this.