avr-gcc

avr-gcc

[Ricardo Wurmus]

Hi Guix,

I’ve been wanting to use microscheme to do fun things with my AVR
microcontrollers.  Sadly, I haven’t been able to make the combination of
microscheme, avrdude, and avr-gcc work.

Here’s what I did first:

    guix package -i microscheme avrdude gcc-cross-sans-libc-avr avr-libc

The microscheme package includes some examples, so I tried to compile
and upload the BLINK example:

~~~~~~~~~~~~~~~
rekado@banana ~ $ microscheme -a -u -m UNO -d /dev/bus/usb/006/004 microscheme-0.9.2/examples/BLINK.ms 
Microscheme 0.9.2, (C) Ryan Suchocki
>> Treeshaker: After 4 rounds: 87 globals purged! 22 bytes will be reserved.
>> 18 lines compiled OK
>> Assembling...
avr-ld: cannot open linker script file ldscripts/avr5.xn: No such file or directory
collect2: error: ld returned 1 exit status
>> Warning: Command may have failed. (Exit code 256)
sh: avr-objcopy: command not found
>> Warning: Command may have failed. (Exit code 32512)
...
~~~~~~~~~~~~~~~

So, a problem with a linker script that cannot be found and a missing
avr-objcopy.  I found them in the binutils-cross-avr output in the
store, but since there’s no separate package for this I installed it
like this:

    guix package -i /gnu/store/5f7pp8r9wpwzsf61cf406xb1hkad2cdi-binutils-cross-avr-2.25.1

Now running microscheme again produces this:

~~~~~~~~~~~~~~~
Microscheme 0.9.2, (C) Ryan Suchocki
>> Treeshaker: After 4 rounds: 87 globals purged! 22 bytes will be reserved.
>> 18 lines compiled OK
>> Assembling...
avr-ld: cannot find crtm328p.o: No such file or directory
avr-ld: cannot find -lm
avr-ld: cannot find -lc
collect2: error: ld returned 1 exit status
>> Warning: Command may have failed. (Exit code 256)
avr-objcopy: 'BLINK.elf': No such file
>> Warning: Command may have failed. (Exit code 256)
>> Uploading...
avrdude: ser_open(): can't set attributes for device "/dev/bus/usb/006/004": Inappropriate ioctl for device

avrdude done.  Thank you.

>> Warning: Command may have failed. (Exit code 256)
>> Finished.
~~~~~~~~~~~~~~~

There are multiple copies of “libm.a” and “libc.a” and there’s a
“crtm328p.o” as well somewhere below the “avr/lib/” directory in the
output of the avr-libc package.  Even after adding these paths to
LIBRARY_PATH, however, I cannot seem to fix the linker errors above.
Then I realised that LIBRARY_PATH only works for native compilers, and
that I would need to pass flags to the compiler (“-L”, maybe?).

But this all seems very wrong.  How can we fix this elegantly?  Does
microscheme’s call to avr-gcc need to be patched to “-L” the avr-libc
path?  Or does avr-gcc need fixing?  Or something else entirely?

~~ Ricardo

Re: avr-gcc

[Ricardo Wurmus]

Ricardo Wurmus <rekado@elephly.net> writes:

> I’ve been wanting to use microscheme to do fun things with my AVR
> microcontrollers.  Sadly, I haven’t been able to make the combination of
> microscheme, avrdude, and avr-gcc work.

[...]

> There are multiple copies of “libm.a” and “libc.a” and there’s a
> “crtm328p.o” as well somewhere below the “avr/lib/” directory in the
> output of the avr-libc package.  Even after adding these paths to
> LIBRARY_PATH, however, I cannot seem to fix the linker errors above.
> Then I realised that LIBRARY_PATH only works for native compilers, and
> that I would need to pass flags to the compiler (“-L”, maybe?).
>
> But this all seems very wrong.  How can we fix this elegantly?  Does
> microscheme’s call to avr-gcc need to be patched to “-L” the avr-libc
> path?  Or does avr-gcc need fixing?  Or something else entirely?

I first looked at how to fix this inelegantly.  “crtm328p.o” cannot be
found no matter what I did, so I copied it from the store to the current
directory:

~~~~~~~~~~~~
rekado@banana ~ $ cp /gnu/store/b8p4kkhcly7k5klnrzxmql35d541xhgq-avr-libc-1.8.1/avr/lib/avr5/crtm328p.o .
~~~~~~~~~~~~

Then I discovered microscheme’s “-w” flag which lets me paste stuff to
the end of the call to avr-gcc.  I abuse it to add the avr-libc lib
directory containing “libc.a” and “libm.a”:

~~~~~~~~~~~~
rekado@banana ~ $ microscheme -a -u -m UNO -d /dev/bus/usb/006/004 -w "-L/gnu/store/b8p4kkhcly7k5klnrzxmql35d541xhgq-avr-libc-1.8.1/avr/lib/avr5/" microscheme/examples/BLINK.ms 
Microscheme 0.9.2, (C) Ryan Suchocki
>> Treeshaker: After 4 rounds: 87 globals purged! 22 bytes will be reserved.
>> 18 lines compiled OK
>> Assembling...
>> Uploading...
avrdude: ser_open(): can't set attributes for device "/dev/bus/usb/006/004": Inappropriate ioctl for device

avrdude done.  Thank you.

>> Warning: Command may have failed. (Exit code 256)
>> Finished.
~~~~~~~~~~~~

Yes!  It actually assembled the example!

(Uploading fails, of course, because I shouldn’t try to write to a raw
USB device.  For some reason the AVRISPmkII USB programming device
doesn’t appear as a regular serial device, so some more work is needed
here.)

So, back to the original question: how could we fix this in an elegant
manner?  This hack will last me for some tests, but it feels really
icky.

~~ Ricardo

Re: avr-gcc

[Ludovic Courtès]

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

Ricardo Wurmus <rekado@elephly.net> skribis:

> So, a problem with a linker script that cannot be found and a missing
> avr-objcopy.  I found them in the binutils-cross-avr output in the
> store, but since there’s no separate package for this I installed it
> like this:
>
>     guix package -i /gnu/store/5f7pp8r9wpwzsf61cf406xb1hkad2cdi-binutils-cross-avr-2.25.1

If needed, you could add one such package to ‘cross-base.scm’.
Currently there are only full-blown cross-GCCs there, but if adding a
cross-binutils is useful, go for it.

> Microscheme 0.9.2, (C) Ryan Suchocki
>>> Treeshaker: After 4 rounds: 87 globals purged! 22 bytes will be reserved.
>>> 18 lines compiled OK
>>> Assembling...
> avr-ld: cannot find crtm328p.o: No such file or directory
> avr-ld: cannot find -lm
> avr-ld: cannot find -lc

In GCC we modify the spec file so that the right -L/libc/dir/name is
passed to ld; see (gnu packages gcc), ‘GNU_USER_TARGET_LIB_SPEC’.

However, ‘gcc-cross-sans-libc-avr’ is a bare-bones compiler, so it
doesn’t get the -L flag in question since there’s no libc to link to.

To get a full-blow compiler that uses avr-libc, you could start from
this:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 582 bytes --]

diff --git a/gnu/packages/avr.scm b/gnu/packages/avr.scm
index d59816b..8e9f172 100644
--- a/gnu/packages/avr.scm
+++ b/gnu/packages/avr.scm
@@ -53,6 +53,13 @@
 for use with GCC on Atmel AVR microcontrollers.")
     (license (license:non-copyleft "http://www.nongnu.org/avr-libc/LICENSE.txt"))))
 
