[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#24416: address@hidden is broken
From: |
Thompson, David |
Subject: |
bug#24416: address@hidden is broken |
Date: |
Mon, 12 Sep 2016 11:29:11 -0400 |
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
- Prev by Date:
bug#24408: `make check` fails for builders, build-utils, cran, derivations, elpa, gexp, grafts, hackage, monads, packages, store, ui
- Next by Date:
bug#24418: GnuTLS security update
- Previous by thread:
bug#24416: address@hidden is broken
- Next by thread:
bug#24416: address@hidden is broken
- Index(es):