tools
tools copied to clipboard
outdated hardfp cross compiler toolchain for raspbian
The libc version used in raspbian is 2.13 while the one comes with hardfp toolchain is 2.11. This results ldd throwing errors like sys_nerr@GLIBC_2.12 sys_errlist@GLIBC_2.12 if the code link (in)directly against libc.so.6.
I have built brand new softfp and hardfp toolchains. Not had a lot of testing, but I guess I could add them to github.
Please do so people can help testing.
That would be very useful!
Okay, I've pushed my build of 4.7.1 softfp and hardfp into raspberrypi/tools repo. Please test.
Thank you!popcornmix [email protected] wrote:Okay, I've pushed my build of 4.7.1 softfp and hardfp into raspberrypi/tools repo. Please test.
Reply to this email directly or view it on GitHub: https://github.com/raspberrypi/tools/issues/4#issuecomment-7157504
Have you got a x64 build of the toolchain for testing too?
No, but the 32 bit ones are usable on a 64 bit OS (but the not vice versa).
Thanks for your update but looks like that tool chain is built against glibc 2.14.1. Could you rebuilt the toolchain with glibc 2.13 so it matches with the one used in raspbian?
Okay, I'll try that tonight.
Can you test again? I've pushed a rebuilt versions with glibc 2.13
Cheers will let you know!
-----Original Message----- From: popcornmix [mailto:[email protected]] Sent: 23 July 2012 17:35 To: Sam Nazarko Subject: Re: [tools] outdated hardfp cross compiler toolchain for raspbian (#4)
Can you test again? I've pushed a rebuilt versions with glibc 2.13
Reply to this email directly or view it on GitHub: https://github.com/raspberrypi/tools/issues/4#issuecomment-7183212
we can build XBMC with it. Seems to be OK.
Great. So hardfloat raspbmc is coming?
yup.
Is debian wheezy using eglibc? I tried to compile a hello world c binary using the cross compiler but it will not run unless its static linked.
Looks like they are using eglibc. Check the source section of http://packages.debian.org/wheezy/libc6
Could you recompile it with eglibc 2.13? Best to download it from the source and patches from the above link.
Looks like dynamic-linker was different.
The arm-bcm2708hardfp-linux-gnueabi-gcc -dumpspecs gives dynamic-linker as /lib/ld-linux.so.3 which does not exist on raspbian.
The native gcc on raspbian gives /lib/ld-linux-armhf.so.3 for hardfp. I ended up passing dynamic-linker path to arm-bcm2708hardfp-linux-gnueabi-gcc to get my hello world program running.
Looks like we don't need eglibc at all. Will test further and let you know.
Is the memcpy/memset optimization in this toolchain?
Ref: https://github.com/simonjhall/copies-and-fills
@s7mx1 No, but unless you are producing a static build, you will get the memcpy/memset from your rootfs.
You should use the same compiler major version as raspbian does. Altough it is possible to specify the glibc / eglibc version in crosstool to the same version raspbian uses, it is not possible for libstdc++. You will get errors like the following when building C++ applications for the RaspberryPi.
/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (or similar, depends on version)
Can you specify the exact option you would like in the ct-ng config file?
Can we have "--enable-kernel=3.1.9"
basically can you match it to whatever rpi-patches is, at the moment 3.1.9, but if you upgrade match it. I created a separate issue for this https://github.com/raspberrypi/tools/issues/5 explaining the issue
@samnazarko can this be closed?