Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#25798 - [avr-gcc] Missing XMEGA mcu support

Attached to Project: Community Packages
Opened by Alex Forencich (alex.forencich) - Sunday, 28 August 2011, 06:34 GMT
Last edited by Jakob Gruber (schuay) - Saturday, 31 March 2012, 14:09 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Jakob Gruber (schuay)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


The gcc-avr package in the Arch repository is missing ALL XMEGA mcu support.

Additional info:
* avr-gcc 4.6.1

Steps to reproduce:
avr-g++ -c -mmcu=atxmega128a3 -I. -gstabs -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wa,-adhlns=voadrv.lst -MD -MP -MF .dep/voadrv.o.d -DF_CPU=32000000L voadrv.cpp -o voadrv.o
voadrv.cpp:1:0: error: unrecognized argument to -mmcu= option: 'atxmega128a3'
voadrv.cpp:1:0: note: See --target-help for supported MCUs

This task depends upon

Closed by  Jakob Gruber (schuay)
Saturday, 31 March 2012, 14:09 GMT
Reason for closing:  Upstream
Additional comments about closing:  XMEGA support has been added in gcc 4.7.
Comment by Alex Forencich (alex.forencich) - Monday, 29 August 2011, 08:10 GMT
This issue also applies to binutils-avr and avr-libc. Compiler device support is inifnitely more important than using the latest compiler version. Hence, here are modified (though slightly outdated from a raw compiler version standpoint) PKGBUILDs for binutils-avr and gcc-avr that contain the necessary patches for XMEGA device support (among other devices). The patches and specific package versions are drawn from the FreeBSD ports tree. avr-libc requires no additional packages, but it must be built with avr-gcc with the full device support. I also ran into an issue with avr-libc where makepkg will automatically run strip on the library with the host's 'strip' instead of 'avr-strip', making the files unusable. Adding options=(!strip) corrects this issue. Attached are all three PKGBUILDs.
Comment by Alex Forencich (alex.forencich) - Monday, 29 August 2011, 08:19 GMT
More information about attached PKGBUILDs:

avr-libc: 1.7.0
gcc-avr: 4.3.4
binutils-avr: 2.20.1

Note: the souce file on is actually called binutils-2.20.1a.tar.bz2, necessitating a bit of a hack in the source line to get it working properly.
Comment by Alex Forencich (alex.forencich) - Monday, 29 August 2011, 09:09 GMT
It seems that does not generate archives with consistent md5 hashes. The solution is to download each patch separately. Here are the updated PKGBUILDs for binutils-avr and gcc-avr.
Comment by Brad Fanella (itsbrad212) - Tuesday, 27 September 2011, 02:28 GMT
Is this issue even still prevalent? That seems like a large amount of patches to apply, and the gcc/binutils versions mentioned here are long gone.
Comment by Alex Forencich (alex.forencich) - Tuesday, 27 September 2011, 05:05 GMT
This is absolutely prevalent. I use xmega chips primarily and the current versions in the Arch repos are unusable (see error message). The latest version of GCC does not support xmega processors. I do not know the reasoning for them not including support. Perhaps it's because the series is new, having been released a couple of years ago. On the other hand, the winavr team seems to have their own fork with all the extra device support patches, so perhaps it's just that the GCC team does not focus on the AVR version as they have bigger fish to fry. The PKGBUILDS I provided are basically the latest version of the avr-gcc suite that FreeBSD offers and they are quite good about keeping up to date while not dropping important features. The tradeoff of a slightly old compiler version as opposed to omitting an entire architecture is more than acceptable.
Comment by Alex Forencich (alex.forencich) - Wednesday, 02 November 2011, 20:28 GMT
Here are updated PKGBUILDS for newer tool version. Patches are from the official Atmel site .

