guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 2/5] gnu: Add avr-gcc.


From: Ludovic Courtès
Subject: Re: [PATCH 2/5] gnu: Add avr-gcc.
Date: Thu, 14 Apr 2016 19:25:14 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

David Thompson <address@hidden> skribis:

> * gnu/packages/avr.scm (avr-gcc): New variable.

[...]

> +          `(modify-phases ,phases
> +             ;; Without a working multilib build, the resulting GCC lacks
> +             ;; 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
‘patch-shebangs’ phase is because it does not have the executable bit.
Would be worth mentioning in a comment IMO.

What’s unclear, though, is why the invalid shebang is a problem at all
given that this file is not executable anyway.  Thoughts?

> +         ((#:configure-flags flags)
> +          '(list "--target=avr"
> +                 "--enable-languages=c,c++"
> +                 "--disable-nls"
> +                 "--disable-libssp"
> +                 "--with-dwarf2"))))

I think we should minimize target-specific changes and justify them in a
comment when they’re unavoidable.

Here, I think we can safely remove --target and --disable-nls.
--disable-libssp and --enable-languages are already in
‘cross-gcc-arguments’, so that leaves us with just --with-dwarf2, IIUC.

Why is it needed?

> +      (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 ‘native-search-paths’ feels wrong.

But I think it’s because we’re trying to build avr-libc like a “normal”
package with a cross-toolchain as its input.

Instead, the “intended use” is that libc is treated specially as in
‘cross-libc’ in cross-base.scm.  Probably we need to:

  1. Remove #:configure-flags and ‘native-inputs’ from the ‘avr-libc’
     package.

  2. Add (supported-systems '()) or similar to the ‘avr-libc’ package.

  3. Use something similar to ‘cross-libc’ but that uses avr-libc
     instead of glibc in cross-base.scm, thus setting CROSS_CPATH and
     CROSS_LIBRARY_PATH appropriately.

WDYT?

Apologies for spoiling the party.  ;-)  This is clearly a
tricky/inelegant area.

Thanks,
Ludo’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]