GNU bug report logs -
#24416
avr-gcc@5 is broken
Previous Next
Full log
Message #11 received at 24416 <at> debbugs.gnu.org (full text, mbox):
On Mon, Sep 12, 2016 at 2:49 AM, Danny Milosavljevic
<dannym <at> scratchpost.org> 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 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.
Thanks,
- Dave
This bug report was last modified 5 years and 10 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.