[PATCH 0/6] Fix AVR toolchain.

[PATCH 0/6] Fix AVR toolchain.

[David Thompson]

Manolis and I spend quite a lot of time figuring out why our GCC AVR
cross-compilation toolchain is so broken and we were finally able to fix it!
So here's a patch set that fixes things, updates avr-libc to 2.0.0, and adds a
handy avr-toolchain package inspired by the gcc-toolchain package.

Happy firmware hacking!

- Dave

[PATCH 1/5] gnu: Add avr-binutils.

[David Thompson]

* gnu/packages/avr.scm (avr-binutils): New variable.
---
 gnu/packages/avr.scm | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/avr.scm b/gnu/packages/avr.scm
index d59816b..b30c64e 100644
--- a/gnu/packages/avr.scm
+++ b/gnu/packages/avr.scm
@@ -1,6 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2014 Manolis Fragkiskos Ragkousis <manolis837@gmail.com>
+;;; Copyright © 2014, 2016 Manolis Fragkiskos Ragkousis <manolis837@gmail.com>
 ;;; Copyright © 2015 Ricardo Wurmus <rekado@elephly.net>
+;;; Copyright © 2016 David Thompson <davet@gnu.org>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -27,6 +28,14 @@
   #:use-module (gnu packages vim)
   #:use-module (gnu packages zip))
 
+(define-public avr-binutils
+  (package
+    (inherit (cross-binutils "avr"))
+    (name "avr-binutils")
+    (arguments
+     '(#:configure-flags '("--target=avr"
+                           "--disable-nls")))))
+
 (define-public avr-libc
   (package
     (name "avr-libc")
-- 
2.7.3

Re: [PATCH 1/5] gnu: Add avr-binutils.

[Ludovic Courtès]

David Thompson <dthompson2@worcester.edu> skribis:

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

[...]

> +(define-public avr-binutils
> +  (package
> +    (inherit (cross-binutils "avr"))
> +    (name "avr-binutils")
> +    (arguments
> +     '(#:configure-flags '("--target=avr"
> +                           "--disable-nls")))))

AFAICS --target=avr is redundant:

--8<---------------cut here---------------start------------->8---
$ git describe
v0.10.0-204-ga2d0e20
$ wget -q -O - $(./pre-inst-env guix build --log-file -e '((@ (gnu packages cross-base) cross-binutils) "avr")') |grep -e --target
configure flags: ("CONFIG_SHELL=/gnu/store/b1yqjimbdh5bf9jnizd4h7yf110744j2-bash-4.3.42/bin/bash" "SHELL=/gnu/store/b1yqjimbdh5bf9jnizd4h7yf110744j2-bash-4.3.42/bin/bash" "--prefix=/gnu/store/gqmq8gis9igpg4xy6022mvq8qpvp7kk4-binutils-cross-avr-2.25.1" "--enable-fast-install" "--build=x86_64-unknown-linux-gnu" "--target=avr" "--with-sysroot=/" "LDFLAGS=-static-libgcc" "--with-lib-path=/no-ld-lib-path" "--disable-werror" "--enable-install-libbfd" "--enable-deterministic-archives")
--8<---------------cut here---------------end--------------->8---

… and --disable-nls is orthogonal and probably unnecessary.

Can we skip this patch?  :-)

Ludo’.

Re: [PATCH 1/5] gnu: Add avr-binutils.

[Manolis Ragkousis]

Hey Ludo,

On 04/14/16 20:04, Ludovic Courtès wrote:

> AFAICS --target=avr is redundant:
> 
> --8<---------------cut here---------------start------------->8---
> $ git describe
> v0.10.0-204-ga2d0e20
> $ wget -q -O - $(./pre-inst-env guix build --log-file -e '((@ (gnu packages cross-base) cross-binutils) "avr")') |grep -e --target
> configure flags: ("CONFIG_SHELL=/gnu/store/b1yqjimbdh5bf9jnizd4h7yf110744j2-bash-4.3.42/bin/bash" "SHELL=/gnu/store/b1yqjimbdh5bf9jnizd4h7yf110744j2-bash-4.3.42/bin/bash" "--prefix=/gnu/store/gqmq8gis9igpg4xy6022mvq8qpvp7kk4-binutils-cross-avr-2.25.1" "--enable-fast-install" "--build=x86_64-unknown-linux-gnu" "--target=avr" "--with-sysroot=/" "LDFLAGS=-static-libgcc" "--with-lib-path=/no-ld-lib-path" "--disable-werror" "--enable-install-libbfd" "--enable-deterministic-archives")
> --8<---------------cut here---------------end--------------->8---
> 
> … and --disable-nls is orthogonal and probably unnecessary.
> 
> Can we skip this patch?  :-)

We added --disable-nls mostly because it was suggested from the avr-libc
manual to be passed to binutils and gcc.
<http://www.nongnu.org/avr-libc/user-manual/install_tools.html>

David can you build the toolchain without it and see if it works?

And I would really prefer if we had a way to explicitly install
avr-binutils.  This way it will be more clear to someone only wanting to
install this specific package.

We could keep something like this

(define-public avr-binutils
  (package
    (inherit (cross-binutils "avr"))
    (name "avr-binutils")))

Manolis

Re: [PATCH 1/5] gnu: Add avr-binutils.

[Ludovic Courtès]

Manolis Ragkousis <manolis837@gmail.com> skribis:

