| View previous topic :: View next topic |
| Author |
Message |
roarinelk
Guru
Joined: 04 Mar 2004
Posts: 520
|
 Posted: Fri Jul 03, 2009 5:32 am Post subject: ARM EABI problems |
 |
|
Hello!
I'm trying to build a new userspace system for a ARMv6 (arm1136jf-s) target.
I've built cross-compilers as well as a native toolchain on a x64 host;
now I've run into a problem:
Some/most packages built with the native compiler fail to link with these
errors:
| Code: |
/usr/lib/gcc/armv6-unknown-linux-gnueabi/4.3.3/libgcc.a(bpabi.o):(.ARM.exidx+0x0): undefined reference to `__aeabi_unwind_cpp_pr0'
/usr/lib/gcc/armv6-unknown-linux-gnueabi/4.3.3/libgcc.a(_divdi3.o):(.ARM.exidx+0x0): undefined reference to `__aeabi_unwind_cpp_pr0'
/usr/lib/gcc/armv6-unknown-linux-gnueabi/4.3.3/libgcc.a(_udivdi3.o):(.ARM.exidx+0x0): undefined reference to `__aeabi_unwind_cpp_pr0'
|
Interestingly, cross-building on the x64 host works (for packages that can
actually be cross-compiled; unfortunately one or two packags I need stubbornely
refuse to be cross-built so I decided to build natively).
Target tuple is "armv6-unknown-linux-gnuabi", binutils-2.19.1-r1, gcc-4.3.3-r2, glibc-2.9_p20081201-r2
I googled the whole day yesterday in search of solutions, but could find none that works
(gcc built with --disable-libunwind-exceptions as suggested in a few places doesn't work either).
I started out with the armv5el-*-*-gnueabi stage3 which can be found on gentoo mirrors,
and replaced bintutils/gcc/glibc one by one with cross-built ones.
Any ideas on how to fix this properly?
Thanks! |
|
| Back to top |
|
 |
eddy89
Apprentice
Joined: 01 Feb 2006
Posts: 180
Location: /world/Italy/Torino
|
| Posted: Fri Jul 03, 2009 7:50 am Post subject: |
|
|
I solved many problem like this reading here: http://www.gentoo.org/proj/en/base/embedded/handbook/?part=1&chap=5
Especially this:
| Quote: | | The common convention is to use your /usr/CTARGET/ tree as your sysroot as the include/library directories in this tree are already encoded into the gcc cross-compiler for searching. You could use another directory and then add custom -I/-L paths to your CPPFLAGS/LDFLAGS, but this has historically proven to be problematic. Yes it works most of the time, but the corner cases are why this method is discouraged. In the embedded handbook, we'll assume you're using the sysroot as your development ROOT. |
This solved many problems but not all, like you, also I have to emerge some package natively 
I already reported the problem here:
https://forums.gentoo.org/viewtopic-t-777488.html
P.S. did you used the --stable switch using crossdev? |
|
| Back to top |
|
|
roarinelk
Guru
Joined: 04 Mar 2004
Posts: 520
|
| Posted: Fri Jul 03, 2009 9:50 am Post subject: |
|
|
I actually replaced the toolchain libraries in the rootfs with the ones from the
SYSROOT, and it *still* won't work. I suspect that there's a subtle difference
between building with CHOST=CTARGET=ARM and CHOST=x64 and CTARGET=arm.
Although the required symbols are present in libgcc_eh.a, not even forcing
gcc to link it in all the time gets rid of this error..
On SH arch I see something that may be related to it; a gcc cross-built on
x64 for CHOST=CTARGET=sh4 segfaults immediately when run on the target. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo on Alternative Architectures
