tools
tools copied to clipboard
raspberrypi
4.9 toolchain 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:
/home/solderspot/pidev/pitools/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/4.9.3/../../../../arm-linux-gnueabihf/bin/ld:
cannot find crt1.o: No such file or directory
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:
SET(CMAKE_SYSTEM_NAME Linux)
SET(CMAKE_SYSTEM_VERSION 1)
SET(DEVROOT $ENV{HOME}/pidev)
SET(PIROOT ${DEVROOT}/piroot)
SET(PITOOLS ${DEVROOT}/pitools)
#SET(TOOLROOT ${PITOOLS}/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64)
SET(TOOLROOT ${PITOOLS}/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf)
# specify the cross compiler
SET(CMAKE_C_COMPILER ${TOOLROOT}/bin/arm-linux-gnueabihf-gcc)
SET(CMAKE_CXX_COMPILER ${TOOLROOT}/bin/arm-linux-gnueabihf-g++)
SET(FLAGS "-Wl,-rpath-link,${PIROOT}/opt/vc/lib -Wl,-rpath-link,${PIROOT}/lib/arm-linux-gnueabihf -Wl,-rpath-link,${PIROOT}/usr/lib/arm-linux-gnueabihf -Wl,-rpath-link,${PIROOT}/usr/local/lib")
UNSET(CMAKE_C_FLAGS CACHE)
UNSET(CMAKE_CXX_FLAGS CACHE)
SET(CMAKE_CXX_FLAGS ${FLAGS} CACHE STRING "" FORCE)
SET(CMAKE_C_FLAGS ${FLAGS} CACHE STRING "" FORCE)
SET(CMAKE_SYSROOT ${PIROOT})
SET(CMAKE_FIND_ROOT_PATH ${PIROOT})
# search for programs in the build host directories
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
# for libraries and headers in the target directories
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
[More details about the project can be found here: https://solderspot.wordpress.com/2016/02/04/cross-compiling-for-raspberry-pi-part-ii/]
Does it help if you remove SET(CMAKE_SYSROOT ${PIROOT})?
crt1.o lives in arm-rpi-4.9.3-linux-gnueabihf/arm-linux-gnueabihf/sysroot/usr/lib with the new toolchain, but in gcc-linaro-arm-linux-gnueabihf-raspbian-x64/arm-linux-gnueabihf/libc/usr/lib/arm-linux-gnueabihf with the previous toolchain.
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:
solderspot@ubuntu:~/pidev/camtest/build$ make
Scanning dependencies of target PiCamCVTest
[ 20%] Building CXX object CMakeFiles/PiCamCVTest.dir/main.cpp.o
/home/solderspot/pidev/camtest/main.cpp:7:33: fatal error: opencv2/core/core.hpp: No such file or directory
#include <opencv2/core/core.hpp>
^
compilation terminated.
make[2]: *** [CMakeFiles/PiCamCVTest.dir/main.cpp.o] Error 1
make[1]: *** [CMakeFiles/PiCamCVTest.dir/all] Error 2
make: *** [all] Error 2
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:
/opt/rpi/sysroot/usr/include/features.h:374:25:` fatal error: sys/cdefs.h: No such file or directory
In the old toolchain this is in:
./arm-linux-gnueabihf/libc/usr/include/arm-linux-gnueabihf/sys/cdefs.h
and in the sysroot this is in:
./usr/include/arm-linux-gnueabihf/sys/cdefs.h
but in the new toolchain this is in:
./arm-linux-gnueabihf/sysroot/usr/include/sys/cdefs.h
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. I'm stuck with the old one for the moment.
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 ct-ng build (from https://github.com/crosstool-ng/crosstool-ng).
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?
It's pretty easy to build the toolchain.
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
commit 8460611d5f28c9b4d8e1533238f048119a1f4a63
Author: Bryan Hundven <[email protected]>
Date: Mon Feb 15 01:17:24 2016 -0800
Update README.md
Newlines
@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:
[ALL ] /home/dom/projects/crosstool-ng/install/bin/.build/arm-linux-gnueabihf/build/build-libc-final/libc_pic.os: In function `_Unwind_Resume':
[ALL ] :(.text+0x53c): undefined reference to `libgcc_s_resume'
[ERROR] collect2: error: ld returned 1 exit status
I'm also having issues when using the rpi cross compiler v4.9.3. The toolchain is unable to find the raspbian libraries in the root folder, into where I rsync the /lib and /usr folders.
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 arm-rpi-4.9.3-linux-gnueabihf]$ ls arm-linux-gnueabihf bin include lib libexec share [claymore@claymore-laptop arm-rpi-4.9.3-linux-gnueabihf]$ cd bin [claymore@claymore-laptop bin]$ ls arm-linux-gnueabihf-addr2line arm-linux-gnueabihf-c++filt arm-linux-gnueabihf-gcc arm-linux-gnueabihf-gcov arm-linux-gnueabihf-ldd arm-linux-gnueabihf-ranlib arm-linux-gnueabihf-ar arm-linux-gnueabihf-cpp arm-linux-gnueabihf-gcc-4.9.3 arm-linux-gnueabihf-gdb arm-linux-gnueabihf-nm arm-linux-gnueabihf-readelf arm-linux-gnueabihf-as arm-linux-gnueabihf-ct-ng.config arm-linux-gnueabihf-gcc-ar arm-linux-gnueabihf-gprof arm-linux-gnueabihf-objcopy arm-linux-gnueabihf-size arm-linux-gnueabihf-c++ arm-linux-gnueabihf-elfedit arm-linux-gnueabihf-gcc-nm arm-linux-gnueabihf-ld arm-linux-gnueabihf-objdump arm-linux-gnueabihf-strings arm-linux-gnueabihf-cc arm-linux-gnueabihf-g++ arm-linux-gnueabihf-gcc-ranlib arm-linux-gnueabihf-ld.bfd arm-linux-gnueabihf-populate arm-linux-gnueabihf-strip [claymore@claymore-laptop bin]$ ./arm-linux-gnueabihf-g++ --print-multiarch
[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 https://github.com/raspberrypi/tools/issues/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 gcc-linaro-arm-linux-gnueabihf-raspbian doesn't like the architecture (armv8-a+crc) and the c++ flag (c++1z). I attach the qmake.conf file for rpi3 (linux-rpi3-g++).
qmake.txt
@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. :/ https://gcc.gnu.org/projects/cxx-status.html
On 8 June 2016 at 18:15, Luca Carlon [email protected] wrote:
@Mark-81 https://github.com/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.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/raspberrypi/tools/issues/50#issuecomment-224662610, or mute the thread https://github.com/notifications/unsubscribe/AHTtIcaE5eGTtqVklTCXei-07XS4CZaOks5qJviZgaJpZM4HeKqw .
Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - [email protected] Skype & GTalk -> [email protected] LinkedIn -> http://www.linkedin.com/in/carlosmferreira
Running into this same annoying issue, the paths are different for each compiler, e.g.:
/home/raspi-build/sysroot/usr/include/pulse/mainloop-api.h:26:22: fatal error: sys/time.h: No such file or directory
#include <sys/time.h>
^
compilation terminated.
And apparently I need gcc 4.9 or my build fails with:
In file included from Include/Python.h:53:0,
from Modules/getbuildinfo.c:1:
Include/pyatomic.h:10:23: fatal error: stdatomic.h: No such file or directory
#include <stdatomic.h>
^
compilation terminated.
Makefile:944: recipe for target '.obj/getbuildinfo.o' failed
Here's a diff between bcm2708-ct-ng.config and arm-rpi-4.9.3-linux-gnueabihf.config, e.g.:
colordiff tools/configs/bcm2708-ct-ng.config tools/configs/arm-rpi-4.9.3-linux-gnueabihf.config
These lines look suspicious but I've never used crosstool-ng. What's x-tools6h-new and shouldn't this be arm-bcm2708?
< CT_PREFIX_DIR="${HOME}/tools/arm-bcm2708/${CT_TARGET}"
---
> CT_PREFIX_DIR="${HOME}/x-tools6h-new/${CT_TARGET}"
Same problem as everyone else.
- gcc-linaro-arm-linux-gnueabihf-raspbian can't link libicu from Raspbian Jessie because it is gcc 4.8 but Jessie is built with gcc 4.9
- arm-rpi-4.9.3-linux-gnueabihf does not work at all, and throws hundreds of errors on just about anything.
- gcc 4.9 direct from Linaro works fine. (https://releases.linaro.org/15.02/components/toolchain/binaries/arm-linux-gnueabihf/gcc-linaro-4.9-2015.02-3-x86_64_arm-linux-gnueabihf.tar.xz)
The linaro toolchain was not able to produce valid binaries for RPi1. After adding a lot of path information the new toolchain from this repository works.
make CC="/home/user/tools/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/bin/arm-linux-gnueabihf-g++ --sysroot=/home/user/rpi-jessie/ -I/home/user/rpi-jessie/usr/include/arm-linux-gnueabihf/ -L/home/user/rpi-jessie/usr/lib/arm-linux-gnueabihf/ -B/home/user/rpi-jessie/usr/lib/arm-linux-gnueabihf/"
@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 pthread_setspecific@GLIBC_2.4' /home/heardg/pi/system/devroot/opt/vc/lib/libvcos.so: undefined reference topthread_attr_setstacksize@GLIBC_2.4'
/home/heardg/pi/system/devroot/opt/vc/lib/libvcos.so: undefined reference to dlerror@GLIBC_2.4' /home/heardg/pi/system/devroot/opt/vc/lib/libEGL.so: undefined reference topthread_key_create@GLIBC_2.4'
/home/heardg/pi/system/devroot/opt/vc/lib/libvcos.so: undefined reference to pthread_join@GLIBC_2.4' /home/heardg/pi/system/devroot/opt/vc/lib/libEGL.so: undefined reference tosem_post@GLIBC_2.4'
/home/heardg/pi/system/devroot/opt/vc/lib/libvcos.so: undefined reference to sem_trywait@GLIBC_2.4' /home/heardg/pi/system/devroot/opt/vc/lib/libvcos.so: undefined reference todlclose@GLIBC_2.4'
/home/heardg/pi/system/devroot/opt/vc/lib/libEGL.so: undefined reference to pthread_getspecific@GLIBC_2.4' /home/heardg/pi/system/devroot/opt/vc/lib/libEGL.so: undefined reference tosem_init@GLIBC_2.4'
/home/heardg/pi/system/devroot/opt/vc/lib/libEGL.so: undefined reference to sem_wait@GLIBC_2.4' /home/heardg/pi/system/devroot/opt/vc/lib/libvcos.so: undefined reference topthread_mutexattr_init@GLIBC_2.4'
/home/heardg/pi/system/devroot/opt/vc/lib/libEGL.so: undefined reference to sem_getvalue@GLIBC_2.4' /home/heardg/pi/system/devroot/opt/vc/lib/libEGL.so: undefined reference tosem_destroy@GLIBC_2.4'
/home/heardg/pi/system/devroot/opt/vc/lib/libvcos.so: undefined reference to dlopen@GLIBC_2.4' /home/heardg/pi/system/devroot/opt/vc/lib/libvcos.so: undefined reference topthread_mutexattr_settype@GLIBC_2.4'
/home/heardg/pi/system/devroot/opt/vc/lib/libvcos.so: undefined reference to pthread_once@GLIBC_2.4' /home/heardg/pi/system/devroot/opt/vc/lib/libvcos.so: undefined reference topthread_mutexattr_destroy@GLIBC_2.4'
/home/heardg/pi/system/devroot/opt/vc/lib/libvcos.so: undefined reference to dlsym@GLIBC_2.4' /home/heardg/pi/system/devroot/opt/vc/lib/libvcos.so: undefined reference topthread_create@GLIBC_2.4'
/home/heardg/pi/system/devroot/opt/vc/lib/libEGL.so: undefined reference to pthread_key_delete@GLIBC_2.4' /home/heardg/pi/system/devroot/opt/vc/lib/libvcos.so: undefined reference toclock_gettime@GLIBC_2.4'
Well damn. I owe @thijstriemstra and @paresy an apology.
Seems I missed a couple of very important error messages:
/home/heardg/pi/linaro/gcc-linaro-4.9-2016.02-x86_64_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/4.9.4/../../../../arm-linux-gnueabihf/bin/ld: warning: libpthread.so.0, needed by /home/heardg/pi/system/devroot/opt/vc/lib/libGLESv2.so, not found (try using -rpath or -rpath-link) /home/heardg/pi/linaro/gcc-linaro-4.9-2016.02-x86_64_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/4.9.4/../../../../arm-linux-gnueabihf/bin/ld: warning: libdl.so.2, needed by /home/heardg/pi/system/devroot/opt/vc/lib/libGLESv2.so, not found (try using -rpath or -rpath-link) /home/heardg/pi/linaro/gcc-linaro-4.9-2016.02-x86_64_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/4.9.4/../../../../arm-linux-gnueabihf/bin/ld: warning: librt.so.1, needed by /home/heardg/pi/system/devroot/opt/vc/lib/libGLESv2.so, not found (try using -rpath or -rpath-link)
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 -lpthread -ldl -lrt to the linker invocation and now things are linking again.
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, What about 23-09-2016 Jessie with Raspberry Pi 3. Does that toolchain work? Or do I need to install it from Linaro? If using host Ubuntu 16.04 LTS, what kind of configuration should I use?
I found a solution for arm-rpi-4.9.3-linux-gnueabihf.
- I modified qtbase/mkspecs/devices/linux-rasp-pi-g++/qmake.conf adding this lines just afeter first include:
INCLUDEPATH += $$[QT_SYSROOT]/usr/include/arm-linux-gnueabihf
INCLUDEPATH += $$[QT_SYSROOT]/opt/vc/include
INCLUDEPATH += $$[QT_SYSROOT]/opt/vc/include/interface/vcos
INCLUDEPATH += $$[QT_SYSROOT]/opt/vc/include/interface/vcos/pthreads
INCLUDEPATH += $$[QT_SYSROOT]/opt/vc/include/interface/vmcs_host/linux
LIBS += -L$$[QT_SYSROOT]/opt/vc/lib
LIBS += -L$$[QT_SYSROOT]/usr/lib/arm-linux-gnueabihf
This lines fix some path not found.
- I renamed tools-master/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/bin/arm-linux-gnueabihf-g++ in tools-master/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/bin/arm-linux-gnueabihf-g++.real,
- I created a script named tools-master/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/bin/arm-linux-gnueabihf-g++ containing this code:
#!/bin/sh
cp path_of_your_sysroot/usr/lib/arm-linux-gnueabihf/crt* ./
$0.real "$@"
This script copy crti.o and crt1.o in build directory off all' compiling project and after call real g++. This solve link errors. Typed chmod 755 to this script.
- I created the following script for comodity in qtbase:
#!/bin/sh
./configure -opengl es2 -device linux-rasp-pi-g++ -device-option CROSS_COMPILE=/home/marco/Qt/5.3/tools-master/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/bin/arm-linux-gnueabihf- -sysroot /home/marco/Qt/5.3/sysroot -opensource -confirm-license -optimized-qmake -reduce-exports -release -make libs -prefix /usr/local/qt5pi -hostprefix /usr/local/qt5pi -v
You have only to change locations /home/marco in your locations. Now I have a cross compiling system built with g++4.9.3 and c++11 included.
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 arm-rpi-4.9.3-linux-gnueabihf toolchain seem to be based on the fact that default include/lib paths with this toolchain include arm-linux-gnueabihf/4.9.3 instead of just arm-linux-gnueabihf. Making symlink 4.9.3 to it's parent folder and renaming gcc / g++ and replacing with script
#!/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 arm-rpi-4.9.3-linux-gnueabihf toolchain here: https://github.com/Kukkimonsuta/rpi-buildqt
@Kukkimonsuta. I follow your document but get this error
rm -f verifyspec.o rm -f *~ core *.core /home/shymaxtic/raspi/tools/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/bin/arm-linux-gnueabihf-g++ -c -pipe -march=armv7-a -marm -mthumb-interwork -mfpu=neon-vfpv4 -mtune=cortex-a7 -mabi=aapcs-linux -mfloat-abi=hard --sysroot=/home/shymaxtic/raspi/sysroot -O2 -Wall -W -fPIC -I. -I/home/shymaxtic/raspi/src/qtbase/mkspecs/devices/linux-rasp-pi2-g++ -o verifyspec.o verifyspec.cpp /home/shymaxtic/raspi/tools/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/bin/arm-linux-gnueabihf-g++ -Wl,-rpath-link,/home/shymaxtic/raspi/sysroot/opt/vc/lib -Wl,-rpath-link,/home/shymaxtic/raspi/sysroot/usr/lib/arm-linux-gnueabihf -Wl,-rpath-link,/home/shymaxtic/raspi/sysroot/lib/arm-linux-gnueabihf -mfloat-abi=hard --sysroot=/home/shymaxtic/raspi/sysroot -Wl,-O1 -o verifyspec verifyspec.o
/home/shymaxtic/raspi/tools/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/4.9.3/../../../../arm-linux-gnueabihf/bin/ld: cannot find crt1.o: No such file or directory /home/shymaxtic/raspi/tools/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/4.9.3/../../../../arm-linux-gnueabihf/bin/ld: cannot find crti.o: No such file or directory /home/shymaxtic/raspi/tools/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/4.9.3/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lm collect2: error: ld returned 1 exit status Makefile:65: recipe for target 'verifyspec' failed make: *** [verifyspec] Error 1 Note: Also available for Linux: linux-clang linux-kcc linux-icc linux-cxx ERROR: Cannot compile a minimal program. The toolchain or QMakeSpec is broken.
@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 likely to get a faster response by posting questions like this of the forum.
On 5 March 2017 at 17:48, Lukáš Novotný [email protected] 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 https://github.com/raspberrypi/tools/issues/50#issuecomment-284246615, or mute the thread https://github.com/notifications/unsubscribe-auth/ADqrHfySgZMGu-k6-L1oyor9gvtqNTKEks5rivV4gaJpZM4HeKqw .
-- James Hughes Principal Software Engineer, Raspberry Pi (Trading) Ltd