> On 04/14/16 20:04, Ludovic Courtès wrote:
>
>> AFAICS --target=avr is redundant:
>> 
>> --8<---------------cut here---------------start------------->8---
>> $ git describe
>> v0.10.0-204-ga2d0e20
>> $ wget -q -O - $(./pre-inst-env guix build --log-file -e '((@ (gnu packages cross-base) cross-binutils) "avr")') |grep -e --target
>> configure flags: ("CONFIG_SHELL=/gnu/store/b1yqjimbdh5bf9jnizd4h7yf110744j2-bash-4.3.42/bin/bash" "SHELL=/gnu/store/b1yqjimbdh5bf9jnizd4h7yf110744j2-bash-4.3.42/bin/bash" "--prefix=/gnu/store/gqmq8gis9igpg4xy6022mvq8qpvp7kk4-binutils-cross-avr-2.25.1" "--enable-fast-install" "--build=x86_64-unknown-linux-gnu" "--target=avr" "--with-sysroot=/" "LDFLAGS=-static-libgcc" "--with-lib-path=/no-ld-lib-path" "--disable-werror" "--enable-install-libbfd" "--enable-deterministic-archives")
>> --8<---------------cut here---------------end--------------->8---
>> 
>> … and --disable-nls is orthogonal and probably unnecessary.
>> 
>> Can we skip this patch?  :-)
>
> We added --disable-nls mostly because it was suggested from the avr-libc
> manual to be passed to binutils and gcc.
> <http://www.nongnu.org/avr-libc/user-manual/install_tools.html>
>
> David can you build the toolchain without it and see if it works?

It surely does.  :-)

> And I would really prefer if we had a way to explicitly install
> avr-binutils.  This way it will be more clear to someone only wanting to
> install this specific package.
>
> We could keep something like this
>
> (define-public avr-binutils
>   (package
>     (inherit (cross-binutils "avr"))
>     (name "avr-binutils")))

I see.  In that case, that’s a fine thing to do!

Maybe (define-public avr-binutils (cross-binutils "avr")) is enough
though?  Or is its name too wordy?

Thanks,
Ludo’.

Re: [PATCH 1/5] gnu: Add avr-binutils.

[Thompson, David]

On Tue, Apr 19, 2016 at 10:55 AM, Ludovic Courtès <ludo@gnu.org> wrote:
> Manolis Ragkousis <manolis837@gmail.com> skribis:
>
>> And I would really prefer if we had a way to explicitly install
>> avr-binutils.  This way it will be more clear to someone only wanting to
>> install this specific package.
>>
>> We could keep something like this
>>
>> (define-public avr-binutils
>>   (package
>>     (inherit (cross-binutils "avr"))
>>     (name "avr-binutils")))
>
> I see.  In that case, that’s a fine thing to do!
>
> Maybe (define-public avr-binutils (cross-binutils "avr")) is enough
> though?  Or is its name too wordy?

The name was too wordy, IMO, and it is nice to have consistency with
all the avr toolchain components prefixed with "avr-", so I've pushed
a patch that simply gives (cross-binutils "avr") a new name.

Thanks!

- Dave

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

[David Thompson]

* gnu/packages/avr.scm (avr-gcc): New variable.
---
 gnu/packages/avr.scm | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/gnu/packages/avr.scm b/gnu/packages/avr.scm
index b30c64e..0ec115e 100644
--- a/gnu/packages/avr.scm
+++ b/gnu/packages/avr.scm
@@ -20,6 +20,7 @@
 
 (define-module (gnu packages avr)
   #:use-module ((guix licenses) #:prefix license:)
+  #:use-module (guix utils)
   #:use-module (guix download)
   #:use-module (guix packages)
   #:use-module (guix build-system gnu)
@@ -36,6 +37,36 @@
      '(#:configure-flags '("--target=avr"
                            "--disable-nls")))))
 
