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

[Thompson, David]

On Mon, Aug 15, 2016 at 7:59 AM, Danny Milosavljevic
 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]

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 
):

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 Wed, Aug 10, 2016 at 3:52 AM, Ricardo Wurmus
 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

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

[Ricardo Wurmus]

Vincent Legoll  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

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]

Danny Milosavljevic  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.

[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.

[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.

[Ricardo Wurmus]

Danny Milosavljevic  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=1600L -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 :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]

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=1600L -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 :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.

[Ludovic Courtès]

"Thompson, David"  skribis:

> On Thu, Apr 14, 2016 at 1:25 PM, Ludovic Courtès  wrote:
>> David Thompson  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.

[Thompson, David]

On Thu, Apr 14, 2016 at 1:25 PM, Ludovic Courtès  wrote:
> David Thompson  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]

David Thompson  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.

[Ludovic Courtès]

Manolis Ragkousis  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.

[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  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

[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