Message ID | 1358460970-2081-1-git-send-email-spdawson@gmail.com |
---|---|
State | Rejected |
Headers | show |
Hello Simon, On Thu, 17 Jan 2013 22:16:10 +0000, spdawson@gmail.com wrote: > uClibc 0.9.31.1 fails to build for avr32 using recent (3.7.x) kernel > headers. The build failure looks like the following. Thanks. I don't remember, do you have a specific interest in the AVR32 architecture support? The thing is that apparently, the AVR32 gcc version we're using (gcc 4.2.x) doesn't build anymore with recent host gcc version (I think Gustavo tested with gcc 4.6, and it doesn't build). Generally speaking, the fact that we have to use old, patched, versions of gcc, binutils and uClibc is severely problematic to support this architecture on the long run. Back in November, I got in touch with the people who were active on the AVR32 architecture a few years back (Hans-Christian Egtvedt and Håvard Skinnemoen), but they no longer work for Atmel and therefore don't know what Atmel plans are regarding the AVR32 architecture. Therefore, I'm wondering if we shouldn't mark this architecture as deprecated. Best regards, Thomas
Hi Thomas, On 19 January 2013 10:38, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Thanks. I don't remember, do you have a specific interest in the AVR32 > architecture support? Yes, I'm using Buildroot for the continued development of a system based on the Atmel ap7000. This system will be under development/support for at least the next few years, I would imagine. > The thing is that apparently, the AVR32 gcc version we're using (gcc > 4.2.x) doesn't build anymore with recent host gcc version (I think > Gustavo tested with gcc 4.6, and it doesn't build). Generally speaking, > the fact that we have to use old, patched, versions of gcc, binutils and > uClibc is severely problematic to support this architecture on the long > run. Yes, I understand that the avr32 toolchain is in a bit of a mess. I'm using host gcc version 4.6 without problems; from memory, I think it's 4.7 that doesn't work --- I might have misremembered 'though... > Back in November, I got in touch with the people who were active on the > AVR32 architecture a few years back (Hans-Christian Egtvedt and Håvard > Skinnemoen), but they no longer work for Atmel and therefore don't know > what Atmel plans are regarding the AVR32 architecture. Yes, I think we discussed this briefly at the Buildroot Developer Days in Barcelona. My understanding is that avr32 is regarded semi-officially as an end-of-life architecture. Atmel technical support are, for the time being, still dealing with support queries for avr32. > Therefore, I'm wondering if we shouldn't mark this architecture as > deprecated. From my own perspective, I'd rather keep the avr32 support in Buildroot for now. I don't know how many other people are using the architecture --- not that many, I suspect. Would that be a major problem? I don't know how much effort would be involved in migrating to newer gcc, binutils and uClibc; have you any idea? Simon.
On 01/20/2013 08:01 AM, Simon Dawson wrote: > Yes, I understand that the avr32 toolchain is in a bit of a mess. I'm > using host gcc version 4.6 without problems; from memory, I think it's > 4.7 that doesn't work --- I might have misremembered 'though... With gentoo's 4.6.3 it fails for me in the same way as described at Atmel's site http://www.atmel.no/buildroot/buildroot-issues.html (Error: invalid register list) > Yes, I think we discussed this briefly at the Buildroot Developer Days > in Barcelona. My understanding is that avr32 is regarded > semi-officially as an end-of-life architecture. Atmel technical > support are, for the time being, still dealing with support queries > for avr32. Do you know if the UC3 microcontrollers are in the same boat? If they aren't there may still be some hope for the toolchain (at least binutils/gcc, not much for uclibc/linux). > From my own perspective, I'd rather keep the avr32 support in > Buildroot for now. I don't know how many other people are using the > architecture --- not that many, I suspect. Would that be a major > problem? Testing and fixing is an issue on the toolchain side when there's no upgrade path possible. I wouldn't like to stick to old and potentially vulnerable versions of packages (example: gnutls) because the toolchain is too old to handle it, it's problematic. And dragging arch-specific patches isn't fun either. Maybe we can keep it and start marking broken packages as !BR2_avr32 ? That may be a rough ride though with all the dependencies. Regards.
On 20 January 2013 12:54, Gustavo Zacarias <gustavo@zacarias.com.ar> wrote: > With gentoo's 4.6.3 it fails for me in the same way as described at > Atmel's site http://www.atmel.no/buildroot/buildroot-issues.html > (Error: invalid register list) Okay. It's working for me on Ubuntu with gcc 4.6.3. > Do you know if the UC3 microcontrollers are in the same boat? > If they aren't there may still be some hope for the toolchain (at least > binutils/gcc, not much for uclibc/linux). I don't know, I'm afraid. I'm also using uc3b, but haven't had any contact with Atmel for some time now. Certainly I've heard no warning shots from Atmel about end-of-life for the uc3 series. > Testing and fixing is an issue on the toolchain side when there's no > upgrade path possible. I don't quite follow your meaning here, I'm afraid. > I wouldn't like to stick to old and potentially vulnerable versions of > packages (example: gnutls) because the toolchain is too old to handle > it, it's problematic. > And dragging arch-specific patches isn't fun either. Agreed. > Maybe we can keep it and start marking broken packages as !BR2_avr32 ? > That may be a rough ride though with all the dependencies. I think that's pretty much where we are right now, isn't it? Simon.
Dear Simon Dawson, On Sun, 20 Jan 2013 11:01:30 +0000, Simon Dawson wrote: > Yes, I'm using Buildroot for the continued development of a system > based on the Atmel ap7000. This system will be under > development/support for at least the next few years, I would imagine. Ok. > Yes, I think we discussed this briefly at the Buildroot Developer Days > in Barcelona. My understanding is that avr32 is regarded > semi-officially as an end-of-life architecture. Atmel technical > support are, for the time being, still dealing with support queries > for avr32. > > > Therefore, I'm wondering if we shouldn't mark this architecture as > > deprecated. > > From my own perspective, I'd rather keep the avr32 support in > Buildroot for now. I don't know how many other people are using the > architecture --- not that many, I suspect. Would that be a major > problem? Long term it is a problem to have a gcc 4.2.x only toolchain and an old uClibc version. Some packages will fail to build because gcc is too old, we'll start depending on some uClibc features that the old uClibc version does not have, etc. > I don't know how much effort would be involved in migrating to newer > gcc, binutils and uClibc; have you any idea? I know OpenWRT has some AVR32 support patches for more recent gcc versions (maybe gcc 4.5 or something, I don't remember). I tried once using them, but it wasn't straightforward, and I didn't want to spend too much time on AVR32, honestly :) Best regards, Thomas
On 01/20/2013 10:22 AM, Simon Dawson wrote: >> Testing and fixing is an issue on the toolchain side when there's no >> upgrade path possible. > > I don't quite follow your meaning here, I'm afraid. Some of the breakage is toolchain-related and we can't upgrade it. Most of the time it's gcc IIRC. Like the internal compiler errors for external toolchains, other than blacklisting/disabling packages there's not much to do. >> Maybe we can keep it and start marking broken packages as !BR2_avr32 ? >> That may be a rough ride though with all the dependencies. > > I think that's pretty much where we are right now, isn't it? I don't recall if that's what was agreed on the meetings (particularly since i never went to one). But at some point it won't be a workable compromise i'm afraid. Regards.
On 20 January 2013 14:21, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Long term it is a problem to have a gcc 4.2.x only toolchain and an old > uClibc version. Some packages will fail to build because gcc is too > old, we'll start depending on some uClibc features that the old uClibc > version does not have, etc. Okay, understood. > I know OpenWRT has some AVR32 support patches for more recent gcc > versions (maybe gcc 4.5 or something, I don't remember). I tried once > using them, but it wasn't straightforward, and I didn't want to spend > too much time on AVR32, honestly :) Thanks for the lead; I'll see if I can get anywhere with the OpenWRT patches. Simon.
On 20 January 2013 14:22, Gustavo Zacarias <gustavo@zacarias.com.ar> wrote: > Some of the breakage is toolchain-related and we can't upgrade it. > Most of the time it's gcc IIRC. > Like the internal compiler errors for external toolchains, other than > blacklisting/disabling packages there's not much to do. Right, I understand. Thanks for the clarification. Simon.
diff --git a/toolchain/uClibc/uClibc-0.9.31.1-netlinkaccess-header-types.patch.avr32 b/toolchain/uClibc/uClibc-0.9.31.1-netlinkaccess-header-types.patch.avr32 new file mode 100644 index 0000000..5e7027c --- /dev/null +++ b/toolchain/uClibc/uClibc-0.9.31.1-netlinkaccess-header-types.patch.avr32 @@ -0,0 +1,37 @@ +uClibc 0.9.31.1 fails to build for avr32 using recent (3.7.x) kernel +headers. The build failure looks like the following. + + CC libc/inet/if_index.os +In file included from /home/simond/TrainFX/code/git/third_party/buildroot.backports/output/toolchain/linux/include/linux/rtnetlink.h:6, + from libc/inet/netlinkaccess.h:34, + from libc/inet/if_index.c:36: +/home/simond/TrainFX/code/git/third_party/buildroot.backports/output/toolchain/linux/include/linux/if_link.h:291: error: expected specifier-qualifier-list before '__be16' +make[1]: *** [libc/inet/if_index.os] Error 1 +make[1]: Leaving directory `/home/simond/TrainFX/code/git/third_party/buildroot.backports/output/toolchain/uClibc-0.9.31.1' +make: *** [/home/simond/TrainFX/code/git/third_party/buildroot.backports/output/toolchain/uClibc-0.9.31.1/lib/libc.a] Error 2 + +This patch adjusts the system type definitions in the netlinkaccess.h +header, updating the types to match those used in uClibc 0.9.33.2. + +Signed-off-by: Simon Dawson <spdawson@gmail.com> + +diff -Nurp a/libc/inet/netlinkaccess.h b/libc/inet/netlinkaccess.h +--- a/libc/inet/netlinkaccess.h 2011-06-08 19:58:40.000000000 +0100 ++++ b/libc/inet/netlinkaccess.h 2012-12-20 12:16:34.251965672 +0000 +@@ -22,15 +22,8 @@ + #include <features.h> + #include <stdint.h> + #include <unistd.h> +-#include <sys/types.h> +- + #if defined __ASSUME_NETLINK_SUPPORT || defined __UCLIBC_USE_NETLINK__ +-#define _LINUX_TYPES_H +-typedef uint8_t __u8; +-typedef uint16_t __u16; +-typedef uint32_t __u32; +-typedef uint64_t __u64; +-typedef int32_t __s32; ++#include <asm/types.h> + #include <linux/rtnetlink.h> + #include <linux/netlink.h> +