+(define-public avr-gcc
+  (let ((xgcc (cross-gcc "avr" avr-binutils)))
+    (package
+      (inherit xgcc)
+      (name "avr-gcc")
+      (arguments
+       (substitute-keyword-arguments (package-arguments xgcc)
+         ((#:phases phases)
+          `(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"))))
+                 #t))))
+         ((#:configure-flags flags)
+          '(list "--target=avr"
+                 "--enable-languages=c,c++"
+                 "--disable-nls"
+                 "--disable-libssp"
+                 "--with-dwarf2"))))
+      (native-search-paths
+       (list (search-path-specification
+              (variable "CROSS_CPATH")
+              (files '("avr/include")))
+             (search-path-specification
+              (variable "CROSS_LIBRARY_PATH")
+              (files '("avr/lib"))))))))
+
 (define-public avr-libc
   (package
     (name "avr-libc")
-- 
2.7.3

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

[Manolis Ragkousis]

Hey David,

On 04/14/16 16:17, David Thompson wrote:
> +       (substitute-keyword-arguments (package-arguments xgcc)
> +         ((#:phases phases)
> +          `(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"))))
> +                 #t))))

I think we should add fix-genmultilib to one of the existing standard
phases because this problem appears to Ricardo's arm-none-eabi
cross-toolchain as well. All the cross-toolchains will benefit from this.

Other than that, we have a working toolchain at last :-D

Thank you,
Manolis

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

[Thompson, David]

On Thu, Apr 14, 2016 at 9:53 AM, Manolis Ragkousis <manolis837@gmail.com> wrote:
> Hey David,
>
> On 04/14/16 16:17, David Thompson wrote:
>> +       (substitute-keyword-arguments (package-arguments xgcc)
>> +         ((#:phases phases)
>> +          `(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"))))
>> +                 #t))))
>
> I think we should add fix-genmultilib to one of the existing standard
> phases because this problem appears to Ricardo's arm-none-eabi
> cross-toolchain as well. All the cross-toolchains will benefit from this.

I think that would be a good next step, after this patch set is merged.

- Dave

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

[Ludovic Courtès]

Manolis Ragkousis <manolis837@gmail.com> skribis:

> Hey David,
>
> On 04/14/16 16:17, David Thompson wrote:
>> +       (substitute-keyword-arguments (package-arguments xgcc)
>> +         ((#:phases phases)
>> +          `(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"))))
>> +                 #t))))
>
> I think we should add fix-genmultilib to one of the existing standard
> phases because this problem appears to Ricardo's arm-none-eabi
> cross-toolchain as well. All the cross-toolchains will benefit from this.

Agreed.  Could you prepare a patch for ‘core-updates’ that does this?

In the meantime we’ll add something along the lines of what David
posted in ‘master’.

Ludo’.

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

[Ludovic Courtès]

David Thompson <dthompson2@worcester.edu> 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’.

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

[Thompson, David]

On Thu, Apr 14, 2016 at 1:25 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> David Thompson <dthompson2@worcester.edu> 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?

It turns out that gcc/genmultilib is a script that generates many
scripts, and thus has many instances of #!/bin/sh in it.  So,
patch-shebang was inadequate for the job and I've stuck with the
original solution.

>> +         ((#: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?

I've removed all of these.

>> +      (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.

As explained in the thread about the avr-toolchain, this is a special
scenario because the only use for avr-gcc is to cross-compile and you
cannot actually port any part of Guix to the AVR architecture.  Maybe
there's still something to revisit later, but having a working AVR
toolchain is a big win for now.

Pushed with the other issues addressed.  Thanks!

- Dave

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

[Ludovic Courtès]

"Thompson, David" <dthompson2@worcester.edu> skribis:

> On Thu, Apr 14, 2016 at 1:25 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>> David Thompson <dthompson2@worcester.edu> 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?
>
> It turns out that gcc/genmultilib is a script that generates many
> scripts, and thus has many instances of #!/bin/sh in it.  So,
> patch-shebang was inadequate for the job and I've stuck with the
> original solution.

OK.

>>> +      (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.
>
> As explained in the thread about the avr-toolchain, this is a special
> scenario because the only use for avr-gcc is to cross-compile and you
> cannot actually port any part of Guix to the AVR architecture.  Maybe
> there's still something to revisit later, but having a working AVR
> toolchain is a big win for now.

Yes, makes sense.

> Pushed with the other issues addressed.  Thanks!

Thanks for this patch series!

Ludo’.

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

[Danny Milosavljevic]

Hi,

hmm, does avr-gcc work for anyone on Guix?

I tried to compile a simple Arduino project and I get:

/home/dannym/.guix-profile/bin/avr-g++ -x c++ -include Arduino.h -MMD -c -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=100 -DARDUINO_ARCH_AVR -D__PROG_TYPES_COMPAT__ -Iarduino-1.6.10/hardware/arduino/avr/cores/arduino -Iarduino-1.6.10/hardware/arduino/avr/variants/leonardo     -Iarduino-1.6.10/hardware/arduino/avr/libraries/SPI/src -Wall -ffunction-sections -fdata-sections -Os -DUSB_VID=0x2341 -DUSB_PID=0x8036 -fno-exceptions  main.ino -o build-leonardo/main.ino.o
In file included from /home/dannym/.guix-profile/include/features.h:389:0,
                 from /home/dannym/.guix-profile/include/stdlib.h:24,
                 from arduino-1.6.10/hardware/arduino/avr/cores/arduino/Arduino.h:23,
                 from <command-line>:0:
/home/dannym/.guix-profile/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
compilation terminated.

As you can see it tries to include the host system headers - which will not work.

I have the newest Git Guix.

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

[Ricardo Wurmus]

Danny Milosavljevic <dannym@scratchpost.org> writes:

> Hi,
>
> hmm, does avr-gcc work for anyone on Guix?
>
> I tried to compile a simple Arduino project and I get:
>
> /home/dannym/.guix-profile/bin/avr-g++ -x c++ -include Arduino.h -MMD -c -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=100 -DARDUINO_ARCH_AVR -D__PROG_TYPES_COMPAT__ -Iarduino-1.6.10/hardware/arduino/avr/cores/arduino -Iarduino-1.6.10/hardware/arduino/avr/variants/leonardo     -Iarduino-1.6.10/hardware/arduino/avr/libraries/SPI/src -Wall -ffunction-sections -fdata-sections -Os -DUSB_VID=0x2341 -DUSB_PID=0x8036 -fno-exceptions  main.ino -o build-leonardo/main.ino.o
> In file included from /home/dannym/.guix-profile/include/features.h:389:0,
>                  from /home/dannym/.guix-profile/include/stdlib.h:24,
>                  from arduino-1.6.10/hardware/arduino/avr/cores/arduino/Arduino.h:23,
>                  from <command-line>:0:
> /home/dannym/.guix-profile/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
> compilation terminated.
>
> As you can see it tries to include the host system headers - which will not work.
>
> I have the newest Git Guix.

Did you install the “avr-toolchain” package or just the “avr-gcc”?  I
had it working for me in the past after setting a couple of environment
variables (I think it was the “CROSS_*” family of variables), but I
don’t remember the details, unfortunately.

I find that this is true for a number of packages that need additional
configuration after installation.  Should application setup for
individual applications also be added to the manual?  Currently we do
have a section for application setup, but it’s only for generic things
like locale settings and ensuring that applications find certificates,
etc.

I wouldn’t like to have to dig out old emails on the mailing list
if I decide a few months from now to use AVR GCC again.

What do others think?

~~ Ricardo

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

[Danny Milosavljevic]

> Did you install the “avr-toolchain” package or just the “avr-gcc”? 

I have installed the package "avr-toolchain". The program "avr-gcc" is in my profile but I think it was not from the package avr-gcc.

$ ls -l /home/dannym/.guix-profile/bin/avr-gcc
lrwxrwxrwx 143 root guixbuild 69  1. Jan 1970  /home/dannym/.guix-profile/bin/avr-gcc -> /gnu/store/lhy6jlpwf92yknmfai3675lmr8bhc4jf-avr-gcc-5.3.0/bin/avr-gcc
$ guix package -r avr-gcc
nothing to be done
$ ls -l /home/dannym/.guix-profile/bin/avr-gcc
lrwxrwxrwx 143 root guixbuild 69  1. Jan 1970  /home/dannym/.guix-profile/bin/avr-gcc -> /gnu/store/lhy6jlpwf92yknmfai3675lmr8bhc4jf-avr-gcc-5.3.0/bin/avr-gcc

I've read through the mailing list but even the "-D__x86_64__" hack doesn't work anymore. Hmm...

> Should application setup for individual applications also be added to the manual?

In general yes - but I think avr-gcc is special in that it really doesn't need host system stuff at all. There should be no configuration necessary. (It is necessary, but it shouldn't be)

Also, I manually added avr/include and avr/lib as a workaround. This mostly works. However, when linking I get:
...
avr-ld: cannot find crtatmega32u4.o: No such file or directory
avr-ld: cannot find -latmega32u4

And indeed this crt doesn't exist at all.

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

[Danny Milosavljevic]

(The ones who are there:

~/.guix-profile/avr/lib$ ls -1 avr5/crt*
avr5/crt90pwm161.o
avr5/crt90pwm216.o
avr5/crt90pwm316.o
avr5/crt90scr100.o
avr5/crta5790n.o
avr5/crta5790.o
avr5/crta5795.o
avr5/crtat94k.o
avr5/crtcan32.o
avr5/crtcan64.o
avr5/crtm161.o
avr5/crtm162.o
avr5/crtm163.o
avr5/crtm164a.o
avr5/crtm164pa.o
avr5/crtm164p.o
avr5/crtm165a.o
avr5/crtm165.o
avr5/crtm165pa.o
avr5/crtm165p.o
avr5/crtm168a.o
avr5/crtm168.o
avr5/crtm168pa.o
avr5/crtm168p.o
avr5/crtm169a.o
avr5/crtm169.o
avr5/crtm169pa.o
avr5/crtm169p.o
avr5/crtm16a.o
avr5/crtm16hva2.o
avr5/crtm16hva.o
avr5/crtm16hvb.o
avr5/crtm16hvbrevb.o
avr5/crtm16m1.o
avr5/crtm16.o
avr5/crtm16u4.o
avr5/crtm3000.o
avr5/crtm323.o
avr5/crtm324a.o
avr5/crtm324pa.o
avr5/crtm324p.o
avr5/crtm3250a.o
avr5/crtm3250.o
avr5/crtm3250pa.o
avr5/crtm3250p.o
avr5/crtm325a.o
avr5/crtm325.o
avr5/crtm325p.o
avr5/crtm328.o
avr5/crtm328p.o
avr5/crtm3290a.o
avr5/crtm3290.o
avr5/crtm3290pa.o
avr5/crtm3290p.o
avr5/crtm329a.o
avr5/crtm329.o
avr5/crtm329pa.o
avr5/crtm329p.o
avr5/crtm32a.o
avr5/crtm32c1.o
avr5/crtm32hvb.o
avr5/crtm32hvbrevb.o
avr5/crtm32m1.o
avr5/crtm32.o
avr5/crtm32u4.o
avr5/crtm32u6.o
avr5/crtm406.o
avr5/crtm640.o
avr5/crtm644a.o
avr5/crtm644.o
avr5/crtm644pa.o
avr5/crtm644p.o
avr5/crtm6450a.o
avr5/crtm6450.o
avr5/crtm6450p.o
avr5/crtm645a.o
avr5/crtm645.o
avr5/crtm645p.o
avr5/crtm6490a.o
avr5/crtm6490.o
avr5/crtm6490p.o
avr5/crtm649a.o
avr5/crtm649.o
avr5/crtm649p.o
avr5/crtm64a.o
avr5/crtm64c1.o
avr5/crtm64hve.o
avr5/crtm64m1.o
avr5/crtm64.o
avr5/crtm64rfr2.o
avr5/crtusb646.o
avr5/crtusb647.o

)

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

[Ricardo Wurmus]

Danny Milosavljevic <dannym@scratchpost.org> writes:

>> Did you install the “avr-toolchain” package or just the “avr-gcc”? 
>
> I have installed the package "avr-toolchain". The program "avr-gcc" is in my profile but I think it was not from the package avr-gcc.
>
> $ ls -l /home/dannym/.guix-profile/bin/avr-gcc
> lrwxrwxrwx 143 root guixbuild 69  1. Jan 1970  /home/dannym/.guix-profile/bin/avr-gcc -> /gnu/store/lhy6jlpwf92yknmfai3675lmr8bhc4jf-avr-gcc-5.3.0/bin/avr-gcc
> $ guix package -r avr-gcc
> nothing to be done
> $ ls -l /home/dannym/.guix-profile/bin/avr-gcc
> lrwxrwxrwx 143 root guixbuild 69  1. Jan 1970  /home/dannym/.guix-profile/bin/avr-gcc -> /gnu/store/lhy6jlpwf92yknmfai3675lmr8bhc4jf-avr-gcc-5.3.0/bin/avr-gcc
>
> I've read through the mailing list but even the "-D__x86_64__" hack doesn't work anymore. Hmm...
>
>> Should application setup for individual applications also be added to the manual?
>
> In general yes - but I think avr-gcc is special in that it really doesn't need host system stuff at all. There should be no configuration necessary. (It is necessary, but it shouldn't be)
>
> Also, I manually added avr/include and avr/lib as a workaround. This mostly works. However, when linking I get:

I’m pretty sure I didn’t have to do this.  Instead it was sufficient to
set a couple of environment variables.  The effect is the same, though.

> ...
> avr-ld: cannot find crtatmega32u4.o: No such file or directory
> avr-ld: cannot find -latmega32u4
>
> And indeed this crt doesn't exist at all.

I encountered the same issue last time I used avr-gcc.  This hasn’t
always been like this.  If I recall correctly the names of the crt files
changed after we enabled multilib support.

Maybe Dave knows more about this?

~~ Ricardo

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

[Thompson, David]

On Wed, Aug 10, 2016 at 3:52 AM, Ricardo Wurmus
<ricardo.wurmus@mdc-berlin.de> wrote:
>
> Maybe Dave knows more about this?

I haven't had time to look into anything, but last I checked I was
able to successfully compile the firmware I'm interested in with
avr-toolchain.

- Dave

[PATCH] gnu: avr: Use the correct gcc version as native-input. This makes crtatmega32u4.o etc appear in the output.

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 602 bytes --]


See also <http://svn.savannah.nongnu.org/viewvc?view=rev&root=avr-libc&revision=2475>, <http://svn.savannah.nongnu.org/viewvc/trunk/avr-libc/libc/misc/Rules.am?root=avr-libc&r1=2475&r2=2474&pathrev=2475>.

The easy fix would have been to pass "--enable-device-lib" to libc's configure.
The right fix: use the right gcc as native input.

* gnu/packages/avr.scm (avr-libc): Replace package by function.
* gnu/packages/avr.scm (avr-toolchain): Use new avr-libc function.
---
 gnu/packages/avr.scm | 37 ++++++++++++++++++++-----------------
 1 file changed, 20 insertions(+), 17 deletions(-)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-gnu-avr-Use-the-correct-gcc-version-as-native-input..patch --]
[-- Type: text/x-patch; name="0001-gnu-avr-Use-the-correct-gcc-version-as-native-input..patch", Size: 2620 bytes --]

diff --git a/gnu/packages/avr.scm b/gnu/packages/avr.scm
index 9873477..fd18ff6 100644
--- a/gnu/packages/avr.scm
+++ b/gnu/packages/avr.scm
@@ -73,7 +73,7 @@
     (version (package-version gcc-5))
     (source (package-source gcc-5))))
 
-(define-public avr-libc
+(define (avr-libc avr-gcc)
   (package
     (name "avr-libc")
     (version "2.0.0")
@@ -99,7 +99,7 @@
              (unsetenv "C_INCLUDE_PATH")
              #t)))))
     (native-inputs `(("avr-binutils" ,avr-binutils)
-                     ("avr-gcc" ,avr-gcc-4.9)))
+                     ("avr-gcc" ,avr-gcc)))
     (home-page "http://www.nongnu.org/avr-libc/")
     (synopsis "The AVR C Library")
     (description
@@ -109,24 +109,27 @@ for use with GCC on Atmel AVR microcontrollers.")
      (license:non-copyleft "http://www.nongnu.org/avr-libc/LICENSE.txt"))))
 
 (define (avr-toolchain avr-gcc)
-  (package
-    (name "avr-toolchain")
-    (version (package-version avr-gcc))
-    (source #f)
-    (build-system trivial-build-system)
-    (arguments '(#:builder (mkdir %output)))
-    (propagated-inputs
-     `(("avrdude" ,avrdude)
-       ("binutils" ,avr-binutils)
-       ("gcc" ,avr-gcc)
-       ("libc" ,avr-libc)))
-    (synopsis "Complete GCC tool chain for AVR microcontroller development")
-    (description "This package provides a complete GCC tool chain for AVR
+  ;; avr-libc checks the compiler version and passes "--enable-device-lib" for avr-gcc > 5.1.0.
+  ;; It wouldn't install the library for atmega32u4 etc if we didn't use the corret avr-gcc.
+  (let ((avr-libc (avr-libc avr-gcc)))
+    (package
+      (name "avr-toolchain")
+      (version (package-version avr-gcc))
+      (source #f)
+      (build-system trivial-build-system)
+      (arguments '(#:builder (mkdir %output)))
+      (propagated-inputs
+       `(("avrdude" ,avrdude)
+         ("binutils" ,avr-binutils)
+         ("gcc" ,avr-gcc)
+         ("libc" ,avr-libc)))
+      (synopsis "Complete GCC tool chain for AVR microcontroller development")
+      (description "This package provides a complete GCC tool chain for AVR
 microcontroller development.  This includes the GCC AVR cross compiler and
 avrdude for firmware flashing.  The supported programming languages are C and
 C++.")
-    (home-page (package-home-page avr-libc))
-    (license (package-license avr-gcc))))
+      (home-page (package-home-page avr-libc))
+      (license (package-license avr-gcc)))))
 
 (define-public avr-toolchain-4.9 (avr-toolchain avr-gcc-4.9))
 (define-public avr-toolchain-5 (avr-toolchain avr-gcc-5))

Re: [PATCH] gnu: avr: Use the correct gcc version as native-input. This makes crtatmega32u4.o etc appear in the output.

[Thompson, David]

On Mon, Aug 15, 2016 at 6:45 AM, Danny Milosavljevic
<dannym@scratchpost.org> wrote:
>
> See also <http://svn.savannah.nongnu.org/viewvc?view=rev&root=avr-libc&revision=2475>, <http://svn.savannah.nongnu.org/viewvc/trunk/avr-libc/libc/misc/Rules.am?root=avr-libc&r1=2475&r2=2474&pathrev=2475>.
>
> The easy fix would have been to pass "--enable-device-lib" to libc's configure.
> The right fix: use the right gcc as native input.
>
> * gnu/packages/avr.scm (avr-libc): Replace package by function.
> * gnu/packages/avr.scm (avr-toolchain): Use new avr-libc function.

Ah, good catch!  LGTM.

Could someone with commit access apply this?  I'm currently unable to do it.

- Dave

Re: [PATCH] gnu: avr: Use the correct gcc version as native-input. This makes crtatmega32u4.o etc appear in the output.

[Leo Famulari]

On Mon, Aug 15, 2016 at 07:34:19AM -0400, Thompson, David wrote:
> On Mon, Aug 15, 2016 at 6:45 AM, Danny Milosavljevic
> <dannym@scratchpost.org> wrote:
> >
> > See also <http://svn.savannah.nongnu.org/viewvc?view=rev&root=avr-libc&revision=2475>, <http://svn.savannah.nongnu.org/viewvc/trunk/avr-libc/libc/misc/Rules.am?root=avr-libc&r1=2475&r2=2474&pathrev=2475>.
> >
> > The easy fix would have been to pass "--enable-device-lib" to libc's configure.
> > The right fix: use the right gcc as native input.
> >
> > * gnu/packages/avr.scm (avr-libc): Replace package by function.
> > * gnu/packages/avr.scm (avr-toolchain): Use new avr-libc function.
> 
> Ah, good catch!  LGTM.
> 
> Could someone with commit access apply this?  I'm currently unable to do it.

Pushed as 4d2470b0efb.

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

[Danny Milosavljevic]

Hi,

when I apply my patch and then modify my Makefile to also say:

CPPFLAGS += -I${HOME}/.guix-profile/avr/include -L${HOME}/.guix-profile/avr/lib/avr5 -L${HOME}/.guix-profile/avr/lib -B${HOME}/.guix-profile/avr/lib
CPPFLAGS += -I.. 

then for Arduino (after applying my patch) I still get:

PluggableUSB.cpp:(.text._Z12PluggableUSBv+0xc): undefined reference to `__cxa_guard_acquire'
PluggableUSB.cpp:(.text._Z12PluggableUSBv+0x2c): undefined reference to `__cxa_guard_release'

This is because it uses (see <https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/cores/arduino/PluggableUSB.cpp#L102>):

PluggableUSB_& PluggableUSB()
{
	static PluggableUSB_ obj; /* editor's note: uh oh!! */
        return obj;
}

It works just fine (it also links fine; everything OK) when I change it to:

static PluggableUSB_ obj;

PluggableUSB_& PluggableUSB()
{
        return obj;
}

Should that have worked as-is?

Also, why is avr-gcc also setting native-search-paths (even though it's a cross compiler)? Doesn't seem to make a difference and is also rather strange...

What does the search-paths form do? Does it set environment variables in the profile as well?

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

[Thompson, David]

On Mon, Aug 15, 2016 at 7:59 AM, Danny Milosavljevic
<dannym@scratchpost.org> wrote:

> What does the search-paths form do? Does it set environment variables in the profile as well?

Search path information is used in build environments (guix build),
user-defined environments (guix environment), and profiles (guix
package).  For example, when you run 'guix package --search-paths',
the environment variables printed are determined by the
native-search-paths field for each package in your profile.

I found that without CROSS_CPATH and CROSS_LIBRARY_PATH the compiler
doesn't work because it can't find all of its headers and libraries
since they aren't in /usr.

Some background: avr-gcc was broken for a very long time, until
Manolis, Ricardo, and I worked out the problems several months ago.  I
tested avr-gcc by successfully compiling the various KADE miniArcade
firmwares using the 'make-all.sh' script found here:
https://github.com/kadevice/KADE/tree/master/open%20software/firmwares/KADE%20miniArcade/sources

I don't know what has changed since I got things working, but I can no
longer compile that firmware.  I get errors like this:

    main.c:38:20: fatal error: avr/io.h: No such file or directory

- Dave

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

[Danny Milosavljevic]

> I don't know what has changed since I got things working, but I can no
> longer compile that firmware.  I get errors like this:
> 
>     main.c:38:20: fatal error: avr/io.h: No such file or directory

There was a change in cross-base. We don't use CROSS_CPATH anymore. However, avr-gcc does use it (and shouldn't).

(define* (cross-gcc ...
...
    ;; Only search target inputs, not host inputs.
    ;; Note: See <http://bugs.gnu.org/22186> for why not 'CPATH'.
    (search-paths
     (list (search-path-specification
            (variable "CROSS_C_INCLUDE_PATH")
            (files '("include")))
           (search-path-specification
            (variable "CROSS_CPLUS_INCLUDE_PATH")
            (files '("include")))
           (search-path-specification
            (variable "CROSS_OBJC_INCLUDE_PATH")
            (files '("include")))
           (search-path-specification
            (variable "CROSS_OBJCPLUS_INCLUDE_PATH")
            (files '("include")))
           (search-path-specification
            (variable "CROSS_LIBRARY_PATH")
            (files '("lib" "lib64")))))
    (native-search-paths '())))

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

[Vincent Legoll]

> Did you install the “avr-toolchain” package or just the “avr-gcc”?  I
> had it working for me in the past after setting a couple of environment
> variables (I think it was the “CROSS_*” family of variables), but I
> don’t remember the details, unfortunately.

I think this is a recurring problem for beginners that come from other
distributions, maybe it's just a naming problem... This is non-obvious.

Maybe adding a hint when people install $COMPILER, that tell them to
look for $COMPILER-toolchain...

-- 
Vincent Legoll

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

[Ricardo Wurmus]

Vincent Legoll <vincent.legoll@gmail.com> writes:

>> Did you install the “avr-toolchain” package or just the “avr-gcc”?  I
>> had it working for me in the past after setting a couple of environment
>> variables (I think it was the “CROSS_*” family of variables), but I
>> don’t remember the details, unfortunately.
>
> I think this is a recurring problem for beginners that come from other
> distributions, maybe it's just a naming problem... This is non-obvious.

Indeed!

> Maybe adding a hint when people install $COMPILER, that tell them to
> look for $COMPILER-toolchain...

Or maybe we should hide these packages?  They could still be used in
manifests and in other packages, but they shouldn’t appear in
other interfaces such as the command line output.

~~ Ricardo

[PATCH 3/5] gnu: avr-libc: Fix build.

[David Thompson]

* gnu/packages/avr.scm (avr-libc): Update to 2.0.0.
[native-inputs]: Use new avr-gcc and avr-binutils.
[arguments]: Add phase to unset C_INCLUDE_PATH.
---
 gnu/packages/avr.scm | 32 +++++++++++++++++++++-----------
 1 file changed, 21 insertions(+), 11 deletions(-)

diff --git a/gnu/packages/avr.scm b/gnu/packages/avr.scm
index 0ec115e..81ca162 100644
--- a/gnu/packages/avr.scm
+++ b/gnu/packages/avr.scm
@@ -70,28 +70,38 @@
 (define-public avr-libc
   (package
     (name "avr-libc")
-    (version "1.8.1")
+    (version "2.0.0")
     (source (origin
               (method url-fetch)
-              (uri (string-append
-                    "mirror://savannah//avr-libc/avr-libc-"
-                    version ".tar.bz2"))
+              (uri (string-append "mirror://savannah//avr-libc/avr-libc-"
+                                  version ".tar.bz2"))
               (sha256
                (base32
-                "0sd9qkvhmk9av4g1f8dsjwc309hf1g0731bhvicnjb3b3d42l1n3"))))
+                "15svr2fx8j6prql2il2fc0ppwlv50rpmyckaxx38d3gxxv97zpdj"))))
     (build-system gnu-build-system)
     (arguments
-     `(#:out-of-source? #t
-       #:configure-flags '("--host=avr")))
-
-    (native-inputs `(("cross-binutils" ,(cross-binutils "avr"))
-                     ("cross-gcc" ,xgcc-avr)))
+     '(#:out-of-source? #t
+       #:configure-flags '("--host=avr")
+       #:phases
+       (modify-phases %standard-phases
+         (add-before 'unpack 'fix-cpath
+           (lambda _
+             ;; C_INCLUDE_PATH poses issues for cross-building, leading to
+             ;; failures when building avr-libc on 64-bit systems.  Simply
+             ;; unsetting it allows the build to succeed because it doesn't
+             ;; try to use any of the native system's headers.
+             (unsetenv "C_INCLUDE_PATH")
+             #t)))))
+    (native-inputs `(("avr-binutils" ,avr-binutils)
+                     ("avr-gcc" ,avr-gcc)))
     (home-page "http://www.nongnu.org/avr-libc/")
     (synopsis "The AVR C Library")
     (description
      "AVR Libc is a project whose goal is to provide a high quality C library
 for use with GCC on Atmel AVR microcontrollers.")
-    (license (license:non-copyleft "http://www.nongnu.org/avr-libc/LICENSE.txt"))))
+    (license
+     (license:non-copyleft "http://www.nongnu.org/avr-libc/LICENSE.txt"))))
+
 
 (define-public microscheme
   (package
-- 
2.7.3

Re: [PATCH 3/5] gnu: avr-libc: Fix build.

[Manolis Ragkousis]

On 04/14/16 16:17, David Thompson wrote:
> +       (modify-phases %standard-phases
> +         (add-before 'unpack 'fix-cpath
> +           (lambda _
> +             ;; C_INCLUDE_PATH poses issues for cross-building, leading to
> +             ;; failures when building avr-libc on 64-bit systems.  Simply
> +             ;; unsetting it allows the build to succeed because it doesn't
> +             ;; try to use any of the native system's headers.
> +             (unsetenv "C_INCLUDE_PATH")
> +             #t)))))

Currently I am building it on arm to see if it works there as well.

The reason why this works is because avr-gcc has it's own definition of
limits.h and it uses that when glibc is not present.

Manolis

Re: [PATCH 3/5] gnu: avr-libc: Fix build.

[Ludovic Courtès]

David Thompson <dthompson2@worcester.edu> skribis:

> * gnu/packages/avr.scm (avr-libc): Update to 2.0.0.
> [native-inputs]: Use new avr-gcc and avr-binutils.
> [arguments]: Add phase to unset C_INCLUDE_PATH.

Please make the update a separate patch, which you can push right away.
;-)

I think the rest won’t be needed given my comments on patch #2.

Ludo’.

Re: [PATCH 3/5] gnu: avr-libc: Fix build.

[Thompson, David]

On Thu, Apr 14, 2016 at 1:26 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> David Thompson <dthompson2@worcester.edu> skribis:
>
>> * gnu/packages/avr.scm (avr-libc): Update to 2.0.0.
>> [native-inputs]: Use new avr-gcc and avr-binutils.
>> [arguments]: Add phase to unset C_INCLUDE_PATH.
>
> Please make the update a separate patch, which you can push right away.
> ;-)

I don't see why I should push that separately given that avr-libc has
been broken for a long time.

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=23115

I can just not update it here at all and get everything fixed first.

- Dave

Re: [PATCH 3/5] gnu: avr-libc: Fix build.

[Ludovic Courtès]

"Thompson, David" <dthompson2@worcester.edu> skribis:

> On Thu, Apr 14, 2016 at 1:26 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>> David Thompson <dthompson2@worcester.edu> skribis:
>>
>>> * gnu/packages/avr.scm (avr-libc): Update to 2.0.0.
>>> [native-inputs]: Use new avr-gcc and avr-binutils.
>>> [arguments]: Add phase to unset C_INCLUDE_PATH.
>>
>> Please make the update a separate patch, which you can push right away.
>> ;-)
>
> I don't see why I should push that separately given that avr-libc has
> been broken for a long time.
>
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=23115
>
> I can just not update it here at all and get everything fixed first.

OK, I had overlooked that.  Your call!

Ludo’.

Re: [PATCH 3/5] gnu: avr-libc: Fix build.

[Thompson, David]

On Fri, Apr 15, 2016 at 5:12 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> "Thompson, David" <dthompson2@worcester.edu> skribis:
>
>> On Thu, Apr 14, 2016 at 1:26 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>>> David Thompson <dthompson2@worcester.edu> skribis:
>>>
>>>> * gnu/packages/avr.scm (avr-libc): Update to 2.0.0.
>>>> [native-inputs]: Use new avr-gcc and avr-binutils.
>>>> [arguments]: Add phase to unset C_INCLUDE_PATH.
>>>
>>> Please make the update a separate patch, which you can push right away.
>>> ;-)
>>
>> I don't see why I should push that separately given that avr-libc has
>> been broken for a long time.
>>
>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=23115
>>
>> I can just not update it here at all and get everything fixed first.
>
> OK, I had overlooked that.  Your call!

I decided to push the build fix and the version bump as two separate commits.

Thanks!

- Dave

[PATCH 4/5] gnu: Add avr-toolchain.

[David Thompson]

* gnu/packages/avr.scm (avr-toolchain): New variable.
---
 gnu/packages/avr.scm | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/gnu/packages/avr.scm b/gnu/packages/avr.scm
index 81ca162..94776d8 100644
--- a/gnu/packages/avr.scm
+++ b/gnu/packages/avr.scm
@@ -24,8 +24,10 @@
   #:use-module (guix download)
   #:use-module (guix packages)
   #:use-module (guix build-system gnu)
+  #:use-module (guix build-system trivial)
   #:use-module (gnu packages)
   #:use-module (gnu packages cross-base)
+  #:use-module (gnu packages flashing-tools)
   #:use-module (gnu packages vim)
   #:use-module (gnu packages zip))
 
@@ -102,6 +104,25 @@ for use with GCC on Atmel AVR microcontrollers.")
     (license
      (license:non-copyleft "http://www.nongnu.org/avr-libc/LICENSE.txt"))))
 
+(define-public avr-toolchain
+  (package
+    (name "avr-toolchain")
+    (version (package-version avr-gcc))
+    (source #f)
+    (build-system trivial-build-system)
+    (arguments '(#:builder (mkdir %output)))
+    (propagated-inputs
+     `(("avrdude" ,avrdude)
+       ("binutils" ,avr-binutils)
+       ("gcc" ,avr-gcc)
+       ("libc" ,avr-libc)))
+    (synopsis "Complete GCC tool chain for AVR microcontroller development")
+    (description "This package provides a complete GCC tool chain for AVR
+microcontroller development.  This includes the GCC AVR cross compiler and
+avrdude for firmware flashing.  The supported programming languages are C and
+C++.")
+    (home-page (package-home-page avr-libc))
+    (license (package-license avr-gcc))))
 
 (define-public microscheme
   (package
-- 
2.7.3

Re: [PATCH 4/5] gnu: Add avr-toolchain.

[Ludovic Courtès]

David Thompson <dthompson2@worcester.edu> skribis:

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

I’m guessing that the goal is to allow users to install it in a profile
and build stuff interactively from there, right?

However, profiles currently contain only native packages; patch #2 moves
’search-paths’ to ‘native-search-paths’, which in part is a way to work
around this limitation.

I think a better solution would be to allow users to build profiles that
contain non-native packages.  That way, we could do things like:

  guix environment --target=avr foo

Thoughts?

Until this is possible, we could apply this patch with the added
search-paths/native-search-paths hack (assuming said hack has been
removed from patch #2.)

Does it makes sense?

Thanks,
Ludo’.

Re: [PATCH 4/5] gnu: Add avr-toolchain.

[Thompson, David]

Reviving this old thread.

On Thu, Apr 14, 2016 at 1:33 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> David Thompson <dthompson2@worcester.edu> skribis:
>
>> * gnu/packages/avr.scm (avr-toolchain): New variable.
>
> I’m guessing that the goal is to allow users to install it in a profile
> and build stuff interactively from there, right?
>
> However, profiles currently contain only native packages; patch #2 moves
> ’search-paths’ to ‘native-search-paths’, which in part is a way to work
> around this limitation.
>
> I think a better solution would be to allow users to build profiles that
> contain non-native packages.  That way, we could do things like:
>
>   guix environment --target=avr foo
>
> Thoughts?
>
> Until this is possible, we could apply this patch with the added
> search-paths/native-search-paths hack (assuming said hack has been
> removed from patch #2.)
>
> Does it makes sense?

We discussed this on IRC quite awhile back, and the conclusion was
that this didn't make sense because compiling for AVR isn't like
compiling for an architecture like x86 or MIPS because you cannot
actually run any "normal" software on an AVR.  They are very
special-purpose, 8-bit processors with a limited amount of resources
and can not run GNU/Linux.  Thus, the only way that one would want to
use avr-gcc is to have it compiled for their workstation's
architecture so that they can cross-compile AVR firmware.

I think the native-search-paths make sense for this use-case.  With
this toolchain I've once again been able to build the firmware for my
arcade stick.

Without further ado, I will push this.

- Dave

[PATCH 5/5] gnu: Remove xgcc-avr.

[David Thompson]

We now have a dedicated package module for the AVR toolchain with
important modifications on top of what cross-gcc produces.

* gnu/packages/cross-base.scm (xgcc-avr): Delete.
---
 gnu/packages/cross-base.scm | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/gnu/packages/cross-base.scm b/gnu/packages/cross-base.scm
index aa67d21..9b97e75 100644
--- a/gnu/packages/cross-base.scm
+++ b/gnu/packages/cross-base.scm
@@ -352,12 +352,6 @@ XBINUTILS and the cross tool chain."
                                (package-supported-systems xgcc)
                                '("mips64el-linux" "i686-linux"))))))
 
-(define-public xgcc-avr
-  ;; AVR cross-compiler, used to build AVR-Libc.
-  (let ((triplet "avr"))
-    (cross-gcc triplet
-               (cross-binutils triplet))))
-
 (define-public xgcc-xtensa
   ;; Bare-bones Xtensa cross-compiler, used to build the Atheros firmware.
   (cross-gcc "xtensa-elf"))
-- 
2.7.3