Fix avr32 build using internal toolchain
RFC PATCH 1/1 Fix avr32 build using internal toolchain
From: Simon Dawson <[email protected]>
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.
--- ...0.9.31.1-netlinkaccess-header-types.patch.avr32 | 37 ++++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 toolchain/uClibc/uClibc-0.9.31.1-netlinkaccess-header-types.patch.avr32
toolchain/uClibc/uClibc-0.9.31.1-netlinkaccess-header-types.patch.avr32 new file +37 -0
@@ -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 <[email protected]> + +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> +
Signature · 1 line
1.7.10.4
RFC PATCH 1/1 Fix avr32 build using internal toolchain
Hello Simon,
Quoted 2 lines · spdawson at gmail.com
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
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
RFC PATCH 1/1 Fix avr32 build using internal toolchain
Hi Thomas,
Quoted 2 lines · Thomas Petazzoni
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.
Quoted 6 lines
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...
Quoted 4 lines
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.
Quoted 2 lines
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.
RFC PATCH 1/1 Fix avr32 build using internal toolchain
Quoted 3 lines · Simon Dawson
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)
Quoted 5 lines
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).
Quoted 4 lines
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.
RFC PATCH 1/1 Fix avr32 build using internal toolchain
Quoted 3 lines · Gustavo Zacarias
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.
Quoted 3 lines
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.
Quoted 2 lines
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.
Quoted 4 lines
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.
Quoted 2 lines
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.
RFC PATCH 1/1 Fix avr32 build using internal toolchain
Quoted 4 lines · Simon Dawson
Quoted 2 lines
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.
Quoted 4 lines
Quoted 2 lines
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.
RFC PATCH 1/1 Fix avr32 build using internal toolchain
Quoted 4 lines · Gustavo Zacarias
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.
RFC PATCH 1/1 Fix avr32 build using internal toolchain
In reply to Simon DawsonDear Simon Dawson,
Quoted 3 lines · Simon Dawson
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.
Quoted 6 lines
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.
Quoted 7 lines
Quoted 2 lines
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.
Quoted 2 lines
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
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
RFC PATCH 1/1 Fix avr32 build using internal toolchain
Quoted 4 lines · Thomas Petazzoni
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.
Quoted 4 lines
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.