All of lore.kernel.org
 help / color / mirror / Atom feed
* [Buildroot] AVR32 toolchain build failure
@ 2013-11-13 21:36 Thomas Petazzoni
  2013-11-14  8:53 ` Simon Dawson
  0 siblings, 1 reply; 42+ messages in thread
From: Thomas Petazzoni @ 2013-11-13 21:36 UTC (permalink / raw)
  To: buildroot

Hello Simon,

I've tried to build an AVR32 toolchain with 2013.11-rc1, with the
following defconfig:

BR2_avr32=y
BR2_TOOLCHAIN_BUILDROOT_LARGEFILE=y
BR2_TOOLCHAIN_BUILDROOT_INET_IPV6=y
BR2_TOOLCHAIN_BUILDROOT_INET_RPC=y
BR2_TOOLCHAIN_BUILDROOT_WCHAR=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_INIT_NONE=y
# BR2_PACKAGE_BUSYBOX is not set
# BR2_TARGET_ROOTFS_TAR is not set

and the build failed with:

In file included from /opt/br-avr32-full-2013.11-rc1/usr/avr32-buildroot-linux-uclibc/sysroot/usr/include/linux/kernel.h:4,
                 from /opt/br-avr32-full-2013.11-rc1/usr/avr32-buildroot-linux-uclibc/sysroot/usr/include/linux/netlink.h:4,
                 from /opt/br-avr32-full-2013.11-rc1/usr/avr32-buildroot-linux-uclibc/sysroot/usr/include/linux/rtnetlink.h:5,
                 from libc/inet/netlinkaccess.h:27,
                 from libc/inet/if_index.c:36:
/opt/br-avr32-full-2013.11-rc1/usr/avr32-buildroot-linux-uclibc/sysroot/usr/include/linux/sysinfo.h:8: error: expected specifier-qualifier-list before '__kernel_long_t'
make[1]: *** [libc/inet/if_index.os] Error 1
make[1]: Leaving directory `/opt/toolchain-build/build/uclibc-0.9.31.1'

It is apparently reported at:

  https://lkml.org/lkml/2013/5/18/1

However, I've also built several other toolchains with the same
Buildroot version and haven't had any problem.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-11-13 21:36 [Buildroot] AVR32 toolchain build failure Thomas Petazzoni
@ 2013-11-14  8:53 ` Simon Dawson
  2013-11-14  9:10   ` Thomas Petazzoni
  0 siblings, 1 reply; 42+ messages in thread
From: Simon Dawson @ 2013-11-14  8:53 UTC (permalink / raw)
  To: buildroot

Hi Thomas,

On 13 November 2013 21:36, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> I've tried to build an AVR32 toolchain with 2013.11-rc1, with the
> following defconfig:
>
> BR2_avr32=y
> BR2_TOOLCHAIN_BUILDROOT_LARGEFILE=y
> BR2_TOOLCHAIN_BUILDROOT_INET_IPV6=y
> BR2_TOOLCHAIN_BUILDROOT_INET_RPC=y
> BR2_TOOLCHAIN_BUILDROOT_WCHAR=y
> BR2_TOOLCHAIN_BUILDROOT_CXX=y
> BR2_INIT_NONE=y
> # BR2_PACKAGE_BUSYBOX is not set
> # BR2_TARGET_ROOTFS_TAR is not set
>
> and the build failed with:
>
> In file included from /opt/br-avr32-full-2013.11-rc1/usr/avr32-buildroot-linux-uclibc/sysroot/usr/include/linux/kernel.h:4,
>                  from /opt/br-avr32-full-2013.11-rc1/usr/avr32-buildroot-linux-uclibc/sysroot/usr/include/linux/netlink.h:4,
>                  from /opt/br-avr32-full-2013.11-rc1/usr/avr32-buildroot-linux-uclibc/sysroot/usr/include/linux/rtnetlink.h:5,
>                  from libc/inet/netlinkaccess.h:27,
>                  from libc/inet/if_index.c:36:
> /opt/br-avr32-full-2013.11-rc1/usr/avr32-buildroot-linux-uclibc/sysroot/usr/include/linux/sysinfo.h:8: error: expected specifier-qualifier-list before '__kernel_long_t'
> make[1]: *** [libc/inet/if_index.os] Error 1
> make[1]: Leaving directory `/opt/toolchain-build/build/uclibc-0.9.31.1'

Yes, using your defconfig the build fails for me too. For my avr32
projects, I'm using 3.4.x kernel and headers. The offending commit

  http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=ccdfcc398594

appears not to have been back-ported to the 3.4.x series.

> It is apparently reported at:
>
>   https://lkml.org/lkml/2013/5/18/1
>
> However, I've also built several other toolchains with the same
> Buildroot version and haven't had any problem.

That's odd. I wonder if your other toolchains are using older kernel headers?

I'm not sure what the right fix is for this. Do you have any suggestions?

Simon.

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-11-14  8:53 ` Simon Dawson
@ 2013-11-14  9:10   ` Thomas Petazzoni
  2013-11-15  8:58     ` Simon Dawson
  0 siblings, 1 reply; 42+ messages in thread
From: Thomas Petazzoni @ 2013-11-14  9:10 UTC (permalink / raw)
  To: buildroot

Dear Simon Dawson,

On Thu, 14 Nov 2013 08:53:42 +0000, Simon Dawson wrote:

> > In file included from /opt/br-avr32-full-2013.11-rc1/usr/avr32-buildroot-linux-uclibc/sysroot/usr/include/linux/kernel.h:4,
> >                  from /opt/br-avr32-full-2013.11-rc1/usr/avr32-buildroot-linux-uclibc/sysroot/usr/include/linux/netlink.h:4,
> >                  from /opt/br-avr32-full-2013.11-rc1/usr/avr32-buildroot-linux-uclibc/sysroot/usr/include/linux/rtnetlink.h:5,
> >                  from libc/inet/netlinkaccess.h:27,
> >                  from libc/inet/if_index.c:36:
> > /opt/br-avr32-full-2013.11-rc1/usr/avr32-buildroot-linux-uclibc/sysroot/usr/include/linux/sysinfo.h:8: error: expected specifier-qualifier-list before '__kernel_long_t'
> > make[1]: *** [libc/inet/if_index.os] Error 1
> > make[1]: Leaving directory `/opt/toolchain-build/build/uclibc-0.9.31.1'
> 
> Yes, using your defconfig the build fails for me too. For my avr32
> projects, I'm using 3.4.x kernel and headers. The offending commit
> 
>   http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=ccdfcc398594
> 
> appears not to have been back-ported to the 3.4.x series.

Ok.

> > It is apparently reported at:
> >
> >   https://lkml.org/lkml/2013/5/18/1
> >
> > However, I've also built several other toolchains with the same
> > Buildroot version and haven't had any problem.
> 
> That's odd. I wonder if your other toolchains are using older kernel headers?

No, they were all using the 3.12 kernel headers:

$ grep "linux-headers.*Extracting" *2013.11*log
br-arm-basic-2013.11-rc1-build.log:>>> linux-headers 3.12 Extracting
br-arm-cortex-a9-bleeding-edge-2013.11-rc1-build.log:>>> linux-headers 3.12 Extracting
br-arm-full-2013.11-rc1-build.log:>>> linux-headers 3.12 Extracting
br-arm11-full-nothread-2013.11-rc1-build.log:>>> linux-headers 3.12 Extracting
br-avr32-full-2013.11-rc1-build.log:>>> linux-headers 3.12 Extracting
br-i386-pentium4-full-2013.11-rc1-build.log:>>> linux-headers 3.12 Extracting
br-mips64-largefile-basic-2013.11-rc1-build.log:>>> linux-headers 3.12 Extracting
br-mipsel-o32-full-2013.11-rc1-build.log:>>> linux-headers 3.12 Extracting
br-powerpc-603e-basic-cpp-2013.11-rc1-build.log:>>> linux-headers 3.12 Extracting
br-powerpc-e500mc-full-2013.11-rc1-build.log:>>> linux-headers 3.12 Extracting
br-sh4-full-2013.11-rc1-build.log:>>> linux-headers 3.12 Extracting
br-x86-64-atom-no-rpc-no-ipv6-2013.11-rc1-build.log:>>> linux-headers 3.12 Extracting
br-x86-64-core2-full-2013.11-rc1-build.log:>>> linux-headers 3.12 Extracting

and all of them were successful, except:

 * AVR32 (problem exposed above)
 * SH4 (a multilib problem for which I know the cause)

> I'm not sure what the right fix is for this. Do you have any suggestions?

Well, the difference between all of these builds and the AVR32 one is
obviously that AVR32 is using uClibc 0.9.31, right? Seems like uClibc
0.9.33 is not affected by the problem. So I would suggest that a fix is
made to uClibc 0.9.31 to avoid this problem.

Maybe it's just
uclibc-0004-libc-sysdeps-add-__kernel_long-and-__kernel_ulong.patch
from our 0.9.33.2 patch stack that needs to be backported to uClibc
0.9.31 ?

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-11-14  9:10   ` Thomas Petazzoni
@ 2013-11-15  8:58     ` Simon Dawson
  0 siblings, 0 replies; 42+ messages in thread
From: Simon Dawson @ 2013-11-15  8:58 UTC (permalink / raw)
  To: buildroot

Hi Thomas,

On 14 November 2013 09:10, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Well, the difference between all of these builds and the AVR32 one is
> obviously that AVR32 is using uClibc 0.9.31, right? Seems like uClibc
> 0.9.33 is not affected by the problem. So I would suggest that a fix is
> made to uClibc 0.9.31 to avoid this problem.
>
> Maybe it's just
> uclibc-0004-libc-sysdeps-add-__kernel_long-and-__kernel_ulong.patch
> from our 0.9.33.2 patch stack that needs to be backported to uClibc
> 0.9.31 ?

Okay; thanks for the tip. I'll submit a patch for this.

Simon.

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-08 17:59                         ` Thomas Petazzoni
@ 2013-08-13  6:15                           ` Arnout Vandecappelle
  0 siblings, 0 replies; 42+ messages in thread
From: Arnout Vandecappelle @ 2013-08-13  6:15 UTC (permalink / raw)
  To: buildroot

On 08/08/13 19:59, Thomas Petazzoni wrote:
> Dear Simon Dawson,
>
> On Thu, 8 Aug 2013 17:18:24 +0100, Simon Dawson wrote:
>
>> On 8 August 2013 11:56, Gustavo Zacarias <gustavo@zacarias.com.ar> wrote:
>>> 1) Reinstate patches in the appropiate place since uclibc was packaged.
>>> 2) Probably add various "depends on !BR2_avr32" in packages that need
>>> newer syscalls (alternatively add a ton of backports for uclibc 0.9.31
>>> from newer releases).
>>> 3) Revert startfiles cleanup to the old manual way, adding new
>>> exceptions/modes for the noMMU crowd (it wasn't handled before) - or
>>> alternatively also patch the uclibc 0.9.31 makefile to make it more
>>> 0.9.32/33-ish like.
>>
>> That doesn't sound too bad. I'm happy to do this work, if appropriate.
>> Perhaps your point #2 will not be necessary in the short term...?
>
> Ok, so let's do this maybe?
>
> I think #2 is necessary, we already have some packages that use
> syscalls that aren't provided by uClibc 0.9.31. But ok, it's just a
> matter of adding another bunch of "depends on !BR2_avr32", it's not
> fun, but it's not a big deal either.
>
> As long as someone is interested in keeping AVR32 support in place, and
> is willing to do some effort to keep this support in a reasonably good
> shape in upstream Buildroot, I'm fine with keeping it.

  What about just not including it in the autobuilders, and adding a big 
comment in the top-level menuconfig saying that AVR32 is not really 
supported and things might break?

  I think it would be good if Simon, Alexander and Thiago can use 
upstream buildroot without custom forks, but if these are the only users 
then it's not really needed to include it in the autobuilders IMHO.

  Regards,
  Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-09 20:29                                 ` Thomas Petazzoni
@ 2013-08-09 22:34                                   ` Gustavo Zacarias
  0 siblings, 0 replies; 42+ messages in thread
From: Gustavo Zacarias @ 2013-08-09 22:34 UTC (permalink / raw)
  To: buildroot

On 08/09/2013 05:29 PM, Thomas Petazzoni wrote:
> On Fri, 9 Aug 2013 13:12:51 +0200, Thomas De Schampheleire wrote:
> 
>> I can now also confirm that setting HOSTCC and HOSTCXX explicitly to
>> gcc-4.6 and g++-4.8, is the key to getting C++ support to build for
>> AVR32.
>>
>> One approach to guard against such problems is to check this in
>> dependencies.sh/mk: if AVR32 is selected with C++ toolchain support,
>> and the host gcc is newer than 4.6 (or maybe newer-or-equal-than
>> 4.7.0; not sure where the problem was introduced), then we bail out
>> and ask the user to either disable C++ support, set their host
>> compiler to an older version, or select another architecture (kidding
>> about that last one, of course).
> 
> That's the only reasonable solution I believe.

Not really, for me:

gcc version 4.6.3 (Gentoo 4.6.3 p1.10, pie-0.5.2)

Fails miserably on any situation, even the most bare (non
c++/wchar/nls/ipv6/rpc) configuration.
If it's the USE flags (pretty default), some gentoo patches to gcc or
what else i don't know, but i can't get past gcc-initial (this being the
current stable on the normal architectures).
Regards.

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-09 11:12                               ` Thomas De Schampheleire
@ 2013-08-09 20:29                                 ` Thomas Petazzoni
  2013-08-09 22:34                                   ` Gustavo Zacarias
  0 siblings, 1 reply; 42+ messages in thread
