4.9 toolchain issue #50
Comments
|
Does it help if you remove
I'm not really sure why we are getting the difference, or which is the better option. |
|
Yes, if I remove the sysroot setting then the cmake call works but the actual build (i.e. make) then fails as it cannot find the required header files: I guess I could explicitly add all the system include paths to the FLAGS define for both the compilers and the linker but it would be nicer if things were more transparent. I would also worry that not using sysroot might potentially pull in host files? |
|
I'm experiencing many errors as well. For instance I'm getting: In the old toolchain this is in: and in the sysroot this is in: but in the new toolchain this is in: Maybe this change in the layout makes the compiler unable to find these headers? I notice a layout difference between the Raspbian sysroot and the new toolchain. |
|
It's pretty easy to build the toolchain. Use https://github.com/raspberrypi/tools/blob/master/configs/arm-rpi-4.9.3-linux-gnueabihf.config as your .config and run If you find any .config options that make your builds work I'd be happy to include them (if they don't break anything). With recent toolchain I can build linux kernel, the userland libs, kodi and omxplayer without issue. |
|
The older one works properly with the same makefiles, so maybe there is a difference in the configuration that explains the different layout? |
Is there a particular release of crosstool-ng that we should use? As an aside: It would very helpful if there was some documentation (just a readme) that explained how this repo (raspberrypi/tools) is built and maintained, as well as list any important requirements for the toolchain. That way people like myself, with little or no crosstool-ng experience, can more easily help to trouble shoot and contribute... but maybe this toolchain is only meant for compiling the kernel and it is more appropriate to use other toolchain solutions for building applications? If so then stating that in a readme would be helpful too. Anyway, I'm going to try building the toolchain like you say and report back if I learn anything useful. |
|
I was using latest master, which at the time was |
|
@solderspot If you're going to do a new build, I would try the latest master. There have been some fixes to crosstool-ng since the release @popcornmix mentioned, but haven't had time to look into this specific issue. @carlonluca just brought this issue to my attention. I'm currently working on a few unrelated issues with crosstool-ng (Like, I just accidentally broke musl-libc support and am trying to fix that :P ). As soon as I'm done fixing that, I will run some builds of my own to see if I can figure this out. |
|
@bhundven should it be possible to build gcc 5.3.0 with glibc 2.19? I always get a build failure: |
|
I'm also having issues when using the rpi cross compiler v4.9.3. Btw, the rpi compiler in tools, does not support multiarch. `[claymore@claymore-laptop Boost]$ cd ~/Raspbian/Tools/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/ [claymore@claymore-laptop bin]$ |
|
@carlonluca I'm facing the same problems about sys headers. I cannot use the old toolchain due to the ICU issue #41 it seems there is no working toolchain at the moment (at least for Qt5.6 and RPi3). Is there a way to fix one of them? |
|
@Mark-81 yes build icu with the old library. No more issues. Last time I tried 4.9 it was not working in the form provided so I can't use it. |
|
@carlonluca thanks! Have you tried with RPi3? Because |
|
@Mark-81 I use the same build conf that I use on Pi2. Maybe the toolchain is too old. Those params seems to be included in 4.9: https://gcc.gnu.org/gcc-4.9/changes.html. |
|
GCC 4.9 does not support most of the c++1z features. In fact, it doesn't even support most of the C++14 features. :/ On 8 June 2016 at 18:15, Luca Carlon [email protected] wrote:
Carlos Miguel Ferreira |
|
Running into this same annoying issue, the paths are different for each compiler, e.g.: And apparently I need gcc 4.9 or my build fails with: Here's a diff between These lines look suspicious but I've never used crosstool-ng. What's < CT_PREFIX_DIR="${HOME}/tools/arm-bcm2708/${CT_TARGET}"
---
> CT_PREFIX_DIR="${HOME}/x-tools6h-new/${CT_TARGET}" |
|
Same problem as everyone else.
|
|
@ali1234 Thanks... gcc-4.9 from Linaro works flawlessly. |
|
The linaro toolchain was not able to produce valid binaries for RPi1.
|
|
@paresy, I'm glad you were able to get the repo's rpi-4.9.3 compiler to work for you, but for me its still a no go on the pi zero. Surely the raspbian guys cross compiled jessie from source. Jessie works fine on the pi zero. Where is that toolchain? I really don't want to compile on the target. |
|
Any of the compilers listed here work for me: https://releases.linaro.org/components/toolchain/binaries/latest-5/arm-linux-gnueabihf/ |
|
@thijstriemstra, doesn't work too well with jessie as the sysroot: /home/heardg/pi/system/devroot/opt/vc/lib/libEGL.so: undefined reference to |
|
Well damn. I owe @thijstriemstra and @paresy an apology. Seems I missed a couple of very important error messages:
I will admit I don't know enough about compilers or even gcc to understand what's changed, but with Linaro's 4.9-2016.02 compiler I need to add I will report back when I get things fixed up enough to link against icu to make sure everything works. Edit 2016-10-03: The above linked compiler works with the pi zero/pi 1 and the jessie image as the sysroot. Sorry for the clutter and confusion I may have caused. |
|
Hi, |
|
I found a solution for arm-rpi-4.9.3-linux-gnueabihf.
This lines fix some path not found.
This script copy crti.o and crt1.o in build directory off all' compiling project and after call real g++. This solve link errors.
You have only to change locations /home/marco in your locations. P.S. I compiler qt-base taken from apt-get source qt-default and copied on building host. It is a 5.3.2 debian patched. I do this for compatibility with originale qt libs in raspbian. |
|
@xbomber This worked for Qt 5.8 release cross compilation for Raspberry Pi 3 with latest Raspbian. Used the Qt 5.8 source archive with the linux-rasp-pi2-g++ device configuration. Followed the RaspberryPi2EGLFS instructions on a Linux Mint 17.3 x64 machine. |
|
All the errors I encountered using #!/bin/sh
set -e
exec "$0.real" "-isystem=/usr/include/arm-linux-gnueabihf" "-Wl,--rpath-link=${RPIDEV_SYSROOT}/lib/arm-linux-gnueabihf" "-Wl,--rpath-link=${RPIDEV_SYSROOT}/usr/lib/arm-linux-gnueabihf" "$@"seem to work. I've documented compiling qt5.8 + piomxtextures using |
|
@Kukkimonsuta. I follow your document but get this error
|
|
@Shymaxtic It can't find |
|
You are likely to get a faster response by posting questions like this of
the forum.
…On 5 March 2017 at 17:48, Lukáš Novotný ***@***.***> wrote:
@Shymaxtic <https://github.com/Shymaxtic> It can't find libm crt1.o crti.o
for some reason. Try installing build-essential on rpi and run 2_sync.sh
again. Let me know if it helps.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#50 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADqrHfySgZMGu-k6-L1oyor9gvtqNTKEks5rivV4gaJpZM4HeKqw>
.
--
James Hughes
Principal Software Engineer,
Raspberry Pi (Trading) Ltd
|
|
@Kukkimonsuta , This is my mistake, some folders in raspberry cannot synchronize. So 2_sync.sh not work completely. I ignore these folders and now it work. |
|
I successfully compiled a gcc 4.9.4 multiarch toolchain for host x86_64 and target armv6hf using this crosstool-ng configuration: .config I have no issue so far when compiling with I tried to compile a sample code that use openssl to retrieve the runtime version and it works fine on the raspberry. Using the Another way to deal the sysroot without having to fix absolute symlinks is to build a static cross compiler to use it inside the raspbian chroot (the same as qemu-arm-static idea). It run inside the chroot without the need of arm emulation so compilation is fast but inside the complete unmodified raspbian system as sysroot (--sysroot=/ in this case) I enabled |
|
Configuring Qt5.7 with arm-rpi-4.9.3-linux-gnueabihf for the RPI zero states that C++ 11 is disabled. Has anyone else encountered this? @xbomber did you also encounter this? |
|
@BiGsTaN69 I used linaro gcc 5.3 or newer to work around that issue. |
I was able to cross compile my project successfully for Jessie using the previous gcc-linaro-4.9-2015.02-3-x86_64_arm-linux-gnueabihf toolchain that was added briefly a few days ago. However, with the new replacement 4.9 toolchain arm-rpi-4.9.3-linux-gnueabihf I get this error when calling cmake:
Any suggestions as to what the problem is?
Here is the CMAKE_TOOLCHAIN_FILE that works fine for the previousgcc-linaro-4.9-2015.02-3-x86_64_arm-linux-gnueabihf toolchain, as well as gcc-linaro-arm-linux-gnueabihf-raspbian-x64:
[More details about the project can be found here: https://solderspot.wordpress.com/2016/02/04/cross-compiling-for-raspberry-pi-part-ii/]
The text was updated successfully, but these errors were encountered: