search

raspberrypi / tools

1.89k stars 865 forks source link

4.9 toolchain issue #50

Open solderspot opened 8 years ago

solderspot commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

solderspot commented 8 years ago

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 commented 8 years ago

I was using latest master, which at the time was

commit 8460611d5f28c9b4d8e1533238f048119a1f4a63
Author: Bryan Hundven <bryanhundven@gmail.com>
Date:   Mon Feb 15 01:17:24 2016 -0800

    Update README.md

    Newlines
bhundven commented 8 years ago

@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 commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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

carlonluca commented 8 years ago

@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 commented 8 years ago

@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 commented 8 years ago

@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 commented 8 years ago

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 notifications@github.com 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 - cmf@av.it.pt Skype & GTalk -> carlosmf.pt@gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira

thijstriemstra commented 8 years ago

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 commented 8 years ago

Same problem as everyone else.

GrubbyHalo commented 8 years ago

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

paresy commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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

grheard commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

I found a solution for arm-rpi-4.9.3-linux-gnueabihf.

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.

#!/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.

#!/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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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ý notifications@github.com 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

Shymaxtic commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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