Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

4.9 toolchain issue #50

Open
solderspot opened this issue Feb 19, 2016 · 34 comments
Open

4.9 toolchain issue #50

solderspot opened this issue Feb 19, 2016 · 34 comments

Comments

@solderspot
Copy link

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/]

@popcornmix
Copy link
Contributor

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.

@solderspot
Copy link
Author

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?

@carlonluca
Copy link

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.

@popcornmix
Copy link
Contributor

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.

@carlonluca
Copy link

The older one works properly with the same makefiles, so maybe there is a difference in the configuration that explains the different layout?

@solderspot
Copy link
Author

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.

@popcornmix
Copy link
Contributor

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

@bhundven
Copy link

@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.

@popcornmix
Copy link
Contributor

@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

@ClaymorePT
Copy link

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]$
`

@ghost
Copy link

ghost commented Jun 8, 2016

@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?

@carlonluca
Copy link

@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.

@ghost
Copy link

ghost commented Jun 8, 2016

@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

@carlonluca
Copy link

@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.

@ClaymorePT
Copy link

ClaymorePT commented Jun 8, 2016

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
#50 (comment),
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

@thijstriemstra
Copy link

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}"

@ali1234
Copy link
Contributor

ali1234 commented Aug 21, 2016

Same problem as everyone else.

@GrubbyHalo
Copy link

@ali1234 Thanks... gcc-4.9 from Linaro works flawlessly.

@paresy
Copy link

paresy commented Sep 26, 2016

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/"

@grheard
Copy link

grheard commented Oct 2, 2016

@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.

@thijstriemstra
Copy link

Any of the compilers listed here work for me: https://releases.linaro.org/components/toolchain/binaries/latest-5/arm-linux-gnueabihf/

@grheard
Copy link

grheard commented Oct 2, 2016

@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'

@grheard
Copy link

grheard commented Oct 3, 2016

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.

@jyhakala
Copy link

jyhakala commented Oct 10, 2016

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?

@xbomber
Copy link

xbomber commented Nov 12, 2016

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.

@hubaiz
Copy link

hubaiz commented Feb 19, 2017

@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.

@Kukkimonsuta
Copy link

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

@Shymaxtic
Copy link

Shymaxtic commented Mar 5, 2017

@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.

@Kukkimonsuta
Copy link

@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.

@JamesH65
Copy link

JamesH65 commented Mar 6, 2017 via email

@Shymaxtic
Copy link

Shymaxtic commented Mar 6, 2017

@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.

@amurzeau
Copy link

amurzeau commented Mar 19, 2017

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 --sysroot set to a raspbian chroot (I used raspberrypi-cross-toolchain.cmake with uncommented CMAKE_CHROOT to the actual chroot dir)

I tried to compile a sample code that use openssl to retrieve the runtime version and it works fine on the raspberry.

Using the symlinks -cro /lib /usr/lib to fix absolute links in the chroot, compilation seems to work fine.

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)
To enable static gcc build, I used the same .config as above but with CT_STATIC_TOOLCHAIN set.

I enabled --enable-multiarch so the toolchain have appropriate search dirs and --enable-version-specific-runtime-libs so gcc runtime libs (like libgcc_s.so, libstdc++.so, ...) are in $(prefix)/lib/gcc/... instead of the sysroot (as raspbian don't have them in /usr/lib/ but in /usr/lib/gcc/.../4.9/)

/home/rpi/raspberry-pi/cross/toolchain-build/.build/src/gcc-4.9.4/configure
 --build=x86_64-build_pc-linux-gnu
 --host=x86_64-build_pc-linux-gnu
 --target=armv6-raspbian-linux-gnueabihf
 --prefix=/home/rpi/raspberry-pi/cross/arm-raspbian-linux-gnueabihf
 --with-sysroot=/home/rpi/raspberry-pi/cross/arm-raspbian-linux-gnueabihf/armv6-raspbian-linux-gnueabihf/sysroot
 --enable-languages=c,c++
 --with-pkgversion='crosstool-NG crosstool-ng-1.22.0-677-ga3dd55b9 - Raspbian-cross 4.9.4'
 --disable-sjlj-exceptions
 --enable-__cxa_atexit
 --disable-libmudflap
 --enable-libgomp
 --enable-libssp
 --disable-libquadmath
 --disable-libquadmath-support
 --enable-libsanitizer
 --with-gmp=/home/rpi/raspberry-pi/cross/toolchain-build/.build/armv6-raspbian-linux-gnueabihf/buildtools
 --with-mpfr=/home/rpi/raspberry-pi/cross/toolchain-build/.build/armv6-raspbian-linux-gnueabihf/buildtools
 --with-mpc=/home/rpi/raspberry-pi/cross/toolchain-build/.build/armv6-raspbian-linux-gnueabihf/buildtools
 --with-isl=/home/rpi/raspberry-pi/cross/toolchain-build/.build/armv6-raspbian-linux-gnueabihf/buildtools
 --with-cloog=/home/rpi/raspberry-pi/cross/toolchain-build/.build/armv6-raspbian-linux-gnueabihf/buildtools
 --enable-lto
 --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
 --enable-threads=posix
 --enable-linker-build-id
 --enable-plugin
 --disable-nls
 --with-system-zlib
 --enable-multiarch
 --with-local-prefix=/home/rpi/raspberry-pi/cross/arm-raspbian-linux-gnueabihf/armv6-raspbian-linux-gnueabihf/sysroot
 --enable-long-long
 --with-arch=armv6
 --with-float=hard
 --with-fpu=vfp
 --enable-libstdcxx-debug
 --enable-libstdcxx-time=yes
 --enable-version-specific-runtime-libs

@BiGsTaN69
Copy link

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?

@thijstriemstra
Copy link

@BiGsTaN69 I used linaro gcc 5.3 or newer to work around that issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests