bug#24416: address@hidden is broken

[Thompson, David]

On Mon, Sep 12, 2016 at 2:49 AM, Danny Milosavljevic
<address@hidden> 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