+(define-public xgcc-avr-avrlibc
+  ;; AVR cross-compiler, used to build AVR-Libc.
+  (let ((triplet "avr-linux-avrlibc"))
+    (cross-gcc triplet
+               (cross-binutils triplet)
+               avr-libc)))
+
 (define-public microscheme
   (package
     (name "microscheme")

[-- Attachment #3: Type: text/plain, Size: 624 bytes --]


… and then address any glibc assumptions you encounter.

> There are multiple copies of “libm.a” and “libc.a” and there’s a
> “crtm328p.o” as well somewhere below the “avr/lib/” directory in the
> output of the avr-libc package.  Even after adding these paths to
> LIBRARY_PATH, however, I cannot seem to fix the linker errors above.
> Then I realised that LIBRARY_PATH only works for native compilers, and
> that I would need to pass flags to the compiler (“-L”, maybe?).

Maybe microsheme should have avr-gcc and avr-libc as propagated inputs
or something like that?

HTH,
Ludo’.

Re: avr-gcc

[Thompson, David]

On Tue, Nov 17, 2015 at 4:32 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> Ricardo Wurmus <rekado@elephly.net> skribis:
>
>> Microscheme 0.9.2, (C) Ryan Suchocki
>>>> Treeshaker: After 4 rounds: 87 globals purged! 22 bytes will be reserved.
>>>> 18 lines compiled OK
>>>> Assembling...
>> avr-ld: cannot find crtm328p.o: No such file or directory
>> avr-ld: cannot find -lm
>> avr-ld: cannot find -lc
>
> In GCC we modify the spec file so that the right -L/libc/dir/name is
> passed to ld; see (gnu packages gcc), ‘GNU_USER_TARGET_LIB_SPEC’.
>
> However, ‘gcc-cross-sans-libc-avr’ is a bare-bones compiler, so it
> doesn’t get the -L flag in question since there’s no libc to link to.
>
> To get a full-blow compiler that uses avr-libc, you could start from
> this:
>
>
>
> … and then address any glibc assumptions you encounter.

I tried to do this, but I don't really know what I'm doing.  The first
problem I encountered was that I needed to add a case to the
'glibc-dynamic-linker' procedure in (gnu packages bootstrap).  I
didn't know what ld was needed, if any, so I added this case:

    ((string=? system "avr-avrlibc") "no-ld.so")

Then, the issue was that avr-libc doesn't have a propagated input with
the label "linux-headers", as required by 'cross-gcc' in (gnu packages
cross-base).  So, as a hack I tried something like this:

    (if (string=? "avr-libc" (package-name libc))
                           `()
                           `(("xlinux-headers" ;the target headers
                              ,@(assoc-ref (package-propagated-inputs libc)
                                           "linux-headers"))))

Now I was able to get the build process to start, but it failed when
trying to compile binutils:

    checking target system type... Invalid configuration
`avr-linux-avrlibc': system `avrlibc' not recognized

I'm totally lost.  Any thoughts on where to go next?

BTW, I believe this native search path is needed in order for the AVR
header files to be found:

    (search-path-specification
     (variable "C_INCLUDE_PATH")
     (files '("avr/include")))

Hopefully I'll be able to play with my Atmel microcontrollers again
real soon. :)

- Dave

Re: avr-gcc

[Ludovic Courtès]

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

> On Tue, Nov 17, 2015 at 4:32 PM, Ludovic Courtès <ludo@gnu.org> wrote:

[...]

>> In GCC we modify the spec file so that the right -L/libc/dir/name is
>> passed to ld; see (gnu packages gcc), ‘GNU_USER_TARGET_LIB_SPEC’.
>>
>> However, ‘gcc-cross-sans-libc-avr’ is a bare-bones compiler, so it
>> doesn’t get the -L flag in question since there’s no libc to link to.
>>
>> To get a full-blow compiler that uses avr-libc, you could start from
>> this:
>>
>>
>>
>> … and then address any glibc assumptions you encounter.
>
> I tried to do this, but I don't really know what I'm doing.  The first
> problem I encountered was that I needed to add a case to the
> 'glibc-dynamic-linker' procedure in (gnu packages bootstrap).  I
> didn't know what ld was needed, if any, so I added this case:
>
>     ((string=? system "avr-avrlibc") "no-ld.so")

It may be that avr-libc has no dynamic linker, because it targets
MMU-less systems, no?

> Then, the issue was that avr-libc doesn't have a propagated input with
> the label "linux-headers", as required by 'cross-gcc' in (gnu packages
> cross-base).  So, as a hack I tried something like this:
>
>     (if (string=? "avr-libc" (package-name libc))
>                            `()
>                            `(("xlinux-headers" ;the target headers
>                               ,@(assoc-ref (package-propagated-inputs libc)
>                                            "linux-headers"))))
>
> Now I was able to get the build process to start, but it failed when
> trying to compile binutils:
>
>     checking target system type... Invalid configuration
> `avr-linux-avrlibc': system `avrlibc' not recognized
>
> I'm totally lost.  Any thoughts on where to go next?

Hmm, maybe my suggestion was just misguided, because the AVR environment
seems to be very different from the typical GNU/Linux environment.

For instance it’s not clear to me how as a user you’re supposed to tell
the compiler which libc.a file to choose among all those provided by
avr-libc.

Back to the Microscheme question, you could set ‘CROSS_LIBRARY_PATH’
manually to point to one of the avr/lib/xxx directories, where our
cross-gcc will find libc.a, libm.a, and crt*.o, but I don’t know if it’s
how it’s intended to work.

> BTW, I believe this native search path is needed in order for the AVR
> header files to be found:
>
>     (search-path-specification
>      (variable "C_INCLUDE_PATH")
>      (files '("avr/include")))

‘C_INCLUDE_PATH’ is the C-only equivalent of ‘CPATH’.  Our
cross-compiler honors ‘CROSS_CPATH’ instead of ‘CPATH’ so as to
distinguish between host and build headers (see
gcc-cross-environment-variables.patch.)

Also it’s not clear to me why avr-libc installs things in avr/include
instead of include/.

So in short, it looks like everything you need is already there, but the
pieces need to be wired together.  :-)

Ludo’.

Re: avr-gcc

[Thompson, David]

On Wed, Nov 18, 2015 at 6:03 AM, Ludovic Courtès <ludo@gnu.org> wrote:
> "Thompson, David" <dthompson2@worcester.edu> skribis:
>
>> On Tue, Nov 17, 2015 at 4:32 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>
> [...]
>
>>> In GCC we modify the spec file so that the right -L/libc/dir/name is
>>> passed to ld; see (gnu packages gcc), ‘GNU_USER_TARGET_LIB_SPEC’.
>>>
>>> However, ‘gcc-cross-sans-libc-avr’ is a bare-bones compiler, so it
>>> doesn’t get the -L flag in question since there’s no libc to link to.
>>>
>>> To get a full-blow compiler that uses avr-libc, you could start from
>>> this:
>>>
>>>
>>>
>>> … and then address any glibc assumptions you encounter.
>>
>> I tried to do this, but I don't really know what I'm doing.  The first
>> problem I encountered was that I needed to add a case to the
>> 'glibc-dynamic-linker' procedure in (gnu packages bootstrap).  I
>> didn't know what ld was needed, if any, so I added this case:
>>
>>     ((string=? system "avr-avrlibc") "no-ld.so")
>
> It may be that avr-libc has no dynamic linker, because it targets
> MMU-less systems, no?
>
>> Then, the issue was that avr-libc doesn't have a propagated input with
>> the label "linux-headers", as required by 'cross-gcc' in (gnu packages
>> cross-base).  So, as a hack I tried something like this:
>>
>>     (if (string=? "avr-libc" (package-name libc))
>>                            `()
>>                            `(("xlinux-headers" ;the target headers
>>                               ,@(assoc-ref (package-propagated-inputs libc)
>>                                            "linux-headers"))))
>>
>> Now I was able to get the build process to start, but it failed when
>> trying to compile binutils:
>>
>>     checking target system type... Invalid configuration
>> `avr-linux-avrlibc': system `avrlibc' not recognized
>>
>> I'm totally lost.  Any thoughts on where to go next?
>
> Hmm, maybe my suggestion was just misguided, because the AVR environment
> seems to be very different from the typical GNU/Linux environment.
>
> For instance it’s not clear to me how as a user you’re supposed to tell
> the compiler which libc.a file to choose among all those provided by
> avr-libc.
>
> Back to the Microscheme question, you could set ‘CROSS_LIBRARY_PATH’
> manually to point to one of the avr/lib/xxx directories, where our
> cross-gcc will find libc.a, libm.a, and crt*.o, but I don’t know if it’s
> how it’s intended to work.
>
>> BTW, I believe this native search path is needed in order for the AVR
>> header files to be found:
>>
>>     (search-path-specification
>>      (variable "C_INCLUDE_PATH")
>>      (files '("avr/include")))
>
> ‘C_INCLUDE_PATH’ is the C-only equivalent of ‘CPATH’.  Our
> cross-compiler honors ‘CROSS_CPATH’ instead of ‘CPATH’ so as to
> distinguish between host and build headers (see
> gcc-cross-environment-variables.patch.)

Ah, okay.  CROSS_CPATH works.

> Also it’s not clear to me why avr-libc installs things in avr/include
> instead of include/.

Not sure either, but it poses no problem.

> So in short, it looks like everything you need is already there, but the
> pieces need to be wired together.  :-)

Not quite.  The avr-gcc build only provides a single version of
libgcc.a, whereas Debian's avr-gcc provides a separate libgcc.a for
each supported AVR family (avr2, avr3, avr35, etc.)  Mark thought it
might be the fault of the --disable-multilib configure flag, so I
removed it but it didn't solve anything.  I'm not sure what to do now.
I have no idea what flag or patch could be signalling to the gcc build
system that it shouldn't try to compile libraries for all of the
various AVR models.

Does anyone have any ideas?

Thanks,

- Dave

Re: avr-gcc

[Ludovic Courtès]

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

> Not quite.  The avr-gcc build only provides a single version of
> libgcc.a, whereas Debian's avr-gcc provides a separate libgcc.a for
> each supported AVR family (avr2, avr3, avr35, etc.)  Mark thought it
> might be the fault of the --disable-multilib configure flag, so I
> removed it but it didn't solve anything.  I'm not sure what to do now.
> I have no idea what flag or patch could be signalling to the gcc build
> system that it shouldn't try to compile libraries for all of the
> various AVR models.

Are you sure the removal of --disable-multilib was effective?

Otherwise no specific idea.  :-/ We’ll have to thoroughly study the
(avr-)gcc doc.

Ludo’.

Re: avr-gcc

[Thompson, David]

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

Revitalizing this old thread.

On Fri, Nov 20, 2015 at 9:20 AM, Ludovic Courtès <ludo@gnu.org> wrote:
> "Thompson, David" <dthompson2@worcester.edu> skribis:
>
>> Not quite.  The avr-gcc build only provides a single version of
>> libgcc.a, whereas Debian's avr-gcc provides a separate libgcc.a for
>> each supported AVR family (avr2, avr3, avr35, etc.)  Mark thought it
>> might be the fault of the --disable-multilib configure flag, so I
>> removed it but it didn't solve anything.  I'm not sure what to do now.
>> I have no idea what flag or patch could be signalling to the gcc build
>> system that it shouldn't try to compile libraries for all of the
>> various AVR models.
>
> Are you sure the removal of --disable-multilib was effective?
>
> Otherwise no specific idea.  :-/ We’ll have to thoroughly study the
> (avr-)gcc doc.

With much help from Manolis, we were finally able to overcome the
multilib issue!  But there's another roadblock: avr-libc doesn't
build:

avr-gcc -DHAVE_CONFIG_H -I. -I../../../../avr-libc-2.0.0/avr/lib/avr2
-I../../..  -I../../../../avr-libc-2.0.0/common
-I../../../../avr-libc-2.0.0/include -I../../../include
-I../../../../avr-libc-2.0.0/common
-I../../../../avr-libc-2.0.0/include -I../../../include -x
assembler-with-cpp  -mmcu=avr2 -D__COMPILING_AVR_LIBC__   -MT abort.o
-MD -MP -MF .deps/abort.Tpo -c -o abort.o
../../../../avr-libc-2.0.0/libc/stdlib/abort.S
In file included from
/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/include/features.h:389:0,
                 from
/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/include/limits.h:25,
                 from ../../../../avr-libc-2.0.0/libc/stdlib/strtol.c:33:
/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/include/gnu/stubs.h:7:27:
fatal error: gnu/stubs-32.h: No such file or directory
 # include <gnu/stubs-32.h>
                           ^
compilation terminated.


I don't know why it's including headers from the host system's libc.
Manolis was able to get past it by including a cross-libc built for
i686.  Does this seem wrong to anyone else?  Any thoughts on what
might be going on here?

We're closer than ever to having a working AVR toolchain.  I hope we
can iron out these last wrinkles.  Attached is the WIP code for the
toolchain.

- Dave

[-- Attachment #2: 0001-wip-AVR-stuff.patch --]
[-- Type: text/x-patch, Size: 4405 bytes --]

From 9773ef4c013f7a223ea112559f517c3ad9c10ac2 Mon Sep 17 00:00:00 2001
From: David Thompson <dthompson@vistahigherlearning.com>
Date: Tue, 5 Apr 2016 12:12:48 -0400
Subject: [PATCH] wip AVR stuff

---
 gnu/packages/avr.scm        | 60 +++++++++++++++++++++++++++++++++++++--------
 gnu/packages/cross-base.scm |  6 -----
 2 files changed, 50 insertions(+), 16 deletions(-)

diff --git a/gnu/packages/avr.scm b/gnu/packages/avr.scm
index d59816b..7560eec 100644
--- a/gnu/packages/avr.scm
+++ b/gnu/packages/avr.scm
@@ -19,6 +19,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)
@@ -27,31 +28,70 @@
   #: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-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")
-    (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
+     '(#:out-of-source? #t
        #:configure-flags '("--host=avr")))
-
-    (native-inputs `(("cross-binutils" ,(cross-binutils "avr"))
-                     ("cross-gcc" ,xgcc-avr)))
+    (native-inputs `(("avr-binutils" ,avr-binutils)
+                     ("avr-gcc" ,avr-gcc)
+                     ;;("libc" ,(cross-libc "i686-linux"))
+                     ))
     (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
diff --git a/gnu/packages/cross-base.scm b/gnu/packages/cross-base.scm
index 8bd599c..bdf17ba 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

Re: avr-gcc

[Thompson, David]

On Tue, Apr 12, 2016 at 2:21 PM, Thompson, David
<dthompson2@worcester.edu> wrote:

> I don't know why it's including headers from the host system's libc.
> Manolis was able to get past it by including a cross-libc built for
> i686.  Does this seem wrong to anyone else?  Any thoughts on what
> might be going on here?

Well, with a super nasty hack I've been able to successfully build an
AVR toolchain without using that cross-libc!

The issue is that, at least on x86_64, the avr-libc build happens
without the __x86_64__ preprocessor definition.  Adding it manually
with the make flag 'CFLAGS=-D__x86_64__' yields a successful build.
Does anyone have an idea what is going wrong here?  If so, how can we
make sure that all platforms will build this thing correctly?  I use
avr-gcc on ARM machines, for example.

Thanks,

- Dave

Re: avr-gcc

[Ludovic Courtès]

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

> avr-gcc -DHAVE_CONFIG_H -I. -I../../../../avr-libc-2.0.0/avr/lib/avr2
> -I../../..  -I../../../../avr-libc-2.0.0/common
> -I../../../../avr-libc-2.0.0/include -I../../../include
> -I../../../../avr-libc-2.0.0/common
> -I../../../../avr-libc-2.0.0/include -I../../../include -x
> assembler-with-cpp  -mmcu=avr2 -D__COMPILING_AVR_LIBC__   -MT abort.o
> -MD -MP -MF .deps/abort.Tpo -c -o abort.o
> ../../../../avr-libc-2.0.0/libc/stdlib/abort.S
> In file included from
> /gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/include/features.h:389:0,
>                  from
> /gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/include/limits.h:25,
>                  from ../../../../avr-libc-2.0.0/libc/stdlib/strtol.c:33:
> /gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/include/gnu/stubs.h:7:27:
> fatal error: gnu/stubs-32.h: No such file or directory
>  # include <gnu/stubs-32.h>
>                            ^
> compilation terminated.

<gnu/stubs-32.h> is used when building on a 64-bit glibc system in
32-bit mode.  However, our glibc does not provide it currently.

> I don't know why it's including headers from the host system's libc.

Right, that’s a problem.  I would expect it to only include target libc
headers.  Could you check C_INCLUDE_PATH and CROSS_CPATH in there?

Note that our ‘gcc’ package is modified to honor the special CROSS_CPATH
variable, see gcc-cross-environment-variables.patch.  Maybe the
equivalent thing is missing from avr-gcc?

Good that you’re getting there!

Ludo’.

Re: avr-gcc

[Jan Nieuwenhuizen]

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

Ludovic Courtès writes:

>> fatal error: gnu/stubs-32.h: No such file or directory
>>  # include <gnu/stubs-32.h>
>>                            ^
>> compilation terminated.
>
> <gnu/stubs-32.h> is used when building on a 64-bit glibc system in
> 32-bit mode.  However, our glibc does not provide it currently.

I had this same problem and tried lots of workarounds until I finally
found what is now the first patch from my wip-mingw32 branch,
see attached

Greetings, Jan


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-gnu-gcc-use-CPATH-fixes-cross-builds.patch --]
[-- Type: text/x-diff, Size: 1044 bytes --]

From 5a6b6ba5a440d43af3e8c5cbd1d24f3be5a99804 Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen <janneke@gnu.org>
Date: Sun, 27 Mar 2016 16:00:36 +0200
Subject: [PATCH 1/9] gnu: gcc: use CPATH, fixes cross builds.

* gnu/packages/gcc (gcc): Use CPATH instead of C_INCLUDE_PATH.  Fixes usage of
  native glibc headers when cross-compiling.
---
 gnu/packages/gcc.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm
index 1df5150..a68ec7f 100644
--- a/gnu/packages/gcc.scm
+++ b/gnu/packages/gcc.scm
@@ -300,7 +300,7 @@ where the OS part is overloaded to denote a specific ABI---into GCC
        ;; treated as "system headers" (headers exempt from warnings) just like
        ;; the typical /usr/include headers on an FHS system.
        (list (search-path-specification
-              (variable "C_INCLUDE_PATH")
+              (variable "CPATH")
               (files '("include")))
              (search-path-specification
               (variable "CPLUS_INCLUDE_PATH")
-- 
2.7.3


[-- Attachment #3: Type: text/plain, Size: 154 bytes --]


-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

Re: avr-gcc

[Ludovic Courtès]

Jan Nieuwenhuizen <janneke@gnu.org> skribis:

> From 5a6b6ba5a440d43af3e8c5cbd1d24f3be5a99804 Mon Sep 17 00:00:00 2001
> From: Jan Nieuwenhuizen <janneke@gnu.org>
> Date: Sun, 27 Mar 2016 16:00:36 +0200
> Subject: [PATCH 1/9] gnu: gcc: use CPATH, fixes cross builds.
>
> * gnu/packages/gcc (gcc): Use CPATH instead of C_INCLUDE_PATH.  Fixes usage of
>   native glibc headers when cross-compiling.

This would be reverting the fix for <http://bugs.gnu.org/22186> as the
comment above explains.

I suppose the problem is that CPATH is still used elsewhere, leading to
interference with this one.  However, the cross-compilers for
mips64el-linux-gnu and armhf-linux-gnueabi work fine, AFAIK.

Thoughts?

Ludo’.

Re: avr-gcc

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

[CC: Andy because it's his bug report]

>> * gnu/packages/gcc (gcc): Use CPATH instead of C_INCLUDE_PATH.  Fixes usage of
>>   native glibc headers when cross-compiling.
>
> This would be reverting the fix for <http://bugs.gnu.org/22186> as the
> comment above explains.

Thanks, that's an interesting read; I didn't know about the
-Wsystem-path.

> I suppose the problem is that CPATH is still used elsewhere, leading
> to interference with this one.

The problem is our usage of C_INCLUDE_PATH.  Before I found this
apparently simple solution I proposed (not knowing about this bug
report), I gained some experience with what happens if we have the
native gcc set C_INCLUDE_PATH.

When cross building the function build-system/gnu.scm
(standard-packages) includes the native gcc into the build environment.
This makes C_INCLUDE_PATH to point to the native glibc.  That breaks
early when cross compiling to a non-glibc platform such as mingw.

Then I wrote a package-dependent version of standard-packages, that
--when cross-compiling non-toolchain packages--does not include the
native gcc.  Ugly and clumly but works.

Except for packages that need a native gcc to build tools during build
time (CC_FOR_BUILD).  For such packages (like Bash or Guile),
standard-packages must include gcc again.  Then, the build recipe's
phases must be changed so that when cross compiling, the
C_INCLUDE_PATH is moved into CPATH and C_INCLUDE_PATH is unset.
That makes this solution even more unattractive, many changes
to package recipe's could be needed.

However, the bug report by Andy suggests that this is somehow also
the wrong solution, even when cross compiling you'd want to use
C*_INCLUDE_PATH and not CPATH?

> However, the cross-compilers for mips64el-linux-gnu and
> armhf-linux-gnueabi work fine, AFAIK.

Are these platforms also using glibc, that could possibly hide a problem
of including the wrong headers?

> Thoughts?

I would like to ask you (all) the same question.  I don't really
know at this point which way to go.

Possibly we can change gcc-cross-environment-variables.patch
to do this trick

    -  add_env_var_paths ("CPATH", BRACKET);
    +  add_env_var_paths ("CROSS_CPATH", BRACKET);

to C_*INCLUDE_PATH instead of to CPATH, and use C_*INCLUDE_PATH
everywhere?

Greetings,
Jan

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

Re: avr-gcc

[Andy Wingo]

On Fri 15 Apr 2016 10:09, Jan Nieuwenhuizen <janneke@gnu.org> writes:

> Ludovic Courtès writes:
>
>> I suppose the problem is that CPATH is still used elsewhere, leading
>> to interference with this one.
>
> The problem is our usage of C_INCLUDE_PATH.

I don't understand this diagnosis.  If the paths were not in
C_INCLUDE_PATH, they would be in CPATH.  Then you'd have the same
problem.  No?

Or is there some special logic which is applying to CPATH which is not
applying to C_INCLUDE_PATH?

Basically in Guix we should, IMO, always be working on C_INCLUDE_PATH
and friends, and never on CPATH.

Andy

Re: avr-gcc

[Jan Nieuwenhuizen]

Andy Wingo writes:

>> The problem is our usage of C_INCLUDE_PATH.
>
> I don't understand this diagnosis.  If the paths were not in
> C_INCLUDE_PATH, they would be in CPATH.  Then you'd have the same
> problem.  No?

Let me try to choose my words more carefully.  The facts that gcc sets
C_INCLUDE_PATH and this native gcc setting this path to the native
headers, is added to the environment when cross building, and the
fact that C_INCLUDE_PATH does not get special treatment when
cross building, like CPATH

    -  add_env_var_paths ("CPATH", BRACKET);
    +  add_env_var_paths ("CROSS_CPATH", BRACKET);

makes that the cross-gcc picks up the wrong native headers unless
C_INCLUDE_PATH is unset.

> Or is there some special logic which is applying to CPATH which is not
> applying to C_INCLUDE_PATH?

Ah, yes; CPATH is not used when cross building, instead CROSS_CPATH is
used.

> Basically in Guix we should, IMO, always be working on C_INCLUDE_PATH
> and friends, and never on CPATH.

I'm guessing that could work; would could try to change the above patch
(in gcc-cross-environment-variables.patch) to handle C*_INCLUDE_PATH and
introduce CROSS_C*_INCLUDE_PATH.

I just wonder if there was another reason for cross builds to choose
CPATH/CROSS_CPATH instead of C_*INCLUDE_PATH.  Apart maybe from the
fact that we would need to handle all `*' where CPATH works for all
languages.

Greetings,
Jan

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

Re: avr-gcc

[Andy Wingo]

Hi :)

On Fri 15 Apr 2016 14:44, Jan Nieuwenhuizen <janneke@gnu.org> writes:

> Andy Wingo writes:
>
>> Or is there some special logic which is applying to CPATH which is not
>> applying to C_INCLUDE_PATH?
>
> Ah, yes; CPATH is not used when cross building, instead CROSS_CPATH is
> used.

Ah, I see.  I guess that's the essential difference.

>> Basically in Guix we should, IMO, always be working on C_INCLUDE_PATH
>> and friends, and never on CPATH.
>
> I'm guessing that could work; would could try to change the above patch
> (in gcc-cross-environment-variables.patch) to handle C*_INCLUDE_PATH and
> introduce CROSS_C*_INCLUDE_PATH.
>
> I just wonder if there was another reason for cross builds to choose
> CPATH/CROSS_CPATH instead of C_*INCLUDE_PATH.  Apart maybe from the
> fact that we would need to handle all `*' where CPATH works for all
> languages.

Yeah let's give this a try instead.  Probably we should support
CROSS_ variants of all of these include paths: CPATH, C_INCLUDE_PATH,
and so on.

I admit I don't understand why the CROSS_ paths are needed.  But I
haven't looked into it and if I don't need to know, I am happy to remain
ignorant :)

Happy hacking,

Andy

ps. Thank you for all of your work here, Jan!

Re: avr-gcc

[Ludovic Courtès]

Andy Wingo <wingo@igalia.com> skribis:

> On Fri 15 Apr 2016 14:44, Jan Nieuwenhuizen <janneke@gnu.org> writes:
>
>> Andy Wingo writes:

[...]

>>> Basically in Guix we should, IMO, always be working on C_INCLUDE_PATH
>>> and friends, and never on CPATH.
>>
>> I'm guessing that could work; would could try to change the above patch
>> (in gcc-cross-environment-variables.patch) to handle C*_INCLUDE_PATH and
>> introduce CROSS_C*_INCLUDE_PATH.
>>
>> I just wonder if there was another reason for cross builds to choose
>> CPATH/CROSS_CPATH instead of C_*INCLUDE_PATH.  Apart maybe from the
>> fact that we would need to handle all `*' where CPATH works for all
>> languages.

It just happened to be easier to take care of one variable than to take
care of all of them.  (At the time we also used CPATH for the native
GCC.)

> Yeah let's give this a try instead.  Probably we should support
> CROSS_ variants of all of these include paths: CPATH, C_INCLUDE_PATH,
> and so on.

Sounds good to me!

> I admit I don't understand why the CROSS_ paths are needed.  But I
> haven't looked into it and if I don't need to know, I am happy to remain
> ignorant :)

This is so that we can specify different search paths for the native
compiler and for the cross compiler, which is necessary when the coexist
in the same environment: <http://gcc.gnu.org/ml/gcc/2013-02/msg00124.html>.

Thanks,
Ludo’.

Re: avr-gcc

[Ludovic Courtès]

Jan Nieuwenhuizen <janneke@gnu.org> skribis:

> Except for packages that need a native gcc to build tools during build
> time (CC_FOR_BUILD).  For such packages (like Bash or Guile),
> standard-packages must include gcc again.  Then, the build recipe's
> phases must be changed so that when cross compiling, the
> C_INCLUDE_PATH is moved into CPATH and C_INCLUDE_PATH is unset.
> That makes this solution even more unattractive, many changes
> to package recipe's could be needed.

Right!  That is really a bug, and I wonder why we didn’t catch it before
(maybe because the libc’s are pretty much the same in the systems we
were targeting?).

I had actually worked around it in
e8e2e18b84eb8842a59be9bf7d49bb672260ae3a in one particular case.

So the fix, as you suggest, is (1) to change
gcc-cross-environment-variables.patch to CROSS_ify the other environment
variables as well, and (2) to remove the unsetenv that was added in
e8e2e18b84eb8842a59be9bf7d49bb672260ae3a.

Could you give it a try?  :-)

Thanks for taking the time to explain!

Ludo’.

Re: avr-gcc

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

> Jan Nieuwenhuizen <janneke@gnu.org> skribis:
>
>> Except for packages that need a native gcc to build tools during build
>> time (CC_FOR_BUILD).  For such packages (like Bash or Guile),
>> standard-packages must include gcc again.  Then, the build recipe's
>> phases must be changed so that when cross compiling, the
>> C_INCLUDE_PATH is moved into CPATH and C_INCLUDE_PATH is unset.
>> That makes this solution even more unattractive, many changes
>> to package recipe's could be needed.
>
> Right!  That is really a bug, and I wonder why we didn’t catch it before
> (maybe because the libc’s are pretty much the same in the systems we
> were targeting?).
>
> I had actually worked around it in
> e8e2e18b84eb8842a59be9bf7d49bb672260ae3a in one particular case.

Ah, I see.

> So the fix, as you suggest, is (1) to change
> gcc-cross-environment-variables.patch to CROSS_ify the other environment
> variables as well, and (2) to remove the unsetenv that was added in
> e8e2e18b84eb8842a59be9bf7d49bb672260ae3a.

Yes, that's the idea.  And then also use CROSS_C_INCLUDE_PATH and
C_INCLUDE_PATH in cross-base.scm, i.e., for the new libc and gcc cross
builds.

> Could you give it a try?  :-)

I'm looking into this and have some success, quite some things need
to be rebuilt ;-)

> Thanks for taking the time to explain!

That's good to hear!  Thanks for looking into this and providing
information!

Greetings,
Jan

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl