[RFC] Fix avr32 build using internal toolchain

From: Simon Dawson <spdawson@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.

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

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.