Arch Linux

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.

More information about attached PKGBUILDs:

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

Note: the souce file on gnu.org is actually called binutils-2.20.1a.tar.bz2, necessitating a bit of a hack in the source line to get it working properly.

It seems that freebsd.org 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.

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.

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.

Here are updated PKGBUILDS for newer tool version. Patches are from the official Atmel site http://distribute.atmel.no/tools/opensource/avr-gcc/ .

Versions:
avr-libc: 1.7.1
gcc-avr: 4.5.1
binutils-avr: 2.20.1

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.

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?

Nope, same initialization reset loop issue with 4.5.1, 4.5.2, and 4.5.3. Very odd.

Why aren't these atmel patches going upstream aka into gcc-avr ?

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.

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.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44940
I can only find one bug report mentioning xmega. So these patches and bugs should go to upstream.

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 (http://www.freshports.org/devel/avr-gcc/) and debian (http://packages.debian.org/sid/gcc-avr). 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.

Description:
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 http://distribute.atmel.no/tools/opensource/avr-gcc/ .

Good pkgbuilds for properly patched avr-gcc are available here: http://alexforencich.com/wiki/en/linux/arch_avr_gcc

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

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).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44940 also mentions initial XMEGA support in gcc 4.7, so that might be worth watching too.

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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52461 , 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.

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.

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).

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.

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.

The new package in testing seems to work perfectly.