From: Thomas Petazzoni @ 2013-08-09 20:29 UTC (permalink / raw)
  To: buildroot

Dear Thomas De Schampheleire,

On Fri, 9 Aug 2013 13:12:51 +0200, Thomas De Schampheleire wrote:

> I can now also confirm that setting HOSTCC and HOSTCXX explicitly to
> gcc-4.6 and g++-4.8, is the key to getting C++ support to build for
> AVR32.
> 
> One approach to guard against such problems is to check this in
> dependencies.sh/mk: if AVR32 is selected with C++ toolchain support,
> and the host gcc is newer than 4.6 (or maybe newer-or-equal-than
> 4.7.0; not sure where the problem was introduced), then we bail out
> and ask the user to either disable C++ support, set their host
> compiler to an older version, or select another architecture (kidding
> about that last one, of course).

That's the only reasonable solution I believe.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-09  7:16                             ` Simon Dawson
@ 2013-08-09 11:12                               ` Thomas De Schampheleire
  2013-08-09 20:29                                 ` Thomas Petazzoni
  0 siblings, 1 reply; 42+ messages in thread
From: Thomas De Schampheleire @ 2013-08-09 11:12 UTC (permalink / raw)
  To: buildroot

On Fri, Aug 9, 2013 at 9:16 AM, Simon Dawson <spdawson@gmail.com> wrote:
> Hi Thomas,
>
> On 8 August 2013 21:09, Thomas De Schampheleire
> <patrickdepinguin+buildroot@gmail.com> wrote:
>> So you are saying that if I upgrade my host gcc (the native one) to
>> 4.6, that the cross AVR32 gcc will build successfully, and not suffer
>> from the relocation truncation messages?
>
> I believe so, yes.

I can now also confirm that setting HOSTCC and HOSTCXX explicitly to
gcc-4.6 and g++-4.8, is the key to getting C++ support to build for
AVR32.

One approach to guard against such problems is to check this in
dependencies.sh/mk: if AVR32 is selected with C++ toolchain support,
and the host gcc is newer than 4.6 (or maybe newer-or-equal-than
4.7.0; not sure where the problem was introduced), then we bail out
and ask the user to either disable C++ support, set their host
compiler to an older version, or select another architecture (kidding
about that last one, of course).

Another solution, but way overkill IMO, is to build a host-gcc 4.6
first if no suitable gcc can be found (in the avr32 + C++ support
case).

What do you all think?

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-08 20:09                           ` Thomas De Schampheleire
  2013-08-08 20:24                             ` Thomas De Schampheleire
@ 2013-08-09  7:16                             ` Simon Dawson
  2013-08-09 11:12                               ` Thomas De Schampheleire
  1 sibling, 1 reply; 42+ messages in thread
From: Simon Dawson @ 2013-08-09  7:16 UTC (permalink / raw)
  To: buildroot

Hi Thomas,

On 8 August 2013 21:09, Thomas De Schampheleire
<patrickdepinguin+buildroot@gmail.com> wrote:
> So you are saying that if I upgrade my host gcc (the native one) to
> 4.6, that the cross AVR32 gcc will build successfully, and not suffer
> from the relocation truncation messages?

I believe so, yes.

> Can you explain how this can happen, do you have more details?

I don't have any more details, I'm afraid.

Simon.

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-08 20:24                             ` Thomas De Schampheleire
  2013-08-08 22:22                               ` Thiago A. Corrêa
@ 2013-08-09  4:51                               ` Alexander Lukichev
  1 sibling, 0 replies; 42+ messages in thread
From: Alexander Lukichev @ 2013-08-09  4:51 UTC (permalink / raw)
  To: buildroot

Hi all,

2013/8/8 Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com>

> >> That probably explains why your builds fail...
> > So you are saying that if I upgrade my host gcc (the native one) to
> > 4.6, that the cross AVR32 gcc will build successfully, and not suffer
> > from the relocation truncation messages?
>
> By the way, my host gcc is:
> $ gcc --version
> gcc (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2
>

My gcc is:

$ gcc --version
gcc (GCC) 4.5.1 20100924 (Red Hat 4.5.1-4)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


--
Best regards,
  Alexander Lukichev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130809/c955b328/attachment-0001.html>

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-08 20:24                             ` Thomas De Schampheleire
@ 2013-08-08 22:22                               ` Thiago A. Corrêa
  2013-08-09  4:51                               ` Alexander Lukichev
  1 sibling, 0 replies; 42+ messages in thread
From: Thiago A. Corrêa @ 2013-08-08 22:22 UTC (permalink / raw)
  To: buildroot

Hi,

On Thu, Aug 8, 2013 at 5:24 PM, Thomas De Schampheleire
<patrickdepinguin+buildroot@gmail.com> wrote:
>> So you are saying that if I upgrade my host gcc (the native one) to
>> 4.6, that the cross AVR32 gcc will build successfully, and not suffer
>
> By the way, my host gcc is:
> gcc (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2

I was using AVR32 and we still have boards with it in the field. I can
second that using a newer host gcc will not build avr32 toolchain.
Even though I haven't built for AVR32 in a long time, I remember that
I had to keep an old gcc on my Gentoo linux just for the AVR32
toolchain to build. On Gentoo it's a matter of gcc-config switching if
it's installed.

Kind Regards,
     Thiago A. Correa

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-08 20:09                           ` Thomas De Schampheleire
@ 2013-08-08 20:24                             ` Thomas De Schampheleire
  2013-08-08 22:22                               ` Thiago A. Corrêa
  2013-08-09  4:51                               ` Alexander Lukichev
  2013-08-09  7:16                             ` Simon Dawson
  1 sibling, 2 replies; 42+ messages in thread
From: Thomas De Schampheleire @ 2013-08-08 20:24 UTC (permalink / raw)
  To: buildroot

On Thu, Aug 8, 2013 at 10:09 PM, Thomas De Schampheleire
<patrickdepinguin+buildroot@gmail.com> wrote:
> Hi Simon,
>
> On Thu, Aug 8, 2013 at 9:42 PM, Simon Dawson <spdawson@gmail.com> wrote:
>> Hi Thomas,
>>
>> On 8 August 2013 18:34, Thomas De Schampheleire
>> <patrickdepinguin+buildroot@gmail.com> wrote:
>>> That's interesting. I've tried building the atngw100_defconfig on
>>> 2013.05, 2013.02, and 2012.02, and none of them build successfully if
>>> I enable C++ support (nothing else changed).
>>> Could you send your config file for the working C++ build, then I can
>>> try here. Either there is some build system difference, or (more
>>> likely) there is a combination of config options that doesn't work.
>>
>> Oops. I had provided some misinformation, I'm afraid. I'm actually
>> using gcc 4.6 to build the toolchain --- I had forgotten that I'd
>> exported HOSTCC and HOSTCXX for the build.
>>
>> That probably explains why your builds fail...
>>
>
> So you are saying that if I upgrade my host gcc (the native one) to
> 4.6, that the cross AVR32 gcc will build successfully, and not suffer
> from the relocation truncation messages?
> Can you explain how this can happen, do you have more details?

By the way, my host gcc is:
$ gcc --version
gcc (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-08 19:42                         ` Simon Dawson
@ 2013-08-08 20:09                           ` Thomas De Schampheleire
  2013-08-08 20:24                             ` Thomas De Schampheleire
  2013-08-09  7:16                             ` Simon Dawson
  0 siblings, 2 replies; 42+ messages in thread
From: Thomas De Schampheleire @ 2013-08-08 20:09 UTC (permalink / raw)
  To: buildroot

Hi Simon,

On Thu, Aug 8, 2013 at 9:42 PM, Simon Dawson <spdawson@gmail.com> wrote:
> Hi Thomas,
>
> On 8 August 2013 18:34, Thomas De Schampheleire
> <patrickdepinguin+buildroot@gmail.com> wrote:
>> That's interesting. I've tried building the atngw100_defconfig on
>> 2013.05, 2013.02, and 2012.02, and none of them build successfully if
>> I enable C++ support (nothing else changed).
>> Could you send your config file for the working C++ build, then I can
>> try here. Either there is some build system difference, or (more
>> likely) there is a combination of config options that doesn't work.
>
> Oops. I had provided some misinformation, I'm afraid. I'm actually
> using gcc 4.6 to build the toolchain --- I had forgotten that I'd
> exported HOSTCC and HOSTCXX for the build.
>
> That probably explains why your builds fail...
>

So you are saying that if I upgrade my host gcc (the native one) to
4.6, that the cross AVR32 gcc will build successfully, and not suffer
from the relocation truncation messages?
Can you explain how this can happen, do you have more details?

Thanks,
Thomas

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-08 17:34                       ` Thomas De Schampheleire
  2013-08-08 17:57                         ` Thomas Petazzoni
@ 2013-08-08 19:42                         ` Simon Dawson
  2013-08-08 20:09                           ` Thomas De Schampheleire
  1 sibling, 1 reply; 42+ messages in thread
From: Simon Dawson @ 2013-08-08 19:42 UTC (permalink / raw)
  To: buildroot

Hi Thomas,

On 8 August 2013 18:34, Thomas De Schampheleire
<patrickdepinguin+buildroot@gmail.com> wrote:
> That's interesting. I've tried building the atngw100_defconfig on
> 2013.05, 2013.02, and 2012.02, and none of them build successfully if
> I enable C++ support (nothing else changed).
> Could you send your config file for the working C++ build, then I can
> try here. Either there is some build system difference, or (more
> likely) there is a combination of config options that doesn't work.

Oops. I had provided some misinformation, I'm afraid. I'm actually
using gcc 4.6 to build the toolchain --- I had forgotten that I'd
exported HOSTCC and HOSTCXX for the build.

That probably explains why your builds fail...

Simon.

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-08 17:57                         ` Thomas Petazzoni
@ 2013-08-08 18:05                           ` Thomas De Schampheleire
  0 siblings, 0 replies; 42+ messages in thread
From: Thomas De Schampheleire @ 2013-08-08 18:05 UTC (permalink / raw)
  To: buildroot

Hi Thomas,

On Thu, Aug 8, 2013 at 7:57 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Thomas De Schampheleire,
>
> On Thu, 8 Aug 2013 19:34:55 +0200, Thomas De Schampheleire wrote:
>
>> That's interesting. I've tried building the atngw100_defconfig on
>> 2013.05, 2013.02, and 2012.02, and none of them build successfully if
>> I enable C++ support (nothing else changed).
>> Could you send your config file for the working C++ build, then I can
>> try here. Either there is some build system difference, or (more
>> likely) there is a combination of config options that doesn't work.
>
> Do you have locale support enabled?
>
> I'm pretty sure there was a combination like avr32 + C++ + locale that
> never worked, and we even had a set of "depends on" to ensure such a
> combination could never be enabled.

No I do not have locale support enabled. I literally take the
defconfig, and just enable C++ support.

Does this scenario work for you?

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-08 16:18                       ` Simon Dawson
  2013-08-08 17:57                         ` Gustavo Zacarias
@ 2013-08-08 17:59                         ` Thomas Petazzoni
  2013-08-13  6:15                           ` Arnout Vandecappelle
  1 sibling, 1 reply; 42+ messages in thread
From: Thomas Petazzoni @ 2013-08-08 17:59 UTC (permalink / raw)
  To: buildroot

Dear Simon Dawson,

On Thu, 8 Aug 2013 17:18:24 +0100, Simon Dawson wrote:

> On 8 August 2013 11:56, Gustavo Zacarias <gustavo@zacarias.com.ar> wrote:
> > 1) Reinstate patches in the appropiate place since uclibc was packaged.
> > 2) Probably add various "depends on !BR2_avr32" in packages that need
> > newer syscalls (alternatively add a ton of backports for uclibc 0.9.31
> > from newer releases).
> > 3) Revert startfiles cleanup to the old manual way, adding new
> > exceptions/modes for the noMMU crowd (it wasn't handled before) - or
> > alternatively also patch the uclibc 0.9.31 makefile to make it more
> > 0.9.32/33-ish like.
> 
> That doesn't sound too bad. I'm happy to do this work, if appropriate.
> Perhaps your point #2 will not be necessary in the short term...?

Ok, so let's do this maybe?

I think #2 is necessary, we already have some packages that use
syscalls that aren't provided by uClibc 0.9.31. But ok, it's just a
matter of adding another bunch of "depends on !BR2_avr32", it's not
fun, but it's not a big deal either.

As long as someone is interested in keeping AVR32 support in place, and
is willing to do some effort to keep this support in a reasonably good
shape in upstream Buildroot, I'm fine with keeping it.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-08 17:34                       ` Thomas De Schampheleire
@ 2013-08-08 17:57                         ` Thomas Petazzoni
  2013-08-08 18:05                           ` Thomas De Schampheleire
  2013-08-08 19:42                         ` Simon Dawson
  1 sibling, 1 reply; 42+ messages in thread
From: Thomas Petazzoni @ 2013-08-08 17:57 UTC (permalink / raw)
  To: buildroot

Dear Thomas De Schampheleire,

On Thu, 8 Aug 2013 19:34:55 +0200, Thomas De Schampheleire wrote:

> That's interesting. I've tried building the atngw100_defconfig on
> 2013.05, 2013.02, and 2012.02, and none of them build successfully if
> I enable C++ support (nothing else changed).
> Could you send your config file for the working C++ build, then I can
> try here. Either there is some build system difference, or (more
> likely) there is a combination of config options that doesn't work.

Do you have locale support enabled?

I'm pretty sure there was a combination like avr32 + C++ + locale that
never worked, and we even had a set of "depends on" to ensure such a
combination could never be enabled.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-08 16:18                       ` Simon Dawson
@ 2013-08-08 17:57                         ` Gustavo Zacarias
  2013-08-08 17:59                         ` Thomas Petazzoni
  1 sibling, 0 replies; 42+ messages in thread
From: Gustavo Zacarias @ 2013-08-08 17:57 UTC (permalink / raw)
  To: buildroot

On 08/08/2013 01:18 PM, Simon Dawson wrote:

> Hi Gustavo,
> 
> On 8 August 2013 11:56, Gustavo Zacarias <gustavo@zacarias.com.ar> wrote:
>> 1) Reinstate patches in the appropiate place since uclibc was packaged.
>> 2) Probably add various "depends on !BR2_avr32" in packages that need
>> newer syscalls (alternatively add a ton of backports for uclibc 0.9.31
>> from newer releases).
>> 3) Revert startfiles cleanup to the old manual way, adding new
>> exceptions/modes for the noMMU crowd (it wasn't handled before) - or
>> alternatively also patch the uclibc 0.9.31 makefile to make it more
>> 0.9.32/33-ish like.
> 
> That doesn't sound too bad. I'm happy to do this work, if appropriate.
> Perhaps your point #2 will not be necessary in the short term...?

There'll be some autobuilder failures if that's not done.
#3 will surely take time too since it was a hardcoded default before the
0.9.31 removal which made the internal blackfin toolchain never work (it
builds now at least, as far as "work" depends on having someone testing
things, work still remains but it's a start).
It also affects other nommu toolchains like ARM, but it's broken for
other reasons for now.
New packages and bumps might break for avr32 too, we just can't hold on
to old software being buggy and/or having security vulnerabilities just
to keep it running on old bitrot toolchains.

> I understand where you're coming from here. I'm not sure we're "going
> in circles" just yet, but appreciate that it may come to that.

If you want to volunteer continuous amounts of time into getting this
right, then maybe, i'm not the only one deciding here.
I can't get the toolchain to build and everything points to "install
some odd host gcc version" which isn't quite right - things are supposed
to work in many different normal scenarios.
But as Thomas said if the latest kernels don't work that's somewhat of a
bad omen.
Regards.

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-08 16:09                     ` Simon Dawson
@ 2013-08-08 17:34                       ` Thomas De Schampheleire
  2013-08-08 17:57                         ` Thomas Petazzoni
  2013-08-08 19:42                         ` Simon Dawson
  0 siblings, 2 replies; 42+ messages in thread
From: Thomas De Schampheleire @ 2013-08-08 17:34 UTC (permalink / raw)
  To: buildroot

Hi Simon,

On Thu, Aug 8, 2013 at 6:09 PM, Simon Dawson <spdawson@gmail.com> wrote:
> Hi Thomas
>
> On 8 August 2013 09:12, Thomas De Schampheleire
> <patrickdepinguin+buildroot@gmail.com> wrote:
>> So you are able to build a toolchain with C++ support for avr32, using
>> (a custom) buildroot? Is this a public buildroot fork that we can look
>> at? If not: do you know (or could you look up) which changes have been
>> made to make C++ support work?
>
> All I've done is to branch off of the Buildroot master just prior to
> commit 8abb5b33c1aae035cf48b1c81104b433ff884c64, which removed support
> for uClibc 0.9.31. I've then been cherry-picking commits from master,
> as required for my particular project.
>
> I haven't made this fork publicly available. I also haven't had to
> make any changes to get C++ support working --- it already worked for
> me. I'm using host gcc 4.7.3; and the Buildroot-generated toolchain
> builds host-binutils-2.18-avr32-1.0.1

That's interesting. I've tried building the atngw100_defconfig on
2013.05, 2013.02, and 2012.02, and none of them build successfully if
I enable C++ support (nothing else changed).
Could you send your config file for the working C++ build, then I can
try here. Either there is some build system difference, or (more
likely) there is a combination of config options that doesn't work.

Thanks,
Thomas

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-08 10:56                     ` Gustavo Zacarias
@ 2013-08-08 16:18                       ` Simon Dawson
  2013-08-08 17:57                         ` Gustavo Zacarias
  2013-08-08 17:59                         ` Thomas Petazzoni
  0 siblings, 2 replies; 42+ messages in thread
From: Simon Dawson @ 2013-08-08 16:18 UTC (permalink / raw)
  To: buildroot

Hi Gustavo,

On 8 August 2013 11:56, Gustavo Zacarias <gustavo@zacarias.com.ar> wrote:
> 1) Reinstate patches in the appropiate place since uclibc was packaged.
> 2) Probably add various "depends on !BR2_avr32" in packages that need
> newer syscalls (alternatively add a ton of backports for uclibc 0.9.31
> from newer releases).
> 3) Revert startfiles cleanup to the old manual way, adding new
> exceptions/modes for the noMMU crowd (it wasn't handled before) - or
> alternatively also patch the uclibc 0.9.31 makefile to make it more
> 0.9.32/33-ish like.

That doesn't sound too bad. I'm happy to do this work, if appropriate.
Perhaps your point #2 will not be necessary in the short term...?

> In my opinion, sorry if it hurts someone, we're going in circles trying
> to keep up with a dead architecture, because that's what it is, no
> matter how much support some people/companies want to give for their
> products the onus shouldn't be on us that things weren't upstreamed in a
> proper fashion which would make things far more simple.

I understand where you're coming from here. I'm not sure we're "going
in circles" just yet, but appreciate that it may come to that.

Simon.

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-08  8:12                   ` Thomas De Schampheleire
@ 2013-08-08 16:09                     ` Simon Dawson
  2013-08-08 17:34                       ` Thomas De Schampheleire
  0 siblings, 1 reply; 42+ messages in thread
From: Simon Dawson @ 2013-08-08 16:09 UTC (permalink / raw)
  To: buildroot

Hi Thomas

On 8 August 2013 09:12, Thomas De Schampheleire
<patrickdepinguin+buildroot@gmail.com> wrote:
> So you are able to build a toolchain with C++ support for avr32, using
> (a custom) buildroot? Is this a public buildroot fork that we can look
> at? If not: do you know (or could you look up) which changes have been
> made to make C++ support work?

All I've done is to branch off of the Buildroot master just prior to
commit 8abb5b33c1aae035cf48b1c81104b433ff884c64, which removed support
for uClibc 0.9.31. I've then been cherry-picking commits from master,
as required for my particular project.

I haven't made this fork publicly available. I also haven't had to
make any changes to get C++ support working --- it already worked for
me. I'm using host gcc 4.7.3; and the Buildroot-generated toolchain
builds host-binutils-2.18-avr32-1.0.1

Simon.

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-05 12:29 ` Thomas De Schampheleire
  2013-08-06  9:27   ` Alexander Lukichev
@ 2013-08-08 15:35   ` Alexander Lukichev
  1 sibling, 0 replies; 42+ messages in thread
From: Alexander Lukichev @ 2013-08-08 15:35 UTC (permalink / raw)
  To: buildroot

Hello Thomas,

  Sorry, I was wrong earlier saying that I had the same error as you. It
was what the log mentioned here describes.

  It is strange but your config, almost unchanged except for download
directory and the number of jobs 8 vs 5, produces a different error while
building the final toolchain on my machine: it breaks on trying to make a
libstdc++_pic.a library. This could be solved with the attached patch. Here
is what happens on my machine:

Making install in src
make[4]: Entering directory
`/home/alukiche/Projects/buildroot/buildroot-project/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/src'
make[5]: Entering directory
`/home/alukiche/Projects/buildroot/buildroot-project/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/src'
test -z
"/home/alukiche/Projects/buildroot/buildroot-project/output/host/usr/avr32-buildroot-linux-uclibc/lib"
|| mkdir -p --
"/home/alukiche/Projects/buildroot/buildroot-project/output/host/usr/avr32-buildroot-linux-uclibc/lib"
/home/alukiche/Projects/buildroot/buildroot-project/output/host/usr/avr32-buildroot-linux-uclibc/bin/ar
cru libstdc++_pic.a *.o ../libsupc++/*.o
make[5]: Nothing to be done for `install-data-am'.
/home/alukiche/Projects/buildroot/buildroot-project/output/host/usr/avr32-buildroot-linux-uclibc/bin/ar:
*.o: No such file or directory
make[5]: *** [install-exec-local] Error 1
make[5]: *** Waiting for unfinished jobs....
 /bin/sh ../libtool --mode=install /usr/bin/install -c  'libstdc++.la'
'/home/alukiche/Projects/buildroot/buildroot-project/output/host/usr/avr32-buildroot-linux-uclibc/lib/libstdc++.la'
/usr/bin/install -c .libs/libstdc++.so.6.0.9
/home/alukiche/Projects/buildroot/buildroot-project/output/host/usr/avr32-buildroot-linux-uclibc/lib/libstdc++.so.6.0.9
(cd
/home/alukiche/Projects/buildroot/buildroot-project/output/host/usr/avr32-buildroot-linux-uclibc/lib
&& rm -f libstdc++.so.6 && ln -s libstdc++.so.6.0.9 libstdc++.so.6)
(cd
/home/alukiche/Projects/buildroot/buildroot-project/output/host/usr/avr32-buildroot-linux-uclibc/lib
&& rm -f libstdc++.so && ln -s libstdc++.so.6.0.9 libstdc++.so)
/usr/bin/install -c .libs/libstdc++.lai
/home/alukiche/Projects/buildroot/buildroot-project/output/host/usr/avr32-buildroot-linux-uclibc/lib/libstdc++.la
PATH="$PATH:/sbin" ldconfig -n
/home/alukiche/Projects/buildroot/buildroot-project/output/host/usr/avr32-buildroot-linux-uclibc/lib
----------------------------------------------------------------------
Libraries have been installed in:

/home/alukiche/Projects/buildroot/buildroot-project/output/host/usr/avr32-buildroot-linux-uclibc/lib

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-Wl,--rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
make[5]: Leaving directory
`/home/alukiche/Projects/buildroot/buildroot-project/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/src'
make[4]: *** [install-am] Error 2
make[4]: Leaving directory
`/home/alukiche/Projects/buildroot/buildroot-project/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/src'
make[3]: *** [install-recursive] Error 1
make[3]: Leaving directory
`/home/alukiche/Projects/buildroot/buildroot-project/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3'
make[2]: *** [install-target-libstdc++-v3] Error 2
make[2]: Leaving directory
`/home/alukiche/Projects/buildroot/buildroot-project/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build'
make[1]: *** [install] Error 2
make[1]: Leaving directory
`/home/alukiche/Projects/buildroot/buildroot-project/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build'
make: ***
[/home/alukiche/Projects/buildroot/buildroot-project/output/build/host-gcc-final-4.2.2-avr32-2.1.5/.stamp_host_installed]
Error 2


  With the patch applied, it makes a successful build. Am I doing something
wrong here? Maybe something in my environment? My HEAD is at
79309d94423738e6832f08cafab0cd71f65af355 .



--
Best regards,
  Alexander Lukichev


2013/8/5 Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com>

> On Mon, Aug 5, 2013 at 2:01 PM, Thomas De Schampheleire
> <patrickdepinguin+buildroot@gmail.com> wrote:
> > Hi,
> >
> > I was looking at an autobuild failure on AVR32 and tried reproducing
> > it locally. Unfortunately, the AVR32 toolchain that was configured was
> > pre-built on a 64-bit machine, which I don't have. Hence, the
> > configured toolchain was not usable.
> >
> > Then I tried building my own AVR32 toolchain with the internal
> > backend, see config attached. Unfortunately, this failed as well:
> >
> >
>  /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/./gcc/xgcc
> > -shared-libgcc
> -B/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/./gcc
> > -nostdinc++
> -L/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/src
> >
> -L/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/src/.libs
> >
> -B/home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/avr32-buildroot-linux-uclibc/bin/
> >
> -B/home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/avr32-buildroot-linux-uclibc/lib/
> > -isystem
> /home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/avr32-buildroot-linux-uclibc/include
> > -isystem
> /home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/avr32-buildroot-linux-uclibc/sys-include
> > -shared -nostdlib
> >
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/./gcc/crti.o
> >
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/./gcc/crtbeginS.o
> >  .libs/bitmap_allocator.o .libs/pool_allocator.o .libs/mt_allocator.o
> > .libs/codecvt.o .libs/compatibility.o .libs/complex_io.o .libs/ctype.o
> > .libs/debug.o .libs/debug_list.o .libs/functexcept.o
> > .libs/globals_io.o .libs/ios.o .libs/ios_failure.o .libs/ios_init.o
> > .libs/ios_locale.o .libs/limits.o .libs/list.o .libs/locale.o
> > .libs/locale_init.o .libs/locale_facets.o .libs/localename.o
> > .libs/stdexcept.o .libs/strstream.o .libs/tree.o
> > .libs/allocator-inst.o .libs/concept-inst.o .libs/fstream-inst.o
> > .libs/ext-inst.o .libs/ios-inst.o .libs/iostream-inst.o
> > .libs/istream-inst.o .libs/istream.o .libs/locale-inst.o
> > .libs/misc-inst.o .libs/ostream-inst.o .libs/sstream-inst.o
> > .libs/streambuf-inst.o .libs/streambuf.o .libs/string-inst.o
> > .libs/valarray-inst.o .libs/wlocale-inst.o .libs/wstring-inst.o
> > .libs/atomicity.o .libs/codecvt_members.o .libs/collate_members.o
> > .libs/ctype_members.o .libs/messages_members.o
> > .libs/monetary_members.o .libs/numeric_members.o .libs/time_members.o
> > .libs/basic_file.o .libs/c++locale.o -Wl,--whole-archive
> > ../libmath/.libs/libmath.a ../libsupc++/.libs/libsupc++convenience.a
> > -Wl,--no-whole-archive
> >
> -L/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/src
> >
> -L/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/src/.libs
> > -lm ../libmath/.libs/libmath.a -lm
> > ../libsupc++/.libs/libsupc++convenience.a -lm
> >
> -L/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/./gcc
> >
> -L/home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/avr32-buildroot-linux-uclibc/bin
> >
> -L/home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/avr32-buildroot-linux-uclibc/lib
> >
> -L/home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/lib/gcc/avr32-buildroot-linux-uclibc/4.2.2
> >
> -L/home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/lib/gcc/avr32-buildroot-linux-uclibc/4.2.2/../../../../avr32-buildroot-linux-uclibc/lib
> >
> -L/home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/avr32-buildroot-linux-uclibc/sysroot/lib
> >
> -L/home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/avr32-buildroot-linux-uclibc/sysroot/usr/lib
> > -lgcc -lc -lgcc -lm -lgcc -lc -lgcc
> >
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/./gcc/crtendS.o
> >
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/./gcc/crtn.o
> >  -Wl,-O1 -Wl,--gc-sections -Wl,-soname -Wl,libstdc++.so.6 -o
> > .libs/libstdc++.so.6.0.9
> > .libs/bitmap_allocator.o: In function `.LLSDA217':
> >
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/include/ext/bitmap_allocator.h:400:
> > relocation truncated to fit: R_AVR32_32_PCREL against symbol
> > `DW.ref._ZTISt9bad_alloc' defined in
> > .data.DW.ref._ZTISt9bad_alloc[DW.ref._ZTISt9bad_alloc] section in
> > .libs/bitmap_allocator.o
> > .libs/bitmap_allocator.o: In function `.LLSDA294':
> >
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/include/ext/bitmap_allocator.h:400:
> > relocation truncated to fit: R_AVR32_32_PCREL against symbol
> > `DW.ref._ZTISt9bad_alloc' defined in
> > .data.DW.ref._ZTISt9bad_alloc[DW.ref._ZTISt9bad_alloc] section in
> > .libs/bitmap_allocator.o
> > .libs/bitmap_allocator.o: In function `.LLSDA295':
> >
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/include/ext/bitmap_allocator.h:400:
> > relocation truncated to fit: R_AVR32_32_PCREL against symbol
> > `DW.ref._ZTISt9bad_alloc' defined in
> > .data.DW.ref._ZTISt9bad_alloc[DW.ref._ZTISt9bad_alloc] section in
> > .libs/bitmap_allocator.o
> > .libs/bitmap_allocator.o: In function `.LLSDA268':
> >
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/include/ext/bitmap_allocator.h:400:
> > relocation truncated to fit: R_AVR32_32_PCREL against symbol
> > `DW.ref._ZTISt9bad_alloc' defined in
> > .data.DW.ref._ZTISt9bad_alloc[DW.ref._ZTISt9bad_alloc] section in
> > .libs/bitmap_allocator.o
> > .libs/bitmap_allocator.o: In function `.LLSDA269':
> >
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/include/ext/bitmap_allocator.h:400:
> > relocation truncated to fit: R_AVR32_32_PCREL against symbol
> > `DW.ref._ZTISt9bad_alloc' defined in
> > .data.DW.ref._ZTISt9bad_alloc[DW.ref._ZTISt9bad_alloc] section in
> > .libs/bitmap_allocator.o
> > ../libsupc++/.libs/libsupc++convenience.a(new_op.o): In function
> `.LLSDA20':
> >
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/libsupc++/../../../../libstdc++-v3/libsupc++/new_op.cc:50:
> > relocation truncated to fit: R_AVR32_32_PCREL against symbol
> > `DW.ref._ZTISt9bad_alloc' defined in
> > .data.DW.ref._ZTISt9bad_alloc[DW.ref._ZTISt9bad_alloc] section in
> > .libs/bitmap_allocator.o
> > ../libsupc++/.libs/libsupc++convenience.a(new_opnt.o): In function
> `.LLSDA15':
> >
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/libsupc++/../../../../libstdc++-v3/libsupc++/new_opnt.cc:41:
> > relocation truncated to fit: R_AVR32_32_PCREL against symbol
> > `DW.ref._ZTISt9bad_alloc' defined in
> > .data.DW.ref._ZTISt9bad_alloc[DW.ref._ZTISt9bad_alloc] section in
> > .libs/bitmap_allocator.o
> > ../libsupc++/.libs/libsupc++convenience.a(new_opv.o): In function
> `.LLSDA15':
> >
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/libsupc++/../../../../libstdc++-v3/libsupc++/new_opv.cc:35:
> > relocation truncated to fit: R_AVR32_32_PCREL against symbol
> > `DW.ref._ZTISt9bad_alloc' defined in
> > .data.DW.ref._ZTISt9bad_alloc[DW.ref._ZTISt9bad_alloc] section in
> > .libs/bitmap_allocator.o
> > ../libsupc++/.libs/libsupc++convenience.a(vterminate.o): In function
> `.LLSDA59':
> >
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/libsupc++/../../../../libstdc++-v3/libsupc++/vterminate.cc:65:
> > relocation truncated to fit: R_AVR32_32_PCREL against symbol
> > `DW.ref._ZTISt9exception' defined in
> > .data.DW.ref._ZTISt9exception[DW.ref._ZTISt9exception] section in
> > ../libsupc++/.libs/libsupc++convenience.a(vterminate.o)
> > collect2: ld returned 1 exit status
> > make[5]: *** [libstdc++.la] Error 1
> > make[5]: Leaving directory
> >
> `/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/src'
> > make[4]: *** [all-recursive] Error 1
> > make[4]: Leaving directory
> >
> `/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3'
> > make[3]: *** [all] Error 2
> > make[3]: Leaving directory
> >
> `/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3'
> > make[2]: *** [all-target-libstdc++-v3] Error 2
> > make[2]: Leaving directory
> >
> `/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build'
> > make[1]: *** [all] Error 2
> > make[1]: Leaving directory
> >
> `/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build'
> > make: ***
> [/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/.stamp_built]
> > Error 2
> >
> >
> >
> > Anyone seen this before?
> >
> >
> > Thomas Petazzoni: could you send the toolchain configuration you used
> > to create the AVR32 toolchain used for the autobuilders, like this
> > one:
> http://autobuild.buildroot.net/results/645b357d470b75baa9a93eb5be4f1dc5c8c337fa/
>
>
> Obviously, I forgot the attachments. Shame on me...
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130808/d6434fd5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 990-fix-300-libstdc++-pic.patch
Type: application/octet-stream
Size: 1011 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130808/d6434fd5/attachment-0001.obj>

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-08  8:03                   ` Thomas Petazzoni
@ 2013-08-08 10:56                     ` Gustavo Zacarias
  2013-08-08 16:18                       ` Simon Dawson
  0 siblings, 1 reply; 42+ messages in thread
From: Gustavo Zacarias @ 2013-08-08 10:56 UTC (permalink / raw)
  To: buildroot

On 08/08/2013 05:03 AM, Thomas Petazzoni wrote:

> Dear Simon Dawson,
> 
> On Thu, 8 Aug 2013 08:21:14 +0100, Simon Dawson wrote:
> 
>> From my point of view, the ideal solution would be to reinstate uClibc
>> 0.9.31 support, and to lock the avr32 toolchain to that version of
>> uClibc. But I understand that this is likely to be unacceptable to
>> others.
> 
> Gustavo, you're the one who removed uClibc 0.9.31. What would it take
> to reinstate it? Have we made some significant simplifications/cleanups
> that would be complicated to rework to bring back 0.9.31 support for
> AVR32 ?

Hi.
1) Reinstate patches in the appropiate place since uclibc was packaged.
2) Probably add various "depends on !BR2_avr32" in packages that need
newer syscalls (alternatively add a ton of backports for uclibc 0.9.31
from newer releases).
3) Revert startfiles cleanup to the old manual way, adding new
exceptions/modes for the noMMU crowd (it wasn't handled before) - or
alternatively also patch the uclibc 0.9.31 makefile to make it more
0.9.32/33-ish like.

That said, i can't get anywhere with the AVR32 toolchain, it's failing
very early on:

-----
/home/gustavoz/b/avr32/output/build/host-gcc-initial-4.2.2-avr32-2.1.5/build/./gcc/xgcc
-B/home/gustavoz/b/avr32/output/build/host-gcc-initial-4.2.2-avr32-2.1.5/build/./gcc/
-B/home/gustavoz/b/avr32/output/host/usr/avr32-buildroot-linux-uclibc/bin/
-B/home/gustavoz/b/avr32/output/host/usr/avr32-buildroot-linux-uclibc/lib/
-isystem
/home/gustavoz/b/avr32/output/host/usr/avr32-buildroot-linux-uclibc/include
-isystem
/home/gustavoz/b/avr32/output/host/usr/avr32-buildroot-linux-uclibc/sys-include
-O2 -g -Os -DIN_GCC -DCROSS_COMPILE   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-isystem ./include  -I. -I. -I../../gcc -I../../gcc/.
-I../../gcc/../include -I../../gcc/../libcpp/include
-I/home/gustavoz/b/avr32/output/host/usr/include
-I/home/gustavoz/b/avr32/output/host/usr/include
-I../../gcc/../libdecnumber -I../libdecnumber  -g0
-finhibit-size-directive -fno-inline-functions -fno-exceptions
-fno-zero-initialized-in-bss -fno-toplevel-reorder -Dinhibit_libc -mrelax \
  -c ../../gcc/crtstuff.c -DCRT_END \
  -o crtend.o
/tmp/ccN15d7y.s: Assembler messages:
/tmp/ccN15d7y.s:12: Error: invalid register list `,lr'
/tmp/ccN15d7y.s:22: Error: invalid register list `,pc'
/tmp/ccN15d7y.s:36: Error: invalid register list `,pc'
/tmp/ccN15d7y.s:54: Error: invalid register list `,lr'
/tmp/ccN15d7y.s:68: Error: invalid register list `,pc'
make[2]: *** [crtbegin.o] Error 1
make[2]: *** Waiting for unfinished jobs....
/tmp/ccMp5aAy.s: Assembler messages:
/tmp/ccMp5aAy.s:12: Error: invalid register list `,lr'
/tmp/ccZ5kyzy.s: /tmp/ccMp5aAy.s:43: Assembler messages:
Error: invalid register list `,pc'
/tmp/ccZ5kyzy.s:10: /tmp/ccMp5aAy.s:61: Error: Error: invalid register
list `,lr'
invalid register list `,lr'/tmp/ccMp5aAy.s:75: Error: invalid register
list `,pc'

/tmp/ccZ5kyzy.s:25: Error: invalid register list `,pc'
-----

Which is documented (?!?!) upstream at
http://www.atmel.no/buildroot/buildroot-issues.html
So it seems any "modern" host gcc (4.6.x-ish here) will fail and the
solution is "use some old stuff".

There are patches for newer binutils and gcc in openwrt svn (for 2.20.1
and 4.4.7 respectively). I've tried in the past with them and hit some
issues too, though i don't remember OTOH what they were.
Also, these are pretty big patches, binutils being about 900 KiB and gcc
about 750 KiB, they wouldn't be pretty to carry around.

In my opinion, sorry if it hurts someone, we're going in circles trying
to keep up with a dead architecture, because that's what it is, no
matter how much support some people/companies want to give for their
products the onus shouldn't be on us that things weren't upstreamed in a
proper fashion which would make things far more simple.

Regards.

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-08  7:29                 ` Alexander Lukichev
@ 2013-08-08  8:13                   ` Thomas De Schampheleire
  0 siblings, 0 replies; 42+ messages in thread
From: Thomas De Schampheleire @ 2013-08-08  8:13 UTC (permalink / raw)
  To: buildroot

Hi Alexander,

On Thu, Aug 8, 2013 at 9:29 AM, Alexander Lukichev
<alexander.lukichev@gmail.com> wrote:
> Hello Thomas, all,
>
> 2013/8/8 Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com>
>>
>> Hi Simon, Alexander,
>>
>>
>> Current buildroot cannot properly build an AVR32 toolchain with C++
>> support. This problem seems to be present for a while now. Are any of
>> you interested in such C++ support, and do you have time to look into
>> this?
>>
>> If no-one is really interested (or does not have time), here are two
>> suggestions:
>> - we disable the C++ toolchain option for AVR32 and put a comment in
>> kconfig
>> - we leave the C++ toolchain option but put a comment in kconfig
>
>
> I am looking into the problem now and hope that it can be solved. I am OK
> with either option until then. Thanks.

Thanks a lot, it would be great if this can be solved.
Maybe we can learn something from the custom buildroot fork Simon mentioned.

Best regards,
Thomas

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-08  7:21                 ` Simon Dawson
  2013-08-08  8:03                   ` Thomas Petazzoni
@ 2013-08-08  8:12                   ` Thomas De Schampheleire
  2013-08-08 16:09                     ` Simon Dawson
  1 sibling, 1 reply; 42+ messages in thread
From: Thomas De Schampheleire @ 2013-08-08  8:12 UTC (permalink / raw)
  To: buildroot

Hi Simon,

Thanks for your input.

On Thu, Aug 8, 2013 at 9:21 AM, Simon Dawson <spdawson@gmail.com> wrote:
> Hi Thomas,
>
> On 8 August 2013 06:55, Thomas De Schampheleire
> <patrickdepinguin+buildroot@gmail.com> wrote:
>> Current buildroot cannot properly build an AVR32 toolchain with C++
>> support. This problem seems to be present for a while now. Are any of
>> you interested in such C++ support, and do you have time to look into
>> this?
>
> I do currently still require C++ support on avr32. However, since
> support for uClibc 0.9.31.x was removed from Buildroot, I have had to
> build my avr32 toolchain using a custom Buildroot fork: unfortunately,
> while uClibc 0.9.33.x does build for avr32, the result is a root
> filesystem with unusably-slow runtime performance.

So you are able to build a toolchain with C++ support for avr32, using
(a custom) buildroot? Is this a public buildroot fork that we can look
at? If not: do you know (or could you look up) which changes have been
made to make C++ support work?

Best regards,
Thomas

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-08  7:21                 ` Simon Dawson
@ 2013-08-08  8:03                   ` Thomas Petazzoni
  2013-08-08 10:56                     ` Gustavo Zacarias
  2013-08-08  8:12                   ` Thomas De Schampheleire
  1 sibling, 1 reply; 42+ messages in thread
From: Thomas Petazzoni @ 2013-08-08  8:03 UTC (permalink / raw)
  To: buildroot

Dear Simon Dawson,

On Thu, 8 Aug 2013 08:21:14 +0100, Simon Dawson wrote:

> From my point of view, the ideal solution would be to reinstate uClibc
> 0.9.31 support, and to lock the avr32 toolchain to that version of
> uClibc. But I understand that this is likely to be unacceptable to
> others.

Gustavo, you're the one who removed uClibc 0.9.31. What would it take
to reinstate it? Have we made some significant simplifications/cleanups
that would be complicated to rework to bring back 0.9.31 support for
AVR32 ?

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-08  5:55               ` Thomas De Schampheleire
  2013-08-08  7:21                 ` Simon Dawson
@ 2013-08-08  7:29                 ` Alexander Lukichev
  2013-08-08  8:13                   ` Thomas De Schampheleire
  1 sibling, 1 reply; 42+ messages in thread
From: Alexander Lukichev @ 2013-08-08  7:29 UTC (permalink / raw)
  To: buildroot

Hello Thomas, all,

2013/8/8 Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com>

> Hi Simon, Alexander,
>
> Current buildroot cannot properly build an AVR32 toolchain with C++
> support. This problem seems to be present for a while now. Are any of
> you interested in such C++ support, and do you have time to look into
> this?
>
> If no-one is really interested (or does not have time), here are two
> suggestions:
> - we disable the C++ toolchain option for AVR32 and put a comment in
> kconfig
> - we leave the C++ toolchain option but put a comment in kconfig
>

I am looking into the problem now and hope that it can be solved. I am OK
with either option until then. Thanks.

--
Best regards,
  Alexander Lukichev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130808/34715102/attachment.html>

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-08  5:55               ` Thomas De Schampheleire
@ 2013-08-08  7:21                 ` Simon Dawson
  2013-08-08  8:03                   ` Thomas Petazzoni
  2013-08-08  8:12                   ` Thomas De Schampheleire
  2013-08-08  7:29                 ` Alexander Lukichev
  1 sibling, 2 replies; 42+ messages in thread
From: Simon Dawson @ 2013-08-08  7:21 UTC (permalink / raw)
  To: buildroot

Hi Thomas,

On 8 August 2013 06:55, Thomas De Schampheleire
<patrickdepinguin+buildroot@gmail.com> wrote:
> Current buildroot cannot properly build an AVR32 toolchain with C++
> support. This problem seems to be present for a while now. Are any of
> you interested in such C++ support, and do you have time to look into
> this?

I do currently still require C++ support on avr32. However, since
support for uClibc 0.9.31.x was removed from Buildroot, I have had to
build my avr32 toolchain using a custom Buildroot fork: unfortunately,
while uClibc 0.9.33.x does build for avr32, the result is a root
filesystem with unusably-slow runtime performance.

So I'm not particularly interested in getting the avr32 toolchain ---
as it currently exists in Buildroot --- to build with C++ support. But
I do need the "Toolchain has C++ support" flag to be available when
using an external avr32 toolchain.

> If no-one is really interested (or does not have time), here are two
> suggestions:
> - we disable the C++ toolchain option for AVR32 and put a comment in kconfig
> - we leave the C++ toolchain option but put a comment in kconfig

I'm happy with either of these options, as long as it is still
possible to mark an external avr32 toolchain as having C++ support.

From my point of view, the ideal solution would be to reinstate uClibc
0.9.31 support, and to lock the avr32 toolchain to that version of
uClibc. But I understand that this is likely to be unacceptable to
others.

Simon.

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-07 22:07             ` Thomas Petazzoni
@ 2013-08-08  5:55               ` Thomas De Schampheleire
  2013-08-08  7:21                 ` Simon Dawson
  2013-08-08  7:29                 ` Alexander Lukichev
  0 siblings, 2 replies; 42+ messages in thread
From: Thomas De Schampheleire @ 2013-08-08  5:55 UTC (permalink / raw)
  To: buildroot

Hi Simon, Alexander,

>
> On Wed, 7 Aug 2013 20:20:31 +0200, Thomas De Schampheleire wrote:
>> On Wed, Aug 7, 2013 at 6:01 PM, Thomas De Schampheleire
>> <patrickdepinguin+buildroot@gmail.com> wrote:
>> >
>> > On Wed, Aug 7, 2013 at 5:20 PM, Thomas Petazzoni
>> > <thomas.petazzoni@free-electrons.com> wrote:
>> >>
>> >> Can you try to see if the same configuration was building in the
>> >> 2013.05, to see if the problem is a consequence of the new internal
>> >> toolchain backend or not?
>> >
>> > I will, and let you know the results.
>>
>> This also failed in 2013.05, and 2013.02. I can continue down the
>> line, but it seems that not many people need C++ support on AVR32? I
>> can
>
> I do remember that some combinations like C++ + locale support has
> always been failing on AVR32.
>
> I personally don't care much about AVR32. I think Simon Dawson was the
> one mainly interested in keeping the AVR32 support in Buildroot for now.
>

Current buildroot cannot properly build an AVR32 toolchain with C++
support. This problem seems to be present for a while now. Are any of
you interested in such C++ support, and do you have time to look into
this?

If no-one is really interested (or does not have time), here are two
suggestions:
- we disable the C++ toolchain option for AVR32 and put a comment in kconfig
- we leave the C++ toolchain option but put a comment in kconfig

Thanks,
Thomas

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-07 18:20           ` Thomas De Schampheleire
@ 2013-08-07 22:07             ` Thomas Petazzoni
  2013-08-08  5:55               ` Thomas De Schampheleire
  0 siblings, 1 reply; 42+ messages in thread
From: Thomas Petazzoni @ 2013-08-07 22:07 UTC (permalink / raw)
  To: buildroot

Dear Thomas De Schampheleire,

On Wed, 7 Aug 2013 20:20:31 +0200, Thomas De Schampheleire wrote:
> On Wed, Aug 7, 2013 at 6:01 PM, Thomas De Schampheleire
> <patrickdepinguin+buildroot@gmail.com> wrote:
> >
> > On Wed, Aug 7, 2013 at 5:20 PM, Thomas Petazzoni
> > <thomas.petazzoni@free-electrons.com> wrote:
> >>
> >> Can you try to see if the same configuration was building in the
> >> 2013.05, to see if the problem is a consequence of the new internal
> >> toolchain backend or not?
> >
> > I will, and let you know the results.
> 
> This also failed in 2013.05, and 2013.02. I can continue down the
> line, but it seems that not many people need C++ support on AVR32? I
> can

I do remember that some combinations like C++ + locale support has
always been failing on AVR32.

I personally don't care much about AVR32. I think Simon Dawson was the
one mainly interested in keeping the AVR32 support in Buildroot for now.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-07 16:01         ` Thomas De Schampheleire
@ 2013-08-07 18:20           ` Thomas De Schampheleire
  2013-08-07 22:07             ` Thomas Petazzoni
  0 siblings, 1 reply; 42+ messages in thread
From: Thomas De Schampheleire @ 2013-08-07 18:20 UTC (permalink / raw)
  To: buildroot

On Wed, Aug 7, 2013 at 6:01 PM, Thomas De Schampheleire
<patrickdepinguin+buildroot@gmail.com> wrote:
>
> On Wed, Aug 7, 2013 at 5:20 PM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>>
>> Can you try to see if the same configuration was building in the
>> 2013.05, to see if the problem is a consequence of the new internal
>> toolchain backend or not?
>
> I will, and let you know the results.

This also failed in 2013.05, and 2013.02. I can continue down the
line, but it seems that not many people need C++ support on AVR32? I
can

>
> Best regards,
> Thomas

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-07 15:20       ` Thomas Petazzoni
@ 2013-08-07 16:01         ` Thomas De Schampheleire
  2013-08-07 18:20           ` Thomas De Schampheleire
  0 siblings, 1 reply; 42+ messages in thread
From: Thomas De Schampheleire @ 2013-08-07 16:01 UTC (permalink / raw)
  To: buildroot

Hi Thomas,

On Wed, Aug 7, 2013 at 5:20 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Thomas De Schampheleire,
>
> On Wed, 7 Aug 2013 09:05:30 +0200, Thomas De Schampheleire wrote:
>
>> I can now confirm that the atngw100_defconfig works unchanged, but
>
> Does the 3.10 kernel builds for you? It fails to build for me with some
> truncated relocation messages. I.e, as is, the atngw100_defconfig
> doesn't build here.

What I meant was the toolchain part. I also had the kernel problems.

>
>> when I enable C++ support in the toolchain, host-gcc-final fails with
>> the aforementioned error about truncated relocations.
>>
>> I'm not sure how to proceed from here...
>
> Can you try to see if the same configuration was building in the
> 2013.05, to see if the problem is a consequence of the new internal
> toolchain backend or not?

I will, and let you know the results.

Best regards,
Thomas

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-07  7:05     ` Thomas De Schampheleire
@ 2013-08-07 15:20       ` Thomas Petazzoni
  2013-08-07 16:01         ` Thomas De Schampheleire
  0 siblings, 1 reply; 42+ messages in thread
From: Thomas Petazzoni @ 2013-08-07 15:20 UTC (permalink / raw)
  To: buildroot

Dear Thomas De Schampheleire,

On Wed, 7 Aug 2013 09:05:30 +0200, Thomas De Schampheleire wrote:

> I can now confirm that the atngw100_defconfig works unchanged, but

Does the 3.10 kernel builds for you? It fails to build for me with some
truncated relocation messages. I.e, as is, the atngw100_defconfig
doesn't build here.

> when I enable C++ support in the toolchain, host-gcc-final fails with
> the aforementioned error about truncated relocations.
> 
> I'm not sure how to proceed from here...

Can you try to see if the same configuration was building in the
2013.05, to see if the problem is a consequence of the new internal
toolchain backend or not?

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-06 19:33   ` Thomas De Schampheleire
@ 2013-08-07  7:05     ` Thomas De Schampheleire
  2013-08-07 15:20       ` Thomas Petazzoni
  0 siblings, 1 reply; 42+ messages in thread
From: Thomas De Schampheleire @ 2013-08-07  7:05 UTC (permalink / raw)
  To: buildroot

Hi,

On Tue, Aug 6, 2013 at 9:33 PM, Thomas De Schampheleire
<patrickdepinguin+buildroot@gmail.com> wrote:
> Hi Thomas,
>
> On Tue, Aug 6, 2013 at 7:54 PM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>> Dear Thomas De Schampheleire,
>>
>> On Mon, 5 Aug 2013 14:01:51 +0200, Thomas De Schampheleire wrote:
>>
>>> I was looking at an autobuild failure on AVR32 and tried reproducing
>>> it locally. Unfortunately, the AVR32 toolchain that was configured was
>>> pre-built on a 64-bit machine, which I don't have. Hence, the
>>> configured toolchain was not usable.
>>>
>>> Then I tried building my own AVR32 toolchain with the internal
>>> backend, see config attached. Unfortunately, this failed as well:
>>
>> I just tested here on my Ubuntu 13.04 64 bits machine, with the latest
>> Buildroot Git, and the atngw100_defconfig (AVR32) could build a
>> toolchain properly. This toolchain however seems to have a problem as
>> it is not able to link the kernel. This specific regression was, I
>> think, introduced by my patches converting the internal backend to
>> proper packages. I'll try to investigate this one.
>
> I verified the atngw100_defconfig, and the toolchain also builds fine here.
> Comparing the configuration with my failing setup, I see that I had
> enabled C++ support, wchar, largefile and ipv6. Presumably, it's the
> C++ support that is the problem.
>
> I'll verify by enabling just that without wchar, largefile and ipv6.

I can now confirm that the atngw100_defconfig works unchanged, but
when I enable C++ support in the toolchain, host-gcc-final fails with
the aforementioned error about truncated relocations.

I'm not sure how to proceed from here...

Best regards,
Thomas

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-06 17:54 ` Thomas Petazzoni
@ 2013-08-06 19:33   ` Thomas De Schampheleire
  2013-08-07  7:05     ` Thomas De Schampheleire
  0 siblings, 1 reply; 42+ messages in thread
From: Thomas De Schampheleire @ 2013-08-06 19:33 UTC (permalink / raw)
  To: buildroot

Hi Thomas,

On Tue, Aug 6, 2013 at 7:54 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Thomas De Schampheleire,
>
> On Mon, 5 Aug 2013 14:01:51 +0200, Thomas De Schampheleire wrote:
>
>> I was looking at an autobuild failure on AVR32 and tried reproducing
>> it locally. Unfortunately, the AVR32 toolchain that was configured was
>> pre-built on a 64-bit machine, which I don't have. Hence, the
>> configured toolchain was not usable.
>>
>> Then I tried building my own AVR32 toolchain with the internal
>> backend, see config attached. Unfortunately, this failed as well:
>
> I just tested here on my Ubuntu 13.04 64 bits machine, with the latest
> Buildroot Git, and the atngw100_defconfig (AVR32) could build a
> toolchain properly. This toolchain however seems to have a problem as
> it is not able to link the kernel. This specific regression was, I
> think, introduced by my patches converting the internal backend to
> proper packages. I'll try to investigate this one.

I verified the atngw100_defconfig, and the toolchain also builds fine here.
Comparing the configuration with my failing setup, I see that I had
enabled C++ support, wchar, largefile and ipv6. Presumably, it's the
C++ support that is the problem.

I'll verify by enabling just that without wchar, largefile and ipv6.

FYI: I also see a linking problem on the kernel:
lib/lib.a(vsprintf.o): In function `pointer':
vsprintf.c:(.text+0x17e0): relocation truncated to fit:
R_AVR32_16N_PCREL against symbol `_ctype' defined in .text section in
lib/lib.a(ctype.o)
make[1]: *** [vmlinux] Error 1

Best regards,
Thomas

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-05 12:01 Thomas De Schampheleire
  2013-08-05 12:29 ` Thomas De Schampheleire
@ 2013-08-06 17:54 ` Thomas Petazzoni
  2013-08-06 19:33   ` Thomas De Schampheleire
  1 sibling, 1 reply; 42+ messages in thread
From: Thomas Petazzoni @ 2013-08-06 17:54 UTC (permalink / raw)
  To: buildroot

Dear Thomas De Schampheleire,

On Mon, 5 Aug 2013 14:01:51 +0200, Thomas De Schampheleire wrote:

> I was looking at an autobuild failure on AVR32 and tried reproducing
> it locally. Unfortunately, the AVR32 toolchain that was configured was
> pre-built on a 64-bit machine, which I don't have. Hence, the
> configured toolchain was not usable.
> 
> Then I tried building my own AVR32 toolchain with the internal
> backend, see config attached. Unfortunately, this failed as well:

I just tested here on my Ubuntu 13.04 64 bits machine, with the latest
Buildroot Git, and the atngw100_defconfig (AVR32) could build a
toolchain properly. This toolchain however seems to have a problem as
it is not able to link the kernel. This specific regression was, I
think, introduced by my patches converting the internal backend to
proper packages. I'll try to investigate this one.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-06 14:40     ` Thomas De Schampheleire
@ 2013-08-06 15:03       ` Thomas De Schampheleire
  0 siblings, 0 replies; 42+ messages in thread
From: Thomas De Schampheleire @ 2013-08-06 15:03 UTC (permalink / raw)
  To: buildroot

On Tue, Aug 6, 2013 at 4:40 PM, Thomas De Schampheleire
<patrickdepinguin+buildroot@gmail.com> wrote:
> Hi Alexander,
>
> On Tue, Aug 6, 2013 at 11:27 AM, Alexander Lukichev
> <alexander.lukichev@gmail.com> wrote:
>> Hello, Thomas!
>>
>> I had the same problem but was too busy at the time to articulate it here or
>> to Thomas (Petazzoni), instead asking him if I could somehow use autobuilder
>> to test out fixes :) Thanks for posting. I do not know what is the problem
>> but I have it also.
>
> Thanks for letting me know.
>
> I found some info regarding this error here:
> http://stackoverflow.com/questions/8188849/avr-linker-error-relocation-truncated-to-fit
>
> after which I tried adding -mno-short-calls to the failing xgcc call.
> This did not change a thing however.
>
> I'm wondering if it's at all possible to compile libstdc++ for avr32.
> Following project seems to suggest it is:
> https://github.com/jsnyder/avr32-toolchain/blob/master/Makefile
> I looked through some of the options, but did not notice anything out
> of the ordinary. One thing I did see is that for the avr32-toolchain
> project, -Os is used. Could this fix the relocation truncation?

Scratch that: there is an autobuild toolchain for AVR32, so it's
obviously possible to make one.
There must be some other difference.

Best regards,
Thomas

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-06  9:27   ` Alexander Lukichev
  2013-08-06  9:39     ` Alexander Lukichev
@ 2013-08-06 14:40     ` Thomas De Schampheleire
  2013-08-06 15:03       ` Thomas De Schampheleire
  1 sibling, 1 reply; 42+ messages in thread
From: Thomas De Schampheleire @ 2013-08-06 14:40 UTC (permalink / raw)
  To: buildroot

Hi Alexander,

On Tue, Aug 6, 2013 at 11:27 AM, Alexander Lukichev
<alexander.lukichev@gmail.com> wrote:
> Hello, Thomas!
>
> I had the same problem but was too busy at the time to articulate it here or
> to Thomas (Petazzoni), instead asking him if I could somehow use autobuilder
> to test out fixes :) Thanks for posting. I do not know what is the problem
> but I have it also.

Thanks for letting me know.

I found some info regarding this error here:
http://stackoverflow.com/questions/8188849/avr-linker-error-relocation-truncated-to-fit

after which I tried adding -mno-short-calls to the failing xgcc call.
This did not change a thing however.

I'm wondering if it's at all possible to compile libstdc++ for avr32.
Following project seems to suggest it is:
https://github.com/jsnyder/avr32-toolchain/blob/master/Makefile
I looked through some of the options, but did not notice anything out
of the ordinary. One thing I did see is that for the avr32-toolchain
project, -Os is used. Could this fix the relocation truncation?

Any input is welcome...

Best regards,
Thomas

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-06  9:27   ` Alexander Lukichev
@ 2013-08-06  9:39     ` Alexander Lukichev
  2013-08-06 14:40     ` Thomas De Schampheleire
  1 sibling, 0 replies; 42+ messages in thread
From: Alexander Lukichev @ 2013-08-06  9:39 UTC (permalink / raw)
  To: buildroot

2013/8/6 Alexander Lukichev <alexander.lukichev@gmail.com>
> Hello, Thomas!
<...>


Oops, sorry for postquoting!

--
Best regards,
  Alexander Lukichev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130806/3431129c/attachment.html>

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-05 12:29 ` Thomas De Schampheleire
@ 2013-08-06  9:27   ` Alexander Lukichev
  2013-08-06  9:39     ` Alexander Lukichev
  2013-08-06 14:40     ` Thomas De Schampheleire
  2013-08-08 15:35   ` Alexander Lukichev
  1 sibling, 2 replies; 42+ messages in thread
From: Alexander Lukichev @ 2013-08-06  9:27 UTC (permalink / raw)
  To: buildroot

Hello, Thomas!

I had the same problem but was too busy at the time to articulate it here
or to Thomas (Petazzoni), instead asking him if I could somehow use
autobuilder to test out fixes :) Thanks for posting. I do not know what is
the problem but I have it also.

--
Best regards,
  Alexander Lukichev


2013/8/5 Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com>

> On Mon, Aug 5, 2013 at 2:01 PM, Thomas De Schampheleire
> <patrickdepinguin+buildroot@gmail.com> wrote:
> > Hi,
> >
> > I was looking at an autobuild failure on AVR32 and tried reproducing
> > it locally. Unfortunately, the AVR32 toolchain that was configured was
> > pre-built on a 64-bit machine, which I don't have. Hence, the
> > configured toolchain was not usable.
> >
> > Then I tried building my own AVR32 toolchain with the internal
> > backend, see config attached. Unfortunately, this failed as well:
> >
> >
>  /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/./gcc/xgcc
> > -shared-libgcc
> -B/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/./gcc
> > -nostdinc++
> -L/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/src
> >
> -L/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/src/.libs
> >
> -B/home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/avr32-buildroot-linux-uclibc/bin/
> >
> -B/home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/avr32-buildroot-linux-uclibc/lib/
> > -isystem
> /home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/avr32-buildroot-linux-uclibc/include
> > -isystem
> /home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/avr32-buildroot-linux-uclibc/sys-include
> > -shared -nostdlib
> >
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/./gcc/crti.o
> >
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/./gcc/crtbeginS.o
> >  .libs/bitmap_allocator.o .libs/pool_allocator.o .libs/mt_allocator.o
> > .libs/codecvt.o .libs/compatibility.o .libs/complex_io.o .libs/ctype.o
> > .libs/debug.o .libs/debug_list.o .libs/functexcept.o
> > .libs/globals_io.o .libs/ios.o .libs/ios_failure.o .libs/ios_init.o
> > .libs/ios_locale.o .libs/limits.o .libs/list.o .libs/locale.o
> > .libs/locale_init.o .libs/locale_facets.o .libs/localename.o
> > .libs/stdexcept.o .libs/strstream.o .libs/tree.o
> > .libs/allocator-inst.o .libs/concept-inst.o .libs/fstream-inst.o
> > .libs/ext-inst.o .libs/ios-inst.o .libs/iostream-inst.o
> > .libs/istream-inst.o .libs/istream.o .libs/locale-inst.o
> > .libs/misc-inst.o .libs/ostream-inst.o .libs/sstream-inst.o
> > .libs/streambuf-inst.o .libs/streambuf.o .libs/string-inst.o
> > .libs/valarray-inst.o .libs/wlocale-inst.o .libs/wstring-inst.o
> > .libs/atomicity.o .libs/codecvt_members.o .libs/collate_members.o
> > .libs/ctype_members.o .libs/messages_members.o
> > .libs/monetary_members.o .libs/numeric_members.o .libs/time_members.o
> > .libs/basic_file.o .libs/c++locale.o -Wl,--whole-archive
> > ../libmath/.libs/libmath.a ../libsupc++/.libs/libsupc++convenience.a
> > -Wl,--no-whole-archive
> >
> -L/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/src
> >
> -L/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/src/.libs
> > -lm ../libmath/.libs/libmath.a -lm
> > ../libsupc++/.libs/libsupc++convenience.a -lm
> >
> -L/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/./gcc
> >
> -L/home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/avr32-buildroot-linux-uclibc/bin
> >
> -L/home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/avr32-buildroot-linux-uclibc/lib
> >
> -L/home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/lib/gcc/avr32-buildroot-linux-uclibc/4.2.2
> >
> -L/home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/lib/gcc/avr32-buildroot-linux-uclibc/4.2.2/../../../../avr32-buildroot-linux-uclibc/lib
> >
> -L/home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/avr32-buildroot-linux-uclibc/sysroot/lib
> >
> -L/home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/avr32-buildroot-linux-uclibc/sysroot/usr/lib
> > -lgcc -lc -lgcc -lm -lgcc -lc -lgcc
> >
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/./gcc/crtendS.o
> >
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/./gcc/crtn.o
> >  -Wl,-O1 -Wl,--gc-sections -Wl,-soname -Wl,libstdc++.so.6 -o
> > .libs/libstdc++.so.6.0.9
> > .libs/bitmap_allocator.o: In function `.LLSDA217':
> >
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/include/ext/bitmap_allocator.h:400:
> > relocation truncated to fit: R_AVR32_32_PCREL against symbol
> > `DW.ref._ZTISt9bad_alloc' defined in
> > .data.DW.ref._ZTISt9bad_alloc[DW.ref._ZTISt9bad_alloc] section in
> > .libs/bitmap_allocator.o
> > .libs/bitmap_allocator.o: In function `.LLSDA294':
> >
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/include/ext/bitmap_allocator.h:400:
> > relocation truncated to fit: R_AVR32_32_PCREL against symbol
> > `DW.ref._ZTISt9bad_alloc' defined in
> > .data.DW.ref._ZTISt9bad_alloc[DW.ref._ZTISt9bad_alloc] section in
> > .libs/bitmap_allocator.o
> > .libs/bitmap_allocator.o: In function `.LLSDA295':
> >
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/include/ext/bitmap_allocator.h:400:
> > relocation truncated to fit: R_AVR32_32_PCREL against symbol
> > `DW.ref._ZTISt9bad_alloc' defined in
> > .data.DW.ref._ZTISt9bad_alloc[DW.ref._ZTISt9bad_alloc] section in
> > .libs/bitmap_allocator.o
> > .libs/bitmap_allocator.o: In function `.LLSDA268':
> >
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/include/ext/bitmap_allocator.h:400:
> > relocation truncated to fit: R_AVR32_32_PCREL against symbol
> > `DW.ref._ZTISt9bad_alloc' defined in
> > .data.DW.ref._ZTISt9bad_alloc[DW.ref._ZTISt9bad_alloc] section in
> > .libs/bitmap_allocator.o
> > .libs/bitmap_allocator.o: In function `.LLSDA269':
> >
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/include/ext/bitmap_allocator.h:400:
> > relocation truncated to fit: R_AVR32_32_PCREL against symbol
> > `DW.ref._ZTISt9bad_alloc' defined in
> > .data.DW.ref._ZTISt9bad_alloc[DW.ref._ZTISt9bad_alloc] section in
> > .libs/bitmap_allocator.o
> > ../libsupc++/.libs/libsupc++convenience.a(new_op.o): In function
> `.LLSDA20':
> >
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/libsupc++/../../../../libstdc++-v3/libsupc++/new_op.cc:50:
> > relocation truncated to fit: R_AVR32_32_PCREL against symbol
> > `DW.ref._ZTISt9bad_alloc' defined in
> > .data.DW.ref._ZTISt9bad_alloc[DW.ref._ZTISt9bad_alloc] section in
> > .libs/bitmap_allocator.o
> > ../libsupc++/.libs/libsupc++convenience.a(new_opnt.o): In function
> `.LLSDA15':
> >
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/libsupc++/../../../../libstdc++-v3/libsupc++/new_opnt.cc:41:
> > relocation truncated to fit: R_AVR32_32_PCREL against symbol
> > `DW.ref._ZTISt9bad_alloc' defined in
> > .data.DW.ref._ZTISt9bad_alloc[DW.ref._ZTISt9bad_alloc] section in
> > .libs/bitmap_allocator.o
> > ../libsupc++/.libs/libsupc++convenience.a(new_opv.o): In function
> `.LLSDA15':
> >
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/libsupc++/../../../../libstdc++-v3/libsupc++/new_opv.cc:35:
> > relocation truncated to fit: R_AVR32_32_PCREL against symbol
> > `DW.ref._ZTISt9bad_alloc' defined in
> > .data.DW.ref._ZTISt9bad_alloc[DW.ref._ZTISt9bad_alloc] section in
> > .libs/bitmap_allocator.o
> > ../libsupc++/.libs/libsupc++convenience.a(vterminate.o): In function
> `.LLSDA59':
> >
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/libsupc++/../../../../libstdc++-v3/libsupc++/vterminate.cc:65:
> > relocation truncated to fit: R_AVR32_32_PCREL against symbol
> > `DW.ref._ZTISt9exception' defined in
> > .data.DW.ref._ZTISt9exception[DW.ref._ZTISt9exception] section in
> > ../libsupc++/.libs/libsupc++convenience.a(vterminate.o)
> > collect2: ld returned 1 exit status
> > make[5]: *** [libstdc++.la] Error 1
> > make[5]: Leaving directory
> >
> `/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/src'
> > make[4]: *** [all-recursive] Error 1
> > make[4]: Leaving directory
> >
> `/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3'
> > make[3]: *** [all] Error 2
> > make[3]: Leaving directory
> >
> `/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3'
> > make[2]: *** [all-target-libstdc++-v3] Error 2
> > make[2]: Leaving directory
> >
> `/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build'
> > make[1]: *** [all] Error 2
> > make[1]: Leaving directory
> >
> `/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build'
> > make: ***
> [/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/.stamp_built]
> > Error 2
> >
> >
> >
> > Anyone seen this before?
> >
> >
> > Thomas Petazzoni: could you send the toolchain configuration you used
> > to create the AVR32 toolchain used for the autobuilders, like this
> > one:
> http://autobuild.buildroot.net/results/645b357d470b75baa9a93eb5be4f1dc5c8c337fa/
>
>
> Obviously, I forgot the attachments. Shame on me...
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130806/57bbd623/attachment-0001.html>

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
  2013-08-05 12:01 Thomas De Schampheleire
@ 2013-08-05 12:29 ` Thomas De Schampheleire
  2013-08-06  9:27   ` Alexander Lukichev
  2013-08-08 15:35   ` Alexander Lukichev
  2013-08-06 17:54 ` Thomas Petazzoni
  1 sibling, 2 replies; 42+ messages in thread
From: Thomas De Schampheleire @ 2013-08-05 12:29 UTC (permalink / raw)
  To: buildroot

On Mon, Aug 5, 2013 at 2:01 PM, Thomas De Schampheleire
<patrickdepinguin+buildroot@gmail.com> wrote:
> Hi,
>
> I was looking at an autobuild failure on AVR32 and tried reproducing
> it locally. Unfortunately, the AVR32 toolchain that was configured was
> pre-built on a 64-bit machine, which I don't have. Hence, the
> configured toolchain was not usable.
>
> Then I tried building my own AVR32 toolchain with the internal
> backend, see config attached. Unfortunately, this failed as well:
>
>  /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/./gcc/xgcc
> -shared-libgcc -B/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/./gcc
> -nostdinc++ -L/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/src
> -L/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/src/.libs
> -B/home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/avr32-buildroot-linux-uclibc/bin/
> -B/home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/avr32-buildroot-linux-uclibc/lib/
> -isystem /home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/avr32-buildroot-linux-uclibc/include
> -isystem /home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/avr32-buildroot-linux-uclibc/sys-include
> -shared -nostdlib
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/./gcc/crti.o
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/./gcc/crtbeginS.o
>  .libs/bitmap_allocator.o .libs/pool_allocator.o .libs/mt_allocator.o
> .libs/codecvt.o .libs/compatibility.o .libs/complex_io.o .libs/ctype.o
> .libs/debug.o .libs/debug_list.o .libs/functexcept.o
> .libs/globals_io.o .libs/ios.o .libs/ios_failure.o .libs/ios_init.o
> .libs/ios_locale.o .libs/limits.o .libs/list.o .libs/locale.o
> .libs/locale_init.o .libs/locale_facets.o .libs/localename.o
> .libs/stdexcept.o .libs/strstream.o .libs/tree.o
> .libs/allocator-inst.o .libs/concept-inst.o .libs/fstream-inst.o
> .libs/ext-inst.o .libs/ios-inst.o .libs/iostream-inst.o
> .libs/istream-inst.o .libs/istream.o .libs/locale-inst.o
> .libs/misc-inst.o .libs/ostream-inst.o .libs/sstream-inst.o
> .libs/streambuf-inst.o .libs/streambuf.o .libs/string-inst.o
> .libs/valarray-inst.o .libs/wlocale-inst.o .libs/wstring-inst.o
> .libs/atomicity.o .libs/codecvt_members.o .libs/collate_members.o
> .libs/ctype_members.o .libs/messages_members.o
> .libs/monetary_members.o .libs/numeric_members.o .libs/time_members.o
> .libs/basic_file.o .libs/c++locale.o -Wl,--whole-archive
> ../libmath/.libs/libmath.a ../libsupc++/.libs/libsupc++convenience.a
> -Wl,--no-whole-archive
> -L/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/src
> -L/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/src/.libs
> -lm ../libmath/.libs/libmath.a -lm
> ../libsupc++/.libs/libsupc++convenience.a -lm
> -L/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/./gcc
> -L/home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/avr32-buildroot-linux-uclibc/bin
> -L/home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/avr32-buildroot-linux-uclibc/lib
> -L/home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/lib/gcc/avr32-buildroot-linux-uclibc/4.2.2
> -L/home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/lib/gcc/avr32-buildroot-linux-uclibc/4.2.2/../../../../avr32-buildroot-linux-uclibc/lib
> -L/home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/avr32-buildroot-linux-uclibc/sysroot/lib
> -L/home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/avr32-buildroot-linux-uclibc/sysroot/usr/lib
> -lgcc -lc -lgcc -lm -lgcc -lc -lgcc
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/./gcc/crtendS.o
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/./gcc/crtn.o
>  -Wl,-O1 -Wl,--gc-sections -Wl,-soname -Wl,libstdc++.so.6 -o
> .libs/libstdc++.so.6.0.9
> .libs/bitmap_allocator.o: In function `.LLSDA217':
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/include/ext/bitmap_allocator.h:400:
> relocation truncated to fit: R_AVR32_32_PCREL against symbol
> `DW.ref._ZTISt9bad_alloc' defined in
> .data.DW.ref._ZTISt9bad_alloc[DW.ref._ZTISt9bad_alloc] section in
> .libs/bitmap_allocator.o
> .libs/bitmap_allocator.o: In function `.LLSDA294':
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/include/ext/bitmap_allocator.h:400:
> relocation truncated to fit: R_AVR32_32_PCREL against symbol
> `DW.ref._ZTISt9bad_alloc' defined in
> .data.DW.ref._ZTISt9bad_alloc[DW.ref._ZTISt9bad_alloc] section in
> .libs/bitmap_allocator.o
> .libs/bitmap_allocator.o: In function `.LLSDA295':
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/include/ext/bitmap_allocator.h:400:
> relocation truncated to fit: R_AVR32_32_PCREL against symbol
> `DW.ref._ZTISt9bad_alloc' defined in
> .data.DW.ref._ZTISt9bad_alloc[DW.ref._ZTISt9bad_alloc] section in
> .libs/bitmap_allocator.o
> .libs/bitmap_allocator.o: In function `.LLSDA268':
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/include/ext/bitmap_allocator.h:400:
> relocation truncated to fit: R_AVR32_32_PCREL against symbol
> `DW.ref._ZTISt9bad_alloc' defined in
> .data.DW.ref._ZTISt9bad_alloc[DW.ref._ZTISt9bad_alloc] section in
> .libs/bitmap_allocator.o
> .libs/bitmap_allocator.o: In function `.LLSDA269':
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/include/ext/bitmap_allocator.h:400:
> relocation truncated to fit: R_AVR32_32_PCREL against symbol
> `DW.ref._ZTISt9bad_alloc' defined in
> .data.DW.ref._ZTISt9bad_alloc[DW.ref._ZTISt9bad_alloc] section in
> .libs/bitmap_allocator.o
> ../libsupc++/.libs/libsupc++convenience.a(new_op.o): In function `.LLSDA20':
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/libsupc++/../../../../libstdc++-v3/libsupc++/new_op.cc:50:
> relocation truncated to fit: R_AVR32_32_PCREL against symbol
> `DW.ref._ZTISt9bad_alloc' defined in
> .data.DW.ref._ZTISt9bad_alloc[DW.ref._ZTISt9bad_alloc] section in
> .libs/bitmap_allocator.o
> ../libsupc++/.libs/libsupc++convenience.a(new_opnt.o): In function `.LLSDA15':
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/libsupc++/../../../../libstdc++-v3/libsupc++/new_opnt.cc:41:
> relocation truncated to fit: R_AVR32_32_PCREL against symbol
> `DW.ref._ZTISt9bad_alloc' defined in
> .data.DW.ref._ZTISt9bad_alloc[DW.ref._ZTISt9bad_alloc] section in
> .libs/bitmap_allocator.o
> ../libsupc++/.libs/libsupc++convenience.a(new_opv.o): In function `.LLSDA15':
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/libsupc++/../../../../libstdc++-v3/libsupc++/new_opv.cc:35:
> relocation truncated to fit: R_AVR32_32_PCREL against symbol
> `DW.ref._ZTISt9bad_alloc' defined in
> .data.DW.ref._ZTISt9bad_alloc[DW.ref._ZTISt9bad_alloc] section in
> .libs/bitmap_allocator.o
> ../libsupc++/.libs/libsupc++convenience.a(vterminate.o): In function `.LLSDA59':
> /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/libsupc++/../../../../libstdc++-v3/libsupc++/vterminate.cc:65:
> relocation truncated to fit: R_AVR32_32_PCREL against symbol
> `DW.ref._ZTISt9exception' defined in
> .data.DW.ref._ZTISt9exception[DW.ref._ZTISt9exception] section in
> ../libsupc++/.libs/libsupc++convenience.a(vterminate.o)
> collect2: ld returned 1 exit status
> make[5]: *** [libstdc++.la] Error 1
> make[5]: Leaving directory
> `/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/src'
> make[4]: *** [all-recursive] Error 1
> make[4]: Leaving directory
> `/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3'
> make[3]: *** [all] Error 2
> make[3]: Leaving directory
> `/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3'
> make[2]: *** [all-target-libstdc++-v3] Error 2
> make[2]: Leaving directory
> `/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory
> `/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build'
> make: *** [/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/.stamp_built]
> Error 2
>
>
>
> Anyone seen this before?
>
>
> Thomas Petazzoni: could you send the toolchain configuration you used
> to create the AVR32 toolchain used for the autobuilders, like this
> one: http://autobuild.buildroot.net/results/645b357d470b75baa9a93eb5be4f1dc5c8c337fa/


Obviously, I forgot the attachments. Shame on me...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config
Type: application/octet-stream
Size: 49054 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130805/146b0117/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: defconfig
Type: application/octet-stream
Size: 6426 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130805/146b0117/attachment-0003.obj>

^ permalink raw reply	[flat|nested] 42+ messages in thread
* [Buildroot] AVR32 toolchain build failure
@ 2013-08-05 12:01 Thomas De Schampheleire
  2013-08-05 12:29 ` Thomas De Schampheleire
  2013-08-06 17:54 ` Thomas Petazzoni
  0 siblings, 2 replies; 42+ messages in thread
From: Thomas De Schampheleire @ 2013-08-05 12:01 UTC (permalink / raw)
  To: buildroot

Hi,

I was looking at an autobuild failure on AVR32 and tried reproducing
it locally. Unfortunately, the AVR32 toolchain that was configured was
pre-built on a 64-bit machine, which I don't have. Hence, the
configured toolchain was not usable.

Then I tried building my own AVR32 toolchain with the internal
backend, see config attached. Unfortunately, this failed as well:

 /home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/./gcc/xgcc
-shared-libgcc -B/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/./gcc
-nostdinc++ -L/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/src
-L/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/src/.libs
-B/home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/avr32-buildroot-linux-uclibc/bin/
-B/home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/avr32-buildroot-linux-uclibc/lib/
-isystem /home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/avr32-buildroot-linux-uclibc/include
-isystem /home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/avr32-buildroot-linux-uclibc/sys-include
-shared -nostdlib
/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/./gcc/crti.o
/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/./gcc/crtbeginS.o
 .libs/bitmap_allocator.o .libs/pool_allocator.o .libs/mt_allocator.o
.libs/codecvt.o .libs/compatibility.o .libs/complex_io.o .libs/ctype.o
.libs/debug.o .libs/debug_list.o .libs/functexcept.o
.libs/globals_io.o .libs/ios.o .libs/ios_failure.o .libs/ios_init.o
.libs/ios_locale.o .libs/limits.o .libs/list.o .libs/locale.o
.libs/locale_init.o .libs/locale_facets.o .libs/localename.o
.libs/stdexcept.o .libs/strstream.o .libs/tree.o
.libs/allocator-inst.o .libs/concept-inst.o .libs/fstream-inst.o
.libs/ext-inst.o .libs/ios-inst.o .libs/iostream-inst.o
.libs/istream-inst.o .libs/istream.o .libs/locale-inst.o
.libs/misc-inst.o .libs/ostream-inst.o .libs/sstream-inst.o
.libs/streambuf-inst.o .libs/streambuf.o .libs/string-inst.o
.libs/valarray-inst.o .libs/wlocale-inst.o .libs/wstring-inst.o
.libs/atomicity.o .libs/codecvt_members.o .libs/collate_members.o
.libs/ctype_members.o .libs/messages_members.o
.libs/monetary_members.o .libs/numeric_members.o .libs/time_members.o
.libs/basic_file.o .libs/c++locale.o -Wl,--whole-archive
../libmath/.libs/libmath.a ../libsupc++/.libs/libsupc++convenience.a
-Wl,--no-whole-archive
-L/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/src
-L/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/src/.libs
-lm ../libmath/.libs/libmath.a -lm
../libsupc++/.libs/libsupc++convenience.a -lm
-L/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/./gcc
-L/home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/avr32-buildroot-linux-uclibc/bin
-L/home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/avr32-buildroot-linux-uclibc/lib
-L/home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/lib/gcc/avr32-buildroot-linux-uclibc/4.2.2
-L/home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/lib/gcc/avr32-buildroot-linux-uclibc/4.2.2/../../../../avr32-buildroot-linux-uclibc/lib
-L/home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/avr32-buildroot-linux-uclibc/sysroot/lib
-L/home/tdescham/repo/contrib/buildroot-avr32/output/host/usr/avr32-buildroot-linux-uclibc/sysroot/usr/lib
-lgcc -lc -lgcc -lm -lgcc -lc -lgcc
/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/./gcc/crtendS.o
/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/./gcc/crtn.o
 -Wl,-O1 -Wl,--gc-sections -Wl,-soname -Wl,libstdc++.so.6 -o
.libs/libstdc++.so.6.0.9
.libs/bitmap_allocator.o: In function `.LLSDA217':
/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/include/ext/bitmap_allocator.h:400:
relocation truncated to fit: R_AVR32_32_PCREL against symbol
`DW.ref._ZTISt9bad_alloc' defined in
.data.DW.ref._ZTISt9bad_alloc[DW.ref._ZTISt9bad_alloc] section in
.libs/bitmap_allocator.o
.libs/bitmap_allocator.o: In function `.LLSDA294':
/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/include/ext/bitmap_allocator.h:400:
relocation truncated to fit: R_AVR32_32_PCREL against symbol
`DW.ref._ZTISt9bad_alloc' defined in
.data.DW.ref._ZTISt9bad_alloc[DW.ref._ZTISt9bad_alloc] section in
.libs/bitmap_allocator.o
.libs/bitmap_allocator.o: In function `.LLSDA295':
/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/include/ext/bitmap_allocator.h:400:
relocation truncated to fit: R_AVR32_32_PCREL against symbol
`DW.ref._ZTISt9bad_alloc' defined in
.data.DW.ref._ZTISt9bad_alloc[DW.ref._ZTISt9bad_alloc] section in
.libs/bitmap_allocator.o
.libs/bitmap_allocator.o: In function `.LLSDA268':
/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/include/ext/bitmap_allocator.h:400:
relocation truncated to fit: R_AVR32_32_PCREL against symbol
`DW.ref._ZTISt9bad_alloc' defined in
.data.DW.ref._ZTISt9bad_alloc[DW.ref._ZTISt9bad_alloc] section in
.libs/bitmap_allocator.o
.libs/bitmap_allocator.o: In function `.LLSDA269':
/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/include/ext/bitmap_allocator.h:400:
relocation truncated to fit: R_AVR32_32_PCREL against symbol
`DW.ref._ZTISt9bad_alloc' defined in
.data.DW.ref._ZTISt9bad_alloc[DW.ref._ZTISt9bad_alloc] section in
.libs/bitmap_allocator.o
../libsupc++/.libs/libsupc++convenience.a(new_op.o): In function `.LLSDA20':
/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/libsupc++/../../../../libstdc++-v3/libsupc++/new_op.cc:50:
relocation truncated to fit: R_AVR32_32_PCREL against symbol
`DW.ref._ZTISt9bad_alloc' defined in
.data.DW.ref._ZTISt9bad_alloc[DW.ref._ZTISt9bad_alloc] section in
.libs/bitmap_allocator.o
../libsupc++/.libs/libsupc++convenience.a(new_opnt.o): In function `.LLSDA15':
/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/libsupc++/../../../../libstdc++-v3/libsupc++/new_opnt.cc:41:
relocation truncated to fit: R_AVR32_32_PCREL against symbol
`DW.ref._ZTISt9bad_alloc' defined in
.data.DW.ref._ZTISt9bad_alloc[DW.ref._ZTISt9bad_alloc] section in
.libs/bitmap_allocator.o
../libsupc++/.libs/libsupc++convenience.a(new_opv.o): In function `.LLSDA15':
/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/libsupc++/../../../../libstdc++-v3/libsupc++/new_opv.cc:35:
relocation truncated to fit: R_AVR32_32_PCREL against symbol
`DW.ref._ZTISt9bad_alloc' defined in
.data.DW.ref._ZTISt9bad_alloc[DW.ref._ZTISt9bad_alloc] section in
.libs/bitmap_allocator.o
../libsupc++/.libs/libsupc++convenience.a(vterminate.o): In function `.LLSDA59':
/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/libsupc++/../../../../libstdc++-v3/libsupc++/vterminate.cc:65:
relocation truncated to fit: R_AVR32_32_PCREL against symbol
`DW.ref._ZTISt9exception' defined in
.data.DW.ref._ZTISt9exception[DW.ref._ZTISt9exception] section in
../libsupc++/.libs/libsupc++convenience.a(vterminate.o)
collect2: ld returned 1 exit status
make[5]: *** [libstdc++.la] Error 1
make[5]: Leaving directory
`/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3/src'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory
`/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3'
make[3]: *** [all] Error 2
make[3]: Leaving directory
`/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build/avr32-buildroot-linux-uclibc/libstdc++-v3'
make[2]: *** [all-target-libstdc++-v3] Error 2
make[2]: Leaving directory
`/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build'
make[1]: *** [all] Error 2
make[1]: Leaving directory
`/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/build'
make: *** [/home/tdescham/repo/contrib/buildroot-avr32/output/build/host-gcc-final-4.2.2-avr32-2.1.5/.stamp_built]
Error 2



Anyone seen this before?


Thomas Petazzoni: could you send the toolchain configuration you used
to create the AVR32 toolchain used for the autobuilders, like this
one: http://autobuild.buildroot.net/results/645b357d470b75baa9a93eb5be4f1dc5c8c337fa/

Thanks,
Thomas

^ permalink raw reply	[flat|nested] 42+ messages in thread
end of thread, other threads:[~2013-11-15  8:58 UTC | newest]

Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-11-13 21:36 [Buildroot] AVR32 toolchain build failure Thomas Petazzoni
2013-11-14  8:53 ` Simon Dawson
2013-11-14  9:10   ` Thomas Petazzoni
2013-11-15  8:58     ` Simon Dawson
  -- strict thread matches above, loose matches on Subject: below --
2013-08-05 12:01 Thomas De Schampheleire
2013-08-05 12:29 ` Thomas De Schampheleire
2013-08-06  9:27   ` Alexander Lukichev
2013-08-06  9:39     ` Alexander Lukichev
2013-08-06 14:40     ` Thomas De Schampheleire
2013-08-06 15:03       ` Thomas De Schampheleire
2013-08-08 15:35   ` Alexander Lukichev
2013-08-06 17:54 ` Thomas Petazzoni
2013-08-06 19:33   ` Thomas De Schampheleire
2013-08-07  7:05     ` Thomas De Schampheleire
2013-08-07 15:20       ` Thomas Petazzoni
2013-08-07 16:01         ` Thomas De Schampheleire
2013-08-07 18:20           ` Thomas De Schampheleire
2013-08-07 22:07             ` Thomas Petazzoni
2013-08-08  5:55               ` Thomas De Schampheleire
2013-08-08  7:21                 ` Simon Dawson
2013-08-08  8:03                   ` Thomas Petazzoni
2013-08-08 10:56                     ` Gustavo Zacarias
2013-08-08 16:18                       ` Simon Dawson
2013-08-08 17:57                         ` Gustavo Zacarias
2013-08-08 17:59                         ` Thomas Petazzoni
2013-08-13  6:15                           ` Arnout Vandecappelle
2013-08-08  8:12                   ` Thomas De Schampheleire
2013-08-08 16:09                     ` Simon Dawson
2013-08-08 17:34                       ` Thomas De Schampheleire
2013-08-08 17:57                         ` Thomas Petazzoni
2013-08-08 18:05                           ` Thomas De Schampheleire
2013-08-08 19:42                         ` Simon Dawson
2013-08-08 20:09                           ` Thomas De Schampheleire
2013-08-08 20:24                             ` Thomas De Schampheleire
2013-08-08 22:22                               ` Thiago A. Corrêa
2013-08-09  4:51                               ` Alexander Lukichev
2013-08-09  7:16                             ` Simon Dawson
2013-08-09 11:12                               ` Thomas De Schampheleire
2013-08-09 20:29                                 ` Thomas Petazzoni
2013-08-09 22:34                                   ` Gustavo Zacarias
2013-08-08  7:29                 ` Alexander Lukichev
2013-08-08  8:13                   ` Thomas De Schampheleire

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.