* avr-gcc @ 2015-11-17 15:25 Ricardo Wurmus 2015-11-17 15:59 ` avr-gcc Ricardo Wurmus 2015-11-17 21:32 ` avr-gcc Ludovic Courtès 0 siblings, 2 replies; 19+ messages in thread From: Ricardo Wurmus @ 2015-11-17 15:25 UTC (permalink / raw) To: guix-devel@gnu.org 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: avr-gcc 2015-11-17 15:25 avr-gcc Ricardo Wurmus @ 2015-11-17 15:59 ` Ricardo Wurmus 2015-11-17 21:32 ` avr-gcc Ludovic Courtès 1 sibling, 0 replies; 19+ messages in thread From: Ricardo Wurmus @ 2015-11-17 15:59 UTC (permalink / raw) To: guix-devel@gnu.org 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: avr-gcc 2015-11-17 15:25 avr-gcc Ricardo Wurmus 2015-11-17 15:59 ` avr-gcc Ricardo Wurmus @ 2015-11-17 21:32 ` Ludovic Courtès 2015-11-18 3:53 ` avr-gcc Thompson, David 1 sibling, 1 reply; 19+ messages in thread From: Ludovic Courtès @ 2015-11-17 21:32 UTC (permalink / raw) To: Ricardo Wurmus; +Cc: guix-devel@gnu.org [-- 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’. ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: avr-gcc 2015-11-17 21:32 ` avr-gcc Ludovic Courtès @ 2015-11-18 3:53 ` Thompson, David 2015-11-18 11:03 ` avr-gcc Ludovic Courtès 0 siblings, 1 reply; 19+ messages in thread From: Thompson, David @ 2015-11-18 3:53 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel@gnu.org 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: avr-gcc 2015-11-18 3:53 ` avr-gcc Thompson, David @ 2015-11-18 11:03 ` Ludovic Courtès 2015-11-19 1:54 ` avr-gcc Thompson, David 0 siblings, 1 reply; 19+ messages in thread From: Ludovic Courtès @ 2015-11-18 11:03 UTC (permalink / raw) To: Thompson, David; +Cc: guix-devel@gnu.org "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’. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: avr-gcc 2015-11-18 11:03 ` avr-gcc Ludovic Courtès @ 2015-11-19 1:54 ` Thompson, David 2015-11-20 14:20 ` avr-gcc Ludovic Courtès 0 siblings, 1 reply; 19+ messages in thread From: Thompson, David @ 2015-11-19 1:54 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel@gnu.org 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: avr-gcc 2015-11-19 1:54 ` avr-gcc Thompson, David @ 2015-11-20 14:20 ` Ludovic Courtès 2016-04-12 18:21 ` avr-gcc Thompson, David 0 siblings, 1 reply; 19+ messages in thread From: Ludovic Courtès @ 2015-11-20 14:20 UTC (permalink / raw) To: Thompson, David; +Cc: guix-devel@gnu.org "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’. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: avr-gcc 2015-11-20 14:20 ` avr-gcc Ludovic Courtès @ 2016-04-12 18:21 ` Thompson, David 2016-04-12 20:14 ` avr-gcc Thompson, David 2016-04-13 20:42 ` avr-gcc Ludovic Courtès 0 siblings, 2 replies; 19+ messages in thread From: Thompson, David @ 2016-04-12 18:21 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel@gnu.org [-- 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 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: avr-gcc 2016-04-12 18:21 ` avr-gcc Thompson, David @ 2016-04-12 20:14 ` Thompson, David 2016-04-13 20:42 ` avr-gcc Ludovic Courtès 1 sibling, 0 replies; 19+ messages in thread From: Thompson, David @ 2016-04-12 20:14 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel@gnu.org 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: avr-gcc 2016-04-12 18:21 ` avr-gcc Thompson, David 2016-04-12 20:14 ` avr-gcc Thompson, David @ 2016-04-13 20:42 ` Ludovic Courtès 2016-04-14 5:47 ` avr-gcc Jan Nieuwenhuizen 1 sibling, 1 reply; 19+ messages in thread From: Ludovic Courtès @ 2016-04-13 20:42 UTC (permalink / raw) To: Thompson, David; +Cc: guix-devel@gnu.org "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’. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: avr-gcc 2016-04-13 20:42 ` avr-gcc Ludovic Courtès @ 2016-04-14 5:47 ` Jan Nieuwenhuizen 2016-04-14 16:47 ` avr-gcc Ludovic Courtès 0 siblings, 1 reply; 19+ messages in thread From: Jan Nieuwenhuizen @ 2016-04-14 5:47 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel@gnu.org [-- 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 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: avr-gcc 2016-04-14 5:47 ` avr-gcc Jan Nieuwenhuizen @ 2016-04-14 16:47 ` Ludovic Courtès 2016-04-15 8:09 ` avr-gcc Jan Nieuwenhuizen 0 siblings, 1 reply; 19+ messages in thread From: Ludovic Courtès @ 2016-04-14 16:47 UTC (permalink / raw) To: Jan Nieuwenhuizen; +Cc: guix-devel@gnu.org 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’. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: avr-gcc 2016-04-14 16:47 ` avr-gcc Ludovic Courtès @ 2016-04-15 8:09 ` Jan Nieuwenhuizen 2016-04-15 9:01 ` avr-gcc Andy Wingo 2016-04-15 21:10 ` avr-gcc Ludovic Courtès 0 siblings, 2 replies; 19+ messages in thread From: Jan Nieuwenhuizen @ 2016-04-15 8:09 UTC (permalink / raw) To: Ludovic Courtès; +Cc: Andy Wingo, guix-devel@gnu.org 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: avr-gcc 2016-04-15 8:09 ` avr-gcc Jan Nieuwenhuizen @ 2016-04-15 9:01 ` Andy Wingo 2016-04-15 12:44 ` avr-gcc Jan Nieuwenhuizen 2016-04-15 21:10 ` avr-gcc Ludovic Courtès 1 sibling, 1 reply; 19+ messages in thread From: Andy Wingo @ 2016-04-15 9:01 UTC (permalink / raw) To: Jan Nieuwenhuizen; +Cc: guix-devel@gnu.org 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: avr-gcc 2016-04-15 9:01 ` avr-gcc Andy Wingo @ 2016-04-15 12:44 ` Jan Nieuwenhuizen 2016-04-15 13:13 ` avr-gcc Andy Wingo 0 siblings, 1 reply; 19+ messages in thread From: Jan Nieuwenhuizen @ 2016-04-15 12:44 UTC (permalink / raw) To: Andy Wingo; +Cc: guix-devel@gnu.org 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: avr-gcc 2016-04-15 12:44 ` avr-gcc Jan Nieuwenhuizen @ 2016-04-15 13:13 ` Andy Wingo 2016-04-15 21:06 ` avr-gcc Ludovic Courtès 0 siblings, 1 reply; 19+ messages in thread From: Andy Wingo @ 2016-04-15 13:13 UTC (permalink / raw) To: Jan Nieuwenhuizen; +Cc: guix-devel@gnu.org 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! ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: avr-gcc 2016-04-15 13:13 ` avr-gcc Andy Wingo @ 2016-04-15 21:06 ` Ludovic Courtès 0 siblings, 0 replies; 19+ messages in thread From: Ludovic Courtès @ 2016-04-15 21:06 UTC (permalink / raw) To: Andy Wingo; +Cc: guix-devel@gnu.org 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’. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: avr-gcc 2016-04-15 8:09 ` avr-gcc Jan Nieuwenhuizen 2016-04-15 9:01 ` avr-gcc Andy Wingo @ 2016-04-15 21:10 ` Ludovic Courtès 2016-04-16 19:55 ` avr-gcc Jan Nieuwenhuizen 1 sibling, 1 reply; 19+ messages in thread From: Ludovic Courtès @ 2016-04-15 21:10 UTC (permalink / raw) To: Jan Nieuwenhuizen; +Cc: Andy Wingo, guix-devel@gnu.org 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’. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: avr-gcc 2016-04-15 21:10 ` avr-gcc Ludovic Courtès @ 2016-04-16 19:55 ` Jan Nieuwenhuizen 0 siblings, 0 replies; 19+ messages in thread From: Jan Nieuwenhuizen @ 2016-04-16 19:55 UTC (permalink / raw) To: Ludovic Courtès; +Cc: Andy Wingo, guix-devel@gnu.org 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2016-04-16 19:56 UTC | newest] Thread overview: 19+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-11-17 15:25 avr-gcc Ricardo Wurmus 2015-11-17 15:59 ` avr-gcc Ricardo Wurmus 2015-11-17 21:32 ` avr-gcc Ludovic Courtès 2015-11-18 3:53 ` avr-gcc Thompson, David 2015-11-18 11:03 ` avr-gcc Ludovic Courtès 2015-11-19 1:54 ` avr-gcc Thompson, David 2015-11-20 14:20 ` avr-gcc Ludovic Courtès 2016-04-12 18:21 ` avr-gcc Thompson, David 2016-04-12 20:14 ` avr-gcc Thompson, David 2016-04-13 20:42 ` avr-gcc Ludovic Courtès 2016-04-14 5:47 ` avr-gcc Jan Nieuwenhuizen 2016-04-14 16:47 ` avr-gcc Ludovic Courtès 2016-04-15 8:09 ` avr-gcc Jan Nieuwenhuizen 2016-04-15 9:01 ` avr-gcc Andy Wingo 2016-04-15 12:44 ` avr-gcc Jan Nieuwenhuizen 2016-04-15 13:13 ` avr-gcc Andy Wingo 2016-04-15 21:06 ` avr-gcc Ludovic Courtès 2016-04-15 21:10 ` avr-gcc Ludovic Courtès 2016-04-16 19:55 ` avr-gcc Jan Nieuwenhuizen
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/guix.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).