AVR-Toolchain-5 avr/io not found

Hi,

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:

Follow up of the problem:

Looks like what it's missing is `multilib`, avr-gcc-4.9 package description clearly activates multilib and states that in a comment:

(define-public avr-gcc-4.9

(let ((xgcc (cross-gcc "avr" #:xgcc gcc-4.9 #:xbinutils 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 _

;; patch-shebang doesn't work here because there are actually

;; several scripts inside this script, each with a #!/bin/sh

;; that needs patching.

(substitute* "gcc/genmultilib"

(("#!/bin/sh") (string-append "#!" (which "sh"))))

#t))))

((#:configure-flags flags)

`(delete "--disable-multilib" ,flags))))

...

But looks like the avr-gcc-5.5, which is just inheriting the same description, is not able to create the multilib.

Any idea about why?

I think once we solve that we could have a reasonable avr-toolchain and also go for newer versions.

Regards,

Ekaitz

ElenQ Technology

Ethical Innovation

I'm checking the output by avr-gcc-4.9 in order to compare, and it doesn't have the stubs-32.h file neither but the compilation with avr-gcc-4.9 doesn't ask for it so it doesn't break.

Instead, if I use avr-gcc-5 it asks for the stubs-32.h file and it fails because it's not installed.

Both of them must be checking stubs.h (maybe the compilation with 4.9 isn't?) file that makes the include of the -64 or the -32 depending on the platform :S

Also I tried compiling glibc for 32 bytes because stubs-32 is on it. It worked but carried a different error, probably because I didn't compile it correctly:

/gnu/store/86yn7zgf6yx0gcbma9rxgd6d47ibp9ck-profile/include/bits/floatn.h:86:9: error: unknown type name '__float128'

This error shouldn't happen because the bits/floatn.h file is making checks before doing the typedef that fails... So there are a couple of options here:

- The checks are not enough to find my case

- I made the 32 bit GLIBC wrong and it's carrying wrong parameters to that header file, and makes it fall in a weird case.

Ideas?

Thanks!

Ekaitz

ElenQ Technology

Ethical Innovation

Hi,

I tried the last patch at bug 24416 [1] and it does fix the issue. Can

you confirm?

Regards,

Arun.

[1]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24416#17

Not working for me:

```

QMK Firmware 0.7.163

Making helix/rev2 with keymap default [ERRORS]

In file included from drivers/avr/pro_micro.h:28:0,

from keyboards/helix/rev2/matrix.c:33:

/gnu/store/gq69j5j0458dcc4jp5ymq62wgnd0mscl-profile/avr/include/avr/pgmspace.h:1456:25: error: unknown type name 'uint_farptr_t'

extern size_t strlen_PF(uint_farptr_t src) __ATTR_CONST__; /* program memory can't change */

```

ElenQ Technology

Ethical Innovation

??????? Original Message ???????

On Saturday, February 29, 2020 4:06 PM, Arun Isaac <arunisaac@systemreboot.net> wrote:

But looks like some part of the code is not including the

/avr/include/inttypes.h file because it's declared on it.

Ideas on this?

I'm not able to reproduce this error. Could you provide the exact steps

you did? Here's what I did.

After applying the patch, drop into an environment with the new avr-toolchain.

Check the version of avr-gcc.

Check avr-gcc include paths.

Navigate to qmk-firmware and clean previous build results.

I'm checking out 0.7.163 and building helix since that's what you seem

to be doing.

Oh...

I saw what's happening...

I was using `guix environment --manifest=manifest.scm`

Being manifest:

(specifications->manifest

'("unzip"

"zip"

"git"

"wget"

"dfu-programmer"

"dfu-util"

"avr-toolchain"

"glibc"

"gcc-toolchain"

"arm-none-eabi-toolchain"))

Which are all the development packages needed by QMK keyboard.

I can replicate what you did and it works.

May it be conflicting with other packages? Or using environment like that isn't doing what I expect?

ElenQ Technology

Ethical Innovation

Nice! :-)

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?

Also, our avr-gcc package should probably be updated to the latest

avr-gcc-9.

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.

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.

Once the current fix is applied next fixes should be possible.

Why wasn't the patch included in the project?

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

Have to say that nature of Guix makes the conflict issue easy to avoid while we find a solution for it.

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

Something like this is possible too.

Agreed.

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

conflict.

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

24416.

Thanks! :-)