avr-libc: 1.7.1
gcc-avr: 4.5.1
binutils-avr: 2.20.1
Comment by Jelle van der Waa (jelly) - Thursday, 03 November 2011, 12:31 GMT
Hi, I took over the package from brad. I will look into the issues, your updated PKGBUILDs. All contain old versions of gcc-avr and binutils-avr. 4.6.2 should be in the repos now.
Comment by Alex Forencich (alex.forencich) - Thursday, 03 November 2011, 17:25 GMT
Actually scratch the PKGBUILD for gcc-avr 4.5.1-1. I stumbled across an initialization bug that seems to affect one series of xmega parts. As far as I can tell, if an object is instantiated on startup with more than 2 bytes worth of parameters, a register gets clobbered that throws the chip into a reset loop. It affects the xmega128a3 but not the xmega16a4. No clue why at the moment. Same problem with gcc 4.5.2. I will do some more experimentation.

Also, as far as embedded programming goes, who cares about the compiler version if it doesn't support the chip in use. I work with Atmel AVR xmega chips. If the compiler doesn't support xmega, it's worthless. I don't care how many versions I have to go back to find one that does what I need it to do. Also, look at FreeBSD, Debian, Ubuntu, etc. FreeBSD has 4.3.4. Ubuntu had 4.3.5 for a long time, now it's 4.5.3. Whoopee, Arch's version is newer. However, it's useless without the Atmel patches, so what's the point?
Comment by Alex Forencich (alex.forencich) - Thursday, 03 November 2011, 17:51 GMT
Nope, same initialization reset loop issue with 4.5.1, 4.5.2, and 4.5.3. Very odd.
Comment by Jelle van der Waa (jelly) - Thursday, 03 November 2011, 17:52 GMT
Why aren't these atmel patches going upstream aka into gcc-avr ?
Comment by Alex Forencich (alex.forencich) - Thursday, 03 November 2011, 19:24 GMT
I have no idea. Licensing, perhaps. It would sure make our lives easier if we didn't have to go hunting for the darn patches, though.
Comment by Alex Forencich (alex.forencich) - Saturday, 05 November 2011, 11:19 GMT
It seems avr-gcc is not entirely bug free, even the older versions. I could not get a program for an xmega32a4 to link with gcc-avr 4.3.5 due to an architecture issue (atxmega3 was eliminated at some point along the way, breaking a few things). There seems to be an issue with startup code for avr-gcc 4.5.x that affects the xmega128a1 but not the 16a4. Strange. That one can be worked around though, so for gcc the attached pkgbuild is probably the way to go.
Comment by Jelle van der Waa (jelly) - Saturday, 05 November 2011, 14:50 GMT
I can only find one bug report mentioning xmega. So these patches and bugs should go to upstream.
Comment by Alex Forencich (alex.forencich) - Saturday, 05 November 2011, 18:40 GMT
That would be nice. There must be a reason they aren't included at that level, though. All of the other distributions add the Atmel supplied patches on 4.5.x and earlier versions of GCC though. Take a look at freebsd ( and debian ( The bugs I mentiond definitely need to go upstream, though. I only mentioned those as I was trying to determine which compiler version worked the best, and it seems like that would be 4.5.3. I have not seen any other distribution with an avr-gcc version higher than 4.5.3, most likely because the latest patches from Atmel are for 4.5.1 and they don't apply to gcc higher than 4.5.3.

Basically, the bottom like is bugs that aren't related to the proper application of Atmel supplied patches go upstream, and the Atmel supplied patches must be applied as necessary by you guys when building the package for the arch repository. I said it before an I'll say it again, gcc-avr version 4.6.2 is useless to me so long as I can't compile for the chip I'm using with it. I can do that on pretty much every other linux distribution just by installing the default gcc-avr package. Not so with arch linux as I had to go hunting for the proper patches and build it myself. I just want to fix that for everyone else who wants to develop for xmega in arch linux.

Also, binutils-avr and avr-libc must also be patched. However, not all the patches need to be applied as they are for experimental Atmel chips. I'm not sure why they're distributing them. I have included all the necessary patches in the PKGBUILDs.

Additionally, note the following from the bug report you linked to:

"ATXmega is not supported by the FSF version of avr-gcc so you should either report the bug to the distributor of your toolchain or reproduce the artifact with in unpatched version of avr-gcc."

Hence, xmega bugs do not go to gcc directly, but would probably be handed off to Atmel.
Comment by Jelle van der Waa (jelly) - Tuesday, 13 March 2012, 10:40 GMT
I am re-reporting this as the package name has changed and it it still not fixed (old bug is #25798). The avr-gcc package in the Arch repository is missing all XMEGA mcu support as it does not contain the Atmel patches from .

Good pkgbuilds for properly patched avr-gcc are available here:

Note that the patches may not apply to the bleeding edge version of GCC. The latest version the linked pkgbuilds have been tested with is 4.5.3.

Steps to reproduce:
avr-g++ -c -mmcu=atxmega128a3 -I. -gstabs -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wa,-adhlns=voadrv.lst -MD -MP -MF .dep/voadrv.o.d -DF_CPU=32000000L voadrv.cpp -o voadrv.o
voadrv.cpp:1:0: error: unrecognized argument to -mmcu= option: 'atxmega128a3'
voadrv.cpp:1:0: note: See --target-help for supported MCUs
Comment by Jakob Gruber (schuay) - Monday, 19 March 2012, 19:20 GMT
For a short term solution, I'd recommend maintaining packages that require patching for XMEGA support in the AUR (for example as avr-gcc-xmega, avr-binutils-xmega, ...).

Please post back here about any news (things like Atmel patches being ported to current gcc/binutils/... versions). also mentions initial XMEGA support in gcc 4.7, so that might be worth watching too.
Comment by Alex Forencich (alex.forencich) - Tuesday, 20 March 2012, 04:42 GMT
Well, the biggest omission is xmega support, but it's really missing ALL of Atmel's changes, so what about adding AUR packages for avr-gcc-atmel, avr-binutils-atmel, etc. and then having those provide avr-gcc/gcc-avr, avr-binutils/binutils-avr, etc. ? That would also save the trouble of adding the ignore directives to pacman.conf.

I think there is a reason that the Atmel patches are not part of the FSF version of GCC, but I am not familiar with the politics of the compiler; I just want something that works. According to , it seems that the patches constitute a fork of the compiler by Atmel. I'm not sure what the significance is, exactly, aside from the fact that the FSF version is broken (and by extension the version in the Arch community repository) while the version incorporating Atmel's patches works perfectly.
Comment by Jelle van der Waa (jelly) - Wednesday, 21 March 2012, 11:52 GMT
So we should add 3rd party patches which upstream doesn't support, so our package depends on atmels support. That sounds like a bad idea, i would rather not include these packages and hope that the FSF version will have XMEGA support soon.
Comment by Jakob Gruber (schuay) - Saturday, 24 March 2012, 15:20 GMT
avr-gcc 4.7.0, avr-binutils 2.22-3, avr-libc 1.8.0-2 are now in [community-testing].

Please test and let me know how it works (especially with XMEGA).
Comment by Alex Forencich (alex.forencich) - Sunday, 25 March 2012, 21:14 GMT
avr-gcc 4.7.0 seems to work fine. However, avr-libc in testing needs to be recompiled. It is missing xmega support as it seems to have been built with the broken version of avr-gcc in community. With the version of avr-libc in testing, linking produces the following output:

/usr/bin/avr-ld: cannot find crtx128a3.o: No such file or directory
/usr/bin/avr-ld: skipping incompatible /usr/lib/gcc/avr/4.7.0/../../../../avr/lib/libm.a when searching for -lm
/usr/bin/avr-ld: cannot find -lm
/usr/bin/avr-ld: skipping incompatible /usr/lib/gcc/avr/4.7.0/../../../../avr/lib/libc.a when searching for -lc
/usr/bin/avr-ld: cannot find -lc
collect2: error: ld returned 1 exit status
make: *** [main.elf] Error 1

After downloading the PKGBUILD and compiling it locally, it seems to work perfectly. I confirmed that the output is good as well as I have some code built with this setup running on a dev board.
Comment by Jakob Gruber (schuay) - Sunday, 25 March 2012, 21:47 GMT
Good catch, thanks. I just pushed a fixed avr-libc-1.8.0-3 to [community-testing].
I will close this bug report if no more issues pop up in the next couple of days.
Comment by Alex Forencich (alex.forencich) - Sunday, 25 March 2012, 22:43 GMT
The new package in testing seems to work perfectly.