[Top][All Lists]

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

bug#39794: closed (AVR-Toolchain-5 avr/io not found)

From: GNU bug Tracking System
Subject: bug#39794: closed (AVR-Toolchain-5 avr/io not found)
Date: Sun, 01 Mar 2020 07:08:02 +0000

Your message dated Sun, 01 Mar 2020 12:37:35 +0530
with message-id <address@hidden>
and subject line Re: bug#39794: AVR-Toolchain-5 avr/io not found
has caused the debbugs.gnu.org bug report #39794,
regarding AVR-Toolchain-5 avr/io not found
to be marked as done.

(If you believe you have received this mail in error, please contact

39794: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=39794
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: AVR-Toolchain-5 avr/io not found Date: Tue, 25 Feb 2020 22:12:30 +0000

I've been trying to debug AVR toolchain errors found in here:


I'm not experienced enough to know all that's going on here and I need some 
assistance to make everything work.

I'm working on QMK-Firmware (helix keyboard specifically, that is an 
Atmega32u4) has and I'm able to make it compile with avr-gcc@4.9 but when I try 
with 5 first it fails because it doesn't find `avr/io.h`.

Exporting a new CPATH variable fixes it:

`export CPATH=$CPATH:/gnu/store/.../avr/include`

Once the export is done it fails because it's unable to find `gnu/stubs-32.h` 
and I don't know which package carries that. Can you point me to it?
Should it be added to avr-gcc dependencies?

If someone has the time to help me make it work I'll make the patches and the 
tests needed, but now I don't know what else to do.

First I'd say the package for avr-gcc@5 should not inherit from avr-gcc@4.9 
because 4.9 uses CROSS_* variables and works correctly but 5 doesn't use them 
like that. So these changes solve that issue:

diff --git a/gnu/packages/avr.scm b/gnu/packages/avr.scm
index 1f99f636e0..74caec5b94 100644
--- a/gnu/packages/avr.scm
+++ b/gnu/packages/avr.scm
@@ -76,7 +76,15 @@
     (inherit avr-gcc-4.9)
     (version (package-version gcc-5))
-    (source (package-source gcc-5))))
+    (source (package-source gcc-5))
+    (native-search-paths
+      (list (search-path-specification
+              (variable "CPATH")
+              (files '("avr/include")))
+            (search-path-specification
+              (variable "LIBRARY_PATH")
+              (files '("avr/lib")))))))

 (define (avr-libc avr-gcc)

But I don't see how to solve the `gnu/stubs-32.h` error.
Can anyone help me a little on this?


ElenQ Technology
Ethical Innovation

--- End Message ---
--- Begin Message --- Subject: Re: bug#39794: AVR-Toolchain-5 avr/io not found Date: Sun, 01 Mar 2020 12:37:35 +0530
>> arm-none-eabi-toolchain is conflicting with avr-toolchain since both are
>> setting the CROSS_* environment variables. See the output of `avr-gcc -E -v 
>> -` below.
>> This should probably be considered a bug. But I have no idea how to fix
>> this. :-( What do you think?
> I agree. The problem I see here is the environment variable game we have here.
> One option is to create cross compilers with the include paths inserted on 
> them instead of taking environment variables as a default.

Or, we could have separate environment variables CROSS_AVR_C_INCLUDE_PATH
and CROSS_ARM_C_INCLUDE_PATH. But that sounds like too many environment
variables! :-P

> If they had the correct directories in their default includepaths
> everything would work correctly.
> I never did this before but it should be possible, probably affecting
> cross-gcc's configure step.

Something like this is possible too.

> We can start by pushing it and then keep solving the conflict issue
> and the upgrades to gcc-9.


>> Also, our avr-gcc package should probably be updated to the latest
>> avr-gcc-9.
> Once the current fix is applied next fixes should be possible.
> Why wasn't the patch included in the project?

I don't know. I have asked Danny at bug 24416 to push the patch. Let's
wait for a response.

Once Danny's patch is pushed, I'll open a new bug reporting the arm avr

Also, I'm closing this bug report now since this issue is handled by

Thanks! :-)

Attachment: signature.asc
Description: PGP signature

--- End Message ---

reply via email to

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