These toolchains are deprecated. They are outdated and easily available from other sources (e.g. direct from Ubuntu apt). e.g.
sudo apt-get install gcc-arm-linux-gnueabihf
There is also an aarch64 version:
sudo apt-get install gcc-aarch64-linux-gnu
Note: if building for Pi0/1 using --with-arch=armv6 --with-float=hard --with-fpu=vfp is recommended
(and matches the default flags of the toolchains included here).
First, there is no problem with msd.elf turning the device in mass storage device.
I am using a compute module with its board, problem comes with the transfer of both buildroot.elf and fatimage that fail with (large) fatimage file.
Following readme in test_code lead to generate a default fatimage file which is 20MB.
Here are the result I get with rpiboot and such an image :
$ sudo ./rpiboot -v -b fatimage -x ../test_code/test_code
Waiting for BCM2835 ...
Found serial = 0: writing file ./usbbootcode.bin
libusb_bulk_transfer returned 0
Writing 16674 bytes
libusb_bulk_transfer returned 0
Successful
Waiting for BCM2835 ...
Found serial = 1: writing file ./buildroot.elf
Adding 20635648 bytes of binary to end of elf
libusb_bulk_transfer returned 0
Writing 21609448 bytes
libusb_bulk_transfer returned -1
Failed to read correct length, returned 24
Seems that it is not the libusb_bulk_transfer which failed first but rather libusb_control_transfer (-7 / timeout ) but the returned error code is not handle (main.c:54)
The same command line seems to succeed when the fatimage is less than 8MB.
Hi,
We have found that the gcc cross-compiler is causing some problems. For example this small program:
#include <iostream>
#include <thread>
int main( int argc, char **argv )
{
std::thread thr( []() { std::cout << "Hello thread" << std::endl; } );
thr.join();
return 0;
}
if it's compiled with
g++ thread.cpp -o thread -std=c++11 -lpthread -mcpu=cortex-a7
Will output this:
pi@raspberrypi:~/src $ ./thread
pure virtual method called
terminate called without an active exception
Aborted
That should not happen.
Also, some projects seem to fail building on current gcc on this repo:
gerstrong/Commander-Genius#254
That's saying 4.9.2 because it's being retried on local, but using the 4.9.4 crosscompiler in this repo gives the same results.
Any hopes for a recent 5.x cross compiler? Building one myself is relatively easy if you can give me a working .config I can use for ct-ng, trial and error is totally crazy with these things.
`
Hi all!
I'm trying to compile a simple Qt4 application (the calculator example) using linaro-x64 toolchain. It almost compiles, but then the linking stage occurs. This is what I get (sorry for horizontal scrolling, though):
$ arm-linux-gnueabihf-g++ -o calculator button.o calculator.o main.o moc_button.o moc_calculator.o -L$PI_ROOT/usr/lib/arm-linux-gnueabihf -L$PI_TOOLS/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/arm-bcm2708-linux-gnueabi/sysroot -lQtGui -lQtCore -lpthread
/home/firegurafiku/RPI/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/../lib/gcc/arm-linux-gnueabihf/4.8.3/../../../../arm-linux-gnueabihf/bin/ld: cannot find /lib/arm-linux-gnueabihf/libpthread.so.0
/home/firegurafiku/RPI/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/../lib/gcc/arm-linux-gnueabihf/4.8.3/../../../../arm-linux-gnueabihf/bin/ld: cannot find /usr/lib/arm-linux-gnueabihf/libpthread_nonshared.a
collect2: error: ld returned 1 exit status
It seems that ld just ignores the supplied path for libpthread. On the SO I've found an advice to change the linker script. I've changed $PI_TOOLS/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/arm-linux-gnueabihf/libc/usr/lib/arm-linux-gnueabihf/libpthread.so file appropriately, but unfortunately, this hasn't changed anything.
As the last resort, I've prepended strace to the above command, and got:
$ strace (...) 2>&1 | grep '^open'
open("/usr/lib64/openmpi/lib/tls/x86_64/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/openmpi/lib/tls/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/openmpi/lib/x86_64/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/openmpi/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
open("/home/zhehe01/work/bzr/pi-build/builds/arm-linux-gnueabihf-raspbian-linux/install/share/locale/en_US.UTF-8/LC_MESSAGES/gcc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/zhehe01/work/bzr/pi-build/builds/arm-linux-gnueabihf-raspbian-linux/install/share/locale/en_US.utf8/LC_MESSAGES/gcc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/zhehe01/work/bzr/pi-build/builds/arm-linux-gnueabihf-raspbian-linux/install/share/locale/en_US/LC_MESSAGES/gcc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/zhehe01/work/bzr/pi-build/builds/arm-linux-gnueabihf-raspbian-linux/install/share/locale/en.UTF-8/LC_MESSAGES/gcc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/zhehe01/work/bzr/pi-build/builds/arm-linux-gnueabihf-raspbian-linux/install/share/locale/en.utf8/LC_MESSAGES/gcc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/zhehe01/work/bzr/pi-build/builds/arm-linux-gnueabihf-raspbian-linux/install/share/locale/en/LC_MESSAGES/gcc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
It's clear that the linker even doesn't bother itself looking for linker script I've edited. What else can I specifiy libpthread.so.0 directory?
Also note that the binary seems to contain a hard-coded path to /home/zhehe01. I don't think it's meant to be so.
UPD:
It seems I had used the linker in a wrong way, I made it working by passing other directories as arguments. But the hardcoded home directory is still an issue.
If I use Buildroot with the new hardfp i386 toolchain and the rpi-patches branch I get kernel too old error. I had to use the older x64 hardfp toolchain to get past this error. I didn't do so, but if you run file on a binary you will see the target kernel version.
You should compile glibc with --enable-kernel
Is the linaro toolchain currently in the repo still OK to crossbuild for Raspbian Jessie? I read it should be, but when trying to build something that links to icu I get this:
ICU auto-detection... ()
/opt/rpi/gcc-linaro-arm-linux-gnueabihf-raspbian/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=/opt/rpi/sysroot -O2 -Wall -W -fPIC -I. -I/opt/rpi/sysroot/home/pi/qtdeps/include -I../../../mkspecs/devices/linux-rasp-pi2-g++ -o icu.o icu.cpp
/opt/rpi/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-g++ -Wl,-rpath-link,/opt/rpi/sysroot/opt/vc/lib -Wl,-rpath-link,/opt/rpi/sysroot/home/pi/qtdeps/lib -mfloat-abi=hard --sysroot=/opt/rpi/sysroot -Wl,-O1 -o icu icu.o --sysroot=/opt/rpi/sysroot -L/opt/rpi/sysroot/home/pi/qtdeps/lib -licui18n -licuuc -licudata
/opt/rpi/sysroot/home/pi/qtdeps/lib/libicui18n.so: undefined reference to `__cxa_throw_bad_array_new_length@CXXABI_1.3.8'
collect2: error: ld returned 1 exit status
Makefile:110: recipe for target 'icu' failed
make: *** [icu] Error 1
ICU disabled.
I suppose that symbol was added in 4.9 (I may be wrong). Also I see that the compiler in the Jessie image is 4.9.2. So is this toolchain OK for Jessie? Or should I use another one?
Hi,
The CPU core on the Pi2 is a different family from the one in the original Raspberry Pi (2708 vs 2709) and the cross compiler in this repository seems to be tailored towards the Pi 1 CPU:
manuel@vader:~$ arm-bcm2708hardfp-linux-gnueabi-gcc -v -Q ppp.c
Using built-in specs.
COLLECT_GCC=arm-bcm2708hardfp-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/home/manuel/tools/arm-bcm2708/arm-bcm2708hardfp-linux-gnueabi/bin/../libexec/gcc/arm-bcm2708hardfp-linux-gnueabi/4.7.1/lto-wrapper
Target: arm-bcm2708hardfp-linux-gnueabi
Configured with: /home/extra/crosstool/staginghf/.build/src/gcc-linaro-4.7-2012.04/configure --build=i686-build_pc-linux-gnu --host=i686-build_pc-linux-gnu --target=arm-bcm2708hardfp-linux-gnueabi --prefix=/home/dc4/tools/arm-bcm2708/arm-bcm2708hardfp-linux-gnueabi --with-sysroot=/home/dc4/tools/arm-bcm2708/arm-bcm2708hardfp-linux-gnueabi/arm-bcm2708hardfp-linux-gnueabi/sysroot --enable-languages=c,c++ --with-cpu=arm1176jzf-s --with-tune=arm1176jzf-s --with-float=hard --with-pkgversion='crosstool-NG 1.15.2' --enable-__cxa_atexit --disable-libmudflap --disable-libgomp --disable-libssp --with-gmp=/home/extra/crosstool/staginghf/.build/arm-bcm2708hardfp-linux-gnueabi/buildtools --with-mpfr=/home/extra/crosstool/staginghf/.build/arm-bcm2708hardfp-linux-gnueabi/buildtools --with-mpc=/home/extra/crosstool/staginghf/.build/arm-bcm2708hardfp-linux-gnueabi/buildtools --with-ppl=/home/extra/crosstool/staginghf/.build/arm-bcm2708hardfp-linux-gnueabi/buildtools --with-cloog=/home/extra/crosstool/staginghf/.build/arm-bcm2708hardfp-linux-gnueabi/buildtools --with-libelf=/home/extra/crosstool/staginghf/.build/arm-bcm2708hardfp-linux-gnueabi/buildtools --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm -L/home/extra/crosstool/staginghf/.build/arm-bcm2708hardfp-linux-gnueabi/buildtools/lib -lpwl' --enable-threads=posix --enable-target-optspace --disable-nls --disable-multilib --with-local-prefix=/home/dc4/tools/arm-bcm2708/arm-bcm2708hardfp-linux-gnueabi/arm-bcm2708hardfp-linux-gnueabi/sysroot --enable-c99 --enable-long-long --with-float=hard
Thread model: posix
gcc version 4.7.1 20120402 (prerelease) (crosstool-NG 1.15.2)
COLLECT_GCC_OPTIONS='-v' '-Q' '-mcpu=arm1176jzf-s' '-mfloat-abi=hard' '-mtls-dialect=gnu'
/home/manuel/tools/arm-bcm2708/arm-bcm2708hardfp-linux-gnueabi/bin/../libexec/gcc/arm-bcm2708hardfp-linux-gnueabi/4.7.1/cc1 -v -iprefix /home/manuel/tools/arm-bcm2708/arm-bcm2708hardfp-linux-gnueabi/bin/../lib/gcc/arm-bcm2708hardfp-linux-gnueabi/4.7.1/ -isysroot /home/manuel/tools/arm-bcm2708/arm-bcm2708hardfp-linux-gnueabi/bin/../arm-bcm2708hardfp-linux-gnueabi/sysroot ppp.c -dumpbase ppp.c -mcpu=arm1176jzf-s -mfloat-abi=hard -mtls-dialect=gnu -auxbase ppp -version -o /tmp/cc0ugD9R.s
So you can see it's using Pi1 cpu compilation options/flags by default, uses the Pi1 FPU, etc...
Is there (or makes it sense) a Pi2 pre-built cross-compiler? This one has been SO useful to me thee years on the Pi1 for distcc... And building my own is normally a painful process prone to failures with crosstool-ng.
Tried to make the usbboot tool on my raspberrypi and it threw this error. Possibly something has changed lately with libusb?? To work around I edited the main.c file and replaced LIBUSB_LOG_LEVEL_WARNING with the number 2.
This works, but I'm not sure if this is the best approach.
Using a fresh Ubuntu 15.04 installation running on VMware on OSx
Here is what I did:
sudo apt-get install bc (was already installed)
git clone https://github.com/raspberrypi/tools
git clone --depth=1 https://github.com/raspberrypi/linux
cd linux
KERNEL=kernel7
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- bcm2709_defconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
results in the error from gcc of:
arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf-gcc: Syntax error: "(" unexpected
I'm seeing this has been reported in the past but no resolutions have been given.
Could someone give me a clue?
I am trying to compile Python 2 using the tools in arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin. During the configure process, I get the following output:
checking for getaddrinfo... yes
checking getaddrinfo bug... yes
Fatal: You must get working getaddrinfo() function.
or you can specify "--disable-ipv6".
This seems to be a bug with these tools, because the same Python compiles for x86_64 Linux fine.
I know the configure script is picking up the tools correctly, because I see output like checking host system type... arm-unknown-linux-gnueabihf and checking for arm-linux-gnueabihf-gcc... arm-linux-gnueabihf-gcc.
I am using the following Makefile to build Python. It is part of the depends system adopted from Bitcoin Core designed to build software dependencies in a reproducible way. It doesn't work standalone, but you can still get an idea of what it does.
package=python2
$(package)_version=2.7.9
$(package)_download_path=https://www.python.org/ftp/python/$($(package)_version)
$(package)_file_name=Python-$($(package)_version).tgz
$(package)_sha256_hash=c8bba33e66ac3201dabdc556f0ea7cfe6ac11946ec32d357c4c6f9b018c12c5b
define $(package)_config_cmds
$($(package)_autoconf) --build=$(BUILD)
endef
define $(package)_build_cmds
$(MAKE)
endef
define $(package)_stage_cmds
$(MAKE) DESTDIR=$($(package)_staging_dir) install
endef
As you can see it downloads Python 2.7.9 and verifies the hash. It runs ./configure with some standard flags like --host. I also supply --build. Then it runs make and make DESTDIR=... install. This same exact Makefile works with x86_64-unknown-linux-gnu as the --host parameter.
The relevant section of configure.ac from Python is line 3514 of configure.ac. That is a link to Python 3, but you get the idea. It looks like there are a number of things checked in that one getaddrinfo() check, so I am not sure which one is actually the issue.
These two different files on your system collide on Windows:
...\raspberrypi-tools\arm-bcm2708\arm-bcm2708-linux-gnueabi\arm-bcm2708-linux-gnueabi\sysroot\usr\include\linux\netfilter\xt_DSCP.h
...\raspberrypi-tools\arm-bcm2708\arm-bcm2708-linux-gnueabi\arm-bcm2708-linux-gnueabi\sysroot\usr\include\linux\netfilter\xt_dscp.h
I am attempting to cross compile for the Pi using CMAKE on Windows, but I can't even clone your tools. Please consider renaming the files with similar names in your next iteration.
I have problem during kernel cross-compilation.
First I did on RPi, where $pendrive is path (e.g. /media/SD_2GB).
cd /usr/src
git clone --depth 1 git://github.com/raspberrypi/firmware.git
cd firmware/boot
cp fixup.dat bootcode.bin start.elf start_cd.elf fixup_cd.dat kernel_cutdown.img kernel_emergency.img /boot/
zcat /proc/config.gz > $pendrive/.config
apt-get install -y make gcc libncurses5-dev
rm -r $pendrive/linux
cd /usr/src
git clone --depth 1 git://github.com/raspberrypi/tools.git
cd tools/arm-bcm2708
cp -r arm-bcm2708hardfp-linux-gnueabi /
cd /
mv arm-bcm2708hardfp-linux-gnueabi cross
rm -r /usr/src/tools
rm -r /usr/src/firmware
Next I did on PC(Ubuntu), where $pendrive is path and $cores is number of CPU cores:
apt-get -y install make gcc git libncurses5-dev
cd /usr/src
git clone --depth 1 git://github.com/raspberrypi/linux.git
cp $pendrive/.config /usr/src/linux/
cd /usr/src
git clone --depth 1 git://github.com/raspberrypi/tools.git
apt-get -y install gcc-arm-linux-gnueabihf
apt-get -y install ia32-libs
cd tools/arm-bcm2708
cp -r arm-bcm2708hardfp-linux-gnueabi /
cd /
mv arm-bcm2708hardfp-linux-gnueabi raspbian
cd /usr/src/linux
make ARCH=arm CROSS_COMPILE=/raspbian/bin/arm-bcm2708hardfp-linux-gnueabi- menuconfig
make -j"$cores" ARCH=arm CROSS_COMPILE=/raspbian/bin/arm-bcm2708hardfp-linux-gnueabi-
make modules -j"$cores" ARCH=arm CROSS_COMPILE=/raspbian/bin/arm-bcm2708hardfp-linux-gnueabi-
cd /usr/src/tools/mkimage
./imagetool-uncompressed.py /usr/src/linux/arch/arm/boot/zImage
cp kernel.img $pendrive
cd /usr/src
tar czfv $pendrive/linux.tar.gz linux/
rm -r /raspbian
rm -r /usr/src/tools
Then I did on RPi, where &pendrive is path:
cp $pendrive/kernel.img /boot/
cp $pendrive/linux.tar.gz /usr/src/
cd /usr/src
tar -xzf linux.tar.gz
rm linux.tar.gz
cd /usr/src/linux
make ARCH=arm CROSS_COMPILE=/cross/bin/arm-bcm2708hardfp-linux-gnueabi- modules_install INSTALL_MOD_PATH=/
Three scripts with above code are here:
https://github.com/piotr-e/cross_compile
... and during last command I have error: Syntax error: ")" unexpected
(...)
root@raspberrypi:/usr/src/linux# ARCH=arm CROSS_COMPILE=/cross/bin/arm-bcm2708hardfp-linux-gnueabi- make modules_install INSTALL_MOD_PATH=/
/cross/bin/arm-bcm2708hardfp-linux-gnueabi-gcc: 1: /cross/bin/arm-bcm2708hardfp-linux-gnueabi-gcc: Syntax error: word unexpected (expecting ")")
INSTALL arch/arm/oprofile/oprofile.ko
INSTALL crypto/aes_generic.ko
INSTALL crypto/arc4.ko
INSTALL crypto/async_tx/async_memcpy.ko
(...)
This error do not stop modules installing, but I cannot compile anything by make and make install.
root@raspberrypi:/usr/src/stk1160# make
make -C /lib/modules/3.2.27+/build M=/usr/src/stk1160 modules
make[1]: Wejście do katalogu `/usr/src/linux'
Building modules, stage 2.
MODPOST 1 modules
scripts/mod/modpost: 1: scripts/mod/modpost: Syntax error: ")" unexpected
make[2]: *** [__modpost] Błąd 2
make[1]: *** [modules] Błąd 2
make[1]: Opuszczenie katalogu`/usr/src/linux'
make: **\* [all] Błąd 2
root@raspberrypi:/usr/src/stk1160# ls
Makefile stk1160-core.c stk1160-i2c.c stk1160-reg.h stk1160-video.c
modules.order stk1160-core.o stk1160-i2c.o stk1160-v4l.c stk1160-video.o
README.md stk1160.h stk1160.o stk1160-v4l.o
root@raspberrypi:/usr/src/stk1160#
Cross_Compiling is described step by step here:
http://elinux.org/RPi_Kernel_Compilation
What is wrong or what do I do bad ??
I get the following error when cross compiling my program:
opened script file /home/ugo/dev/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/arm-linux-gnueabihf/libc/usr/lib/arm-linux-gnueabihf/libpthread.so
opened script file /home/ugo/dev/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/arm-linux-gnueabihf/libc/usr/lib/arm-linux-gnueabihf/libpthread.so
attempt to open /lib/arm-linux-gnueabihf/libpthread.so.0 failed
attempt to open /usr/lib/arm-linux-gnueabihf/libpthread_nonshared.a failed
/home/ugo/dev/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/../lib/gcc/arm-linux-gnueabihf/4.8.3/../../../../arm-linux-gnueabihf/bin/ld: cannot find /lib/arm-linux-gnueabihf/libpthread.so.0
/home/ugo/dev/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/../lib/gcc/arm-linux-gnueabihf/4.8.3/../../../../arm-linux-gnueabihf/bin/ld: cannot find /usr/lib/arm-linux-gnueabihf/libpthread_nonshared.a
Part of cmake Toolchain:
SET(CMAKE_FIND_ROOT_PATH $ENV{ROOTFS_DIR} $ENV{CROSSROOT_DIR})
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -march=armv6 -mtune=arm1176jzf-s -mfloat-abi=hard -mfpu=vfp --sysroot=$ENV{ROOTFS_DIR}" CACHE STRING "cache it")
SET(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} --sysroot=$ENV{ROOTFS_DIR}" CACHE STRING "cache it")
SET(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} --sysroot=$ENV{ROOTFS_DIR}" CACHE STRING "cache it")
SET(CMAKE_MODULE_LINKER_FLAGS "${CMAKE_MODULE_LINKER_FLAGS} --sysroot=$ENV{ROOTFS_DIR}" CACHE STRING "cache it")
ld cannot find pthread even though the library seems to correctly match the location in sysroot.
i.e. $ENV{ROOTFS_DIR}/lib/arm-linux-gnueabihf/libpthread.so.0 exists
The solution given in the following links is to remove the relative paths from pthread (and libc) linker scripts (tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/arm-linux-gnueabihf/libc/usr/lib/arm-linux-gnueabihf/libpthread.so):
http://go-robot.blogspot.fr/2014_09_01_archive.html
http://linux.bytesex.org/cross-compiler.html
http://www.mira-project.org/MIRA-doc/CrossCompilePage.html
...
It fixed my problem. Does it make sense to send a pull request removing this absolute path on the repository ?
Please re-build arm-linux-gnueabihf-gdb from the linaro toolchain with Python scripting support so that e.g. Qt Creator (version 3.1.1 in my case) can be used for debugging.
Hi I know you are doing a great job but at the moment it's really a mess if you
want to cross-develop - specially if you are on a Mac.
What I found so far is
http://www.welzels.de/blog/en/arm-cross-compiling-with-mac-os-x/
http://www.jaredwolff.com/blog/cross-compiling-on-mac-osx-for-raspberry-pi/
but these sites (the libs / packages) are quite outdated.
There is also a none-eabi hombrew formula (Caskroom/cask/gcc-arm-embedded) - this just overcomplicates things if you just want the write a "normal" C++ program and not a full blown kernel.
I also tried to crosstool-ng but after installing gcc 5 and all the other things I get a link error. Drives me crazy!
Raspbian Jessie is able to support the -std=c++14 flags but these tools don't understand it.
Sorry if this is a duplicate as github doesn't allow for searching of the + character
I've been trying to compile the RPi's kernel using Ubuntu to cross-compile. I've been using a default configuration, and every time I try and compile the kernel, I get this error:
^
arch/arm/kernel/asm-offsets.c:54:2: error: #error and result in filesystem corruption and oopses.
#error and result in filesystem corruption and oopses.
I've followed the documentation on the official Raspberry Pi website, and as someone who's new to kernel compilation, I'm not quite sure how to fix this. Maybe it's an issue that only I'm experiencing, and if so, does anyone know how to resolve this?
Hi there,
I was using an old Raspbian sysroot (living in /opt/rpi_root on my building X86 system) which had it's libs, headers and .so LD scripts in "standard" routes like /usr/lib, /lib, /usr/include, etc...
Now (probably time ago, I just hadn't updated my Rpi crosscompilation sysroot) , the architecture-specific headers, libs and .so LD scripts have been moved their arm-linux-gnueabihf subdirs: that is, Raspbian has adopted the "multiarch" feature which allows the same lib to be present for different architectures on the same rootfs.
The problem here is that the cross-compiler in this repository is not build with the "--enable-mutiarch --target=arm-linux-gnueabihf" configure options, so it looks for libs, crt*.o files, headers and .so LD scrips in "standard" pre-multiarch locations like /usr/lib, /lib, /us/include... without the arm-linux-gnueabihf subdirs.
So, unless I am missing something here, I just don't understand how people can cross-compile these days. I have also tried building my own cross-compiler with crosstool-ng, but I can't see where it has support for "multiarch".
What am I missing here? Thanks
I'm trying to cross-build a project that uses CMAKE. I am using a toolchain file for this.
First I export the path with the arm cross-compiler:
PATH=$PATH:$HOME/tools/arm-bcm2708/arm-bcm2708hardfp-linux-gnueabi/bin `
Then I have created a toolchain file with these contents (the target system usr,lib,and opt directories from Raspbian are in /opt/rpi_root):
SET(CMAKE_SYSTEM_NAME Linux)
SET(CMAKE_SYSTEM_VERSION 1)
SET(CMAKE_C_COMPILER arm-bcm2708hardfp-linux-gnueabi-gcc)
SET(CMAKE_CXX_COMPILER arm-bcm2708hardfp-linux-gnueabi-g++)
SET(CMAKE_FIND_ROOT_PATH /opt/rpi_root)
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
Then I use cmake like this, passing the toolchain file to it:
cmake -DUSE_SDL2=yes -DBUILD_TARGET=LINUX -DCMAKE_BUILD_TYPE=Release -DOGG=no -DTREMOR=NO -DOPENGL=no -DREFKEEN=no -DCMAKE_TOOLCHAIN_FILE=~/src/raspi.cmake ..
It results on the buildsystem to find everything alright, apparently:
manuel@vader:/src/Commander-Genius/build$ cmake -DUSE_SDL2=yes -DBUILD_TARGET=LINUX -DCMAKE_BUILD_TYPE=Release -DOGG=no -DTREMOR=NO -DOPENGL=no -DREFKEEN=no -DCMAKE_TOOLCHAIN_FILE=/src/raspi.cmake ..
-- The C compiler identification is GNU 4.7.1
-- The CXX compiler identification is GNU 4.7.1
-- Check for working C compiler: /home/manuel/tools/arm-bcm2708/arm-bcm2708hardfp-linux-gnueabi/bin/arm-bcm2708hardfp-linux-gnueabi-gcc
-- Check for working C compiler: /home/manuel/tools/arm-bcm2708/arm-bcm2708hardfp-linux-gnueabi/bin/arm-bcm2708hardfp-linux-gnueabi-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /home/manuel/tools/arm-bcm2708/arm-bcm2708hardfp-linux-gnueabi/bin/arm-bcm2708hardfp-linux-gnueabi-g++
-- Check for working CXX compiler: /home/manuel/tools/arm-bcm2708/arm-bcm2708hardfp-linux-gnueabi/bin/arm-bcm2708hardfp-linux-gnueabi-g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- cotire 1.7.6 loaded.
-- Preparing the Build-System for Commander Genius
-- Setting SYSTEM_DATA_DIR to /usr/local/
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.28")
-- checking for one of the modules 'sdl2'
-- Using shared SDL Version 2 for Commander Genius
-- Boost version: 1.55.0
-- checking for one of the modules 'SDL2_image>=2.0.0'
-- Using shared SDL Version 2 for Commander Genius
-- DOSBox-Fusion: OFF
-- Internal Downloader: OFF
-- Refkeen for Keen Dreams: no
-- CXX target CGeniusExe cotired.
-- CPACK_PACKAGE_VERSION = 1.9.1-Beta
-- Build system is prepared. To Build the project just type "make"
-- If you want to create the installation package just type "make package" after you build the project
-- Configuring done
-- Generating done
-- Build files have been written to: /home/manuel/src/Commander-Genius/build
BUT when I try to build it, there are problems with header file location:
[ 14%] Building CXX object src/graphics/CMakeFiles/graphics.dir/effects/CColorMerge.cpp.o
In file included from /usr/include/SDL2/SDL_stdinc.h:40:0,
from /usr/include/SDL2/SDL_main.h:25,
from /usr/include/SDL2/SDL.h:32,
from /home/manuel/src/Commander-Genius/src/graphics/effects/CColorMerge.h:14,
from /home/manuel/src/Commander-Genius/src/graphics/effects/CColorMerge.cpp:8:
/opt/rpi_root/usr/include/stdlib.h:760:34: fatal error: bits/stdlib-bsearch.h: No such file or directory
compilation terminated.
src/graphics/CMakeFiles/graphics.dir/build.make:54: recipe for target 'src/graphics/CMakeFiles/graphics.dir/effects/CColorMerge.cpp.o' failed
make[2]: *** [src/graphics/CMakeFiles/graphics.dir/effects/CColorMerge.cpp.o] Error 1
CMakeFiles/Makefile2:1213: recipe for target 'src/graphics/CMakeFiles/graphics.dir/all' failed
make[1]: *** [src/graphics/CMakeFiles/graphics.dir/all] Error 2
Makefile:136: recipe for target 'all' failed
make: *** [all] Error 2
That particular file is present in the target root system:
manuel@vader:~/src/Commander-Genius/build$ find /opt/rpi_root/usr/include -name stdlib-bsearch.h
/opt/rpi_root/usr/include/arm-linux-gnueabihf/bits/stdlib-bsearch.h
...but it seems the buildsystem does not look for headers in that arm-linux-gnueabihf subdirectory.
How can I convince it to do so, to look in the arm-linux-gnueabihf subdir too?
Please add a root-level REAME.md file that explains the differences between the four different toolchains contained in the arm-bcm2708 directory. (If I knew the difference, I would have happily filed a PR.)
Please!!!! provide us with a current toolchain for Mac. After 3 days I gave up to build one by myself.
ct-ng with clang on Mac is horrible!!!!
I am trying to cross-compile a Raspberry Pi application using this tool chain on a Ubuntu 14.0.4.3 64 bit server instance but am experiencing an issue I'm not sure how to handle.
On the Ubuntu instance I have copied over the /usr tree from my pi to a piroot folder. In the CMakeLists.txt file I have:
include_directories(SYSTEM ${PIROOT}/usr/include ...
where PIROOT is the path to the piroot folder.
However, I get the following compiler error:
[ 20%] Building CXX object CMakeFiles/PiCamCVTest.dir/main.cpp.o
In file included from /home/solderspot/pidev/piroot/opt/vc/include/interface/vcos/pthreads/vcos_platform.h:59:0,
from /home/solderspot/pidev/piroot/opt/vc/include/interface/vcos/vcos.h:116,
from /home/solderspot/pidev/piroot/opt/vc/include/interface/vmcs_host/vc_dispmanx.h:33,
from /home/solderspot/pidev/piroot/opt/vc/include/bcm_host.h:50,
from /home/solderspot/pidev/camtest/mmalincludes.h:9,
from /home/solderspot/pidev/camtest/camera.h:3,
from /home/solderspot/pidev/camtest/main.cpp:5:
/home/solderspot/pidev/piroot/usr/include/stdlib.h:955:31: fatal error: bits/stdlib-float.h: No such file or directory
#include <bits/stdlib-float.h>
^
compilation terminated.
make[2]: *** [CMakeFiles/PiCamCVTest.dir/main.cpp.o] Error 1
make[1]: *** [CMakeFiles/PiCamCVTest.dir/all] Error 2
So the compiler is correctly referencing the piroot/usr/include tree but stdlib.h's reference to bits/stdlib-float.h is failing to find it in piroot/usr/include/arm-linux-gnueabihf
My question is: Why does the compiler not know to search the platform specific folders? Is there some setting I'm missing?
Here is more info which might be helpful:
The application compiles and runs on the native system.
I've been able to compile and run a simple hello world program with this toolchain.
This is the CMAKE_TOOLCHAIN_FILE:
SET(CMAKE_SYSTEM_NAME Linux)
SET(CMAKE_SYSTEM_VERSION 1)
SET(TOOLROOT ${PITOOLS}/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64)
# specify the cross compiler
SET(CMAKE_C_COMPILER ${TOOLROOT}/bin/arm-linux-gnueabihf-gcc)
SET(CMAKE_CXX_COMPILER ${TOOLROOT}/bin/arm-linux-gnueabihf-g++)
# 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)
Where PITOOLS is the path to the this repo.
And the CMakeLists.txt for the project is:
cmake_minimum_required(VERSION 2.8)
project( PiCamCVTest )
SET(COMPILE_DEFINITIONS -Werror)
include_directories(SYSTEM ${PIROOT}/usr/include ${PIROOT}/opt/vc/include ${PIROOT}/opt/vc/include/interface/vcos/pthreads ${PIROOT}/opt/vc/include/interface/vmcs_host/linux )
link_directories( ${PIROOT}/opt/vc/lib )
add_executable(PiCamCVTest main.cpp camera.cpp cameracontrol.cpp graphics.cpp)
target_link_libraries(PiCamCVTest libmmal_core.so libmmal_util.so libmmal_vc_client.so libvcos.so librt.so libbcm_host.so GLESv2 EGL libopencv_core.so libopencv_imgproc.so)
I've detailed my efforts in two journal posts: http://wp.me/p493sy-xY and http://wp.me/p493sy-xY
The project I'm trying to cross-compile is here: https://github.com/solderspot/PiCamCVTest
I dont think I'm being an idiot but I can't definitely rule it out. I'm trying to use the rpiboot program to boot Pi zero without SD card, which I think should be straightforward since few problems reported here or elsewhere. But I just can't get it to work at all. I hope someone can help.
I have a Pi Zero with empty card slot. A micro A / USB A cable connected to Pi Zero micro USB. Host is Intel based PC with 64 bit Ubuntu 14.04 (3.19.0-33-generic).
On the host PC I have done the following (as per instructions)
git clone --depth=1 https://github.com/raspberrypi/tools
cd tools/usbboot
sudo apt-get install libusb-1.0-0-dev
make
cc -g -o rpiboot main.c -lusb-1.0
sudo make install
cp rpiboot /usr/bin
mkdir -p /usr/share/rpiboot
cp usbbootcode.bin /usr/share/rpiboot
cp msd.elf /usr/share/rpiboot
cp buildroot.elf /usr/share/rpiboot
Plug the USB A (connected to Pi Zero) into my Host PC
dmesg
usb 2-1.8: new full-speed USB device number 7 using ehci-pci
usb 2-1.8: New USB device found, idVendor=0a5c, idProduct=2763
usb 2-1.8: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 2-1.8: Product: BCM2708 Boot
usb 2-1.8: Manufacturer: Broadcom
lsusb
Bus 002 Device 007: ID 0a5c:2763 Broadcom Corp.
sudo rpiboot -v
Waiting for BCM2835 ...
Found serial = 0: writing file ./usbbootcode.bin
libusb_bulk_transfer returned 0
Writing 16674 bytes
libusb_bulk_transfer returned 0
Successful
Waiting for BCM2835 ...
It just waits(and waits and waits...), and lsusb entry has gone.
Looking at the code in main.c it seems that the device has been found and usbbootcode.bin has been successfully sent and received. But that the re-enumeration at serial=1 is not happening.
I hacked the code a bit to step through the processes and to get debug messages which I can supply if its going to help. The upshot is that the device detaches subsequent to the epread but doesn't re-register as expected.
I know that it may be said the cable/power may be cause. It seems to me that getting as far through the rpiboot process as I am, seems to mitigate against a cable/power problem. Also I have completed the Adafruit tutorial on Pi Zero gadget [https://learn.adafruit.com/turning-your-raspberry-pi-zero-into-a-usb-gadget] with the same host/cable/power and got ethernet over usb working well so I think I can say that the cable and power are both OK.
It seems that similar problems are not being reported which leads me to think that I have made an elementary error, But I don't know what.
regards
Andy
Please put the latest i2c-dev.h in the tool chain.
To fix my compile problem, I copied the latest i2c-dev. h into the tool chain.
cp /usr/include/linux/i2c-dev.h ./arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/arm-linux-gnueabihf/libc/usr/include/linux/i2c-dev.h
Now, compile works and the resulting image runs properly on the RPi.
Before replacing i2c-dev.h,
make PROGXX=lis3lv02
/home/tomdean/RaspberryPi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf-g++ -I../include -I. -Os -mcpu=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard -marm -c -o lis3lv02.o lis3lv02.cc
lis3lv02.cc: In constructor 'LIS3LV02::LIS3LV02()':
lis3lv02.cc:33:59: error: 'i2c_smbus_write_i2c_block_data' was not declared in this scope
res = i2c_smbus_write_i2c_block_data(device, reg, 2, buf);
^
lis3lv02.cc: In member function 'void LIS3LV02::read_accel()':
lis3lv02.cc:71:57: error: 'i2c_smbus_read_i2c_block_data' was not declared in this scope
res = i2c_smbus_read_i2c_block_data(device, reg, 6, buf);
^
make: *** [lis3lv02.o] Error 1
There is already an issue open for adding a readme file (#10) and that would be nice to have. However, what is more important is to clarify the licenses of the various components in this repository. I would like to re-distribute the contents of 'mkimage' but need clarity on the license conditions.
Please add a top level COPYING or LICENSE file to let us know what we can do with this code.
Where do I find the source code of the toolchain in "arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf"?
Also, please clarify the license of mkimage/mkknlimg and mkimage/knlinfo. They simply say "Licensed under the terms of the GNU General Public License.". Is that the GPL v2, v3 or "v2 or later" or something else? It would be really helpful to include a full copy of the relevant version of the GPL in this repository.
Many Thanks,
Paul Barker
hi,
I want to read jemalloc on raspberrypi, and how to i can get the code of jemalloc on rasberrypi. As it works on ARMs .so I want to know what's the difference between jemalloc on raspberrypi and http://www.canonware.com/jemalloc/ ,thanks.
It seems that the compiler does not implement c++11 standard language as -std=c++11 but only with -std=c++0x with the defined macro __cplusplus != 201103L.
How can we use the c++11 standard with this compiler ?
Most systems don't have an executable called 'python2' and so env won't find it if you try to run it directly, eg:
$ ./imagetool-uncompressed.py <foo>
/usr/bin/env: python2: No such file or directory
fails, whereas
python imagetool-uncompressed.py <foo>
works.
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.
When I try to crossbuild the 4.1.6 emlid kernel for the raspberry pi 2, the crosscompiler crashes with the following error.
lib/raid6/neon4.c: In function ‘raid6_neon4_gen_syndrome_real’:
lib/raid6/neon4.c:113:1: internal compiler error: in dwarf2out_frame_debug_adjust_cfa, at dwarf2cfi.c:1078
}
After a short research I found the following launchpad bug(https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1429894), which mentions the exact same problem.
Hello all,
To be honest, I'm not certain this is actually a bug, as I only use the cross tools for distcc, but I noticed that running ld --verbose* arshows that the cross-ld attempts to search for libraries on the hosts' system path:
/opt/rpi_tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-ld --verbose | less
GNU ld (crosstool-NG linaro-1.13.1-4.8-2014.01 - Linaro GCC 2013.11) 2.24.0.2013
1220
Supported emulations:
armelf_linux_eabi
armelfb_linux_eabi
using internal linker script:
==================================================
/* Script for -z combreloc: combine and sort reloc sections */
OUTPUT_FORMAT("elf32-littlearm", "elf32-bigarm",
"elf32-littlearm")
OUTPUT_ARCH(arm)
ENTRY(_start)
SEARCH_DIR("=/usr/local/lib/arm-linux-gnueabihf"); SEARCH_DIR("=/usr/local/lib")
; SEARCH_DIR("=/lib/arm-linux-gnueabihf"); SEARCH_DIR("=/lib"); SEARCH_DIR("=/us
r/lib/arm-linux-gnueabihf"); SEARCH_DIR("=/usr/lib");
I imagine most people using the cross-compilers are using them in conjunction with distcc, so this issue wouldn't manifest itself much in practice. However, for those who are attempting to build and link on an x86 machine before sending their code off to the Pi, I can't help but wonder that ld will attempt to link against x86 libraries with the same name as arm libraries. The search path provides an opportunity for x86 libraries to be found before arm libraries, especially in /usr/local/lib.
However, again, I do not know for sure, if this is a bug. ld, the gcc compiler driver, and the toolchain itself may be manipulating paths in ways that I don't see, and currently I'm not in a position to test by cross-compiling a libc. I'm simply asking if the ld search path as-is is intentional.
Thanks for any clarification!
*Some perspective: I'm trying to build a freestanding cross gcc that doesn't depend on a target c stdlib. One issue I've noticed is that libssp must be disabled in such cases. Yet these arm cross compilers have libssp enabled (of course, they can be used in "freestanding mode", a la distcc without pump :P, but still), so I was attempting to look for the libc which the arm cross compilers link against in the linker script.
It would be wonderful if there was some kind of tutorial on how to use the tools in this repo.
If one already exists, maybe a readme file pointing to that tutorial could be added to the project?
It was available but is no more.
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/]
Seems that all of the toolchains present have the *hf suffix...
But I'm trying to deduce meaning and intent, since there aren't any docs ;-)
When trying to use these for a cross-compile on an x86_64 system for the rpi1, I'm trying to use the contents of tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin but I probably need a gcc-linaro-arm-linux-gnueabi-raspbian-x64/bin and one isn't present.
Or more likely, I am misunderstanding...
Thanks!
Hi there,
After the last commit (b49947c) to upgrade the linaro toolchain to 4.8, I'm consistently hitting an error during linking:
$ arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-gcc /tmp/tmp.c -o /tmp/tmp.out
arm-linux-gnueabihf-gcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
compilation terminated.
$
The liblto_plugin seems to exist:
$ find arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/|grep liblto
arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/libexec/gcc/arm-linux-gnueabihf/4.8.3/liblto_plugin.so.0.0.0
arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/libexec/gcc/arm-linux-gnueabihf/4.8.3/liblto_plugin.so.0
$
However, gcc isn't looking for it in the right place - strace shows:
$ strace ./arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-gcc /tmp/tmp.c -o /tmp/tmp.pi 2>&1|grep liblto
access("/home/johny/src/MVPSS/linux-buildroot/toolchain_rpi_bcm2708/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/../libexec/gcc/arm-linux-gnueabihf/4.8.3/liblto_plugin.so", R_OK) = -1 ENOENT (No such file or directory)
access("/home/johny/src/MVPSS/linux-buildroot/toolchain_rpi_bcm2708/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/../libexec/gcc/arm-linux-gnueabihf/liblto_plugin.so", R_OK) = -1 ENOENT (No such file or directory)
access("/home/johny/src/MVPSS/linux-buildroot/toolchain_rpi_bcm2708/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/../libexec/gcc/liblto_plugin.so", R_OK) = -1 ENOENT (No such file or directory)
access("/home/johny/src/MVPSS/linux-buildroot/toolchain_rpi_bcm2708/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/../libexec/gcc/arm-linux-gnueabihf/liblto_plugin.so", R_OK) = -1 ENOENT (No such file or directory)
access("/home/johny/src/MVPSS/linux-buildroot/toolchain_rpi_bcm2708/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/../lib/gcc/arm-linux-gnueabihf/4.8.3/../../../../arm-linux-gnueabihf/bin/arm-linux-gnueabihf/4.8.3/liblto_plugin.so", R_OK) = -1 ENOENT (No such file or directory)
access("/home/johny/src/MVPSS/linux-buildroot/toolchain_rpi_bcm2708/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/../lib/gcc/arm-linux-gnueabihf/4.8.3/../../../../arm-linux-gnueabihf/bin/arm-linux-gnueabihf/liblto_plugin.so", R_OK) = -1 ENOENT (No such file or directory)
access("/home/johny/src/MVPSS/linux-buildroot/toolchain_rpi_bcm2708/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/../lib/gcc/arm-linux-gnueabihf/4.8.3/../../../../arm-linux-gnueabihf/bin/liblto_plugin.so", R_OK) = -1 ENOENT (No such file or directory)
access("/home/johny/src/MVPSS/linux-buildroot/toolchain_rpi_bcm2708/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/../lib/gcc/arm-linux-gnueabihf/4.8.3/../../../../arm-linux-gnueabihf/bin/arm-linux-gnueabihf/liblto_plugin.so", R_OK) = -1 ENOENT (No such file or directory)
$
Related Stack overflow question and answer here
I was unable to link libbluetooth due to an undefined reference to '__fdelt_chk@GLIBC_2.15'.
I resolved this issue by using a newer release of the Linaro toolchain (6.1.1).
The current Linaro toolchain used by the repository is pretty old (NG-1.13.1-4.8-2014.01 ).
Any thoughts about updating the toolchain used in this repository?
It would be nice to be able to boot a model A from usb, but there may be issues with usbboot/buildroot.elf expecting 512Mb of ram.
The supplied usbboot/buildroot.elf is over 12 months old, and should be updated more frequently to support the latest hardware and kernel features.
VC_BUILD_ID_TIME: Oct 28 2014
EDIT: It is fairly obvious that this should work with the Model A, with the right kernel, but I am currently getting Seven Flashes at boot, for Kernel Not Found, even with an older kernel.
Hi!
Compiling my program for the raspberry pi with this toolchain (arm-bcm2708hardfp-linux-gnueabi-g++) I get this warning:
Warning: swp{b} use is deprecated for this architecture
Any idea what I can do?
Hey, thanks for the updated Toolchain. But there is no gcc4.8.3 available for raspbian and provided gdb version differs from gdbserver. This way remote debugging is no longer possible. When will the new versions be released for raspbian?
Cheers
straight through or crossover?
How to add libusb (to build RPi program which can use device connected to RPi USB port)?
Can libusb be included in this toolset?
What is this loader?
How does it work?
What is it expecting?
What are the text files placed over-top of it?
Having just tried to build toolchain with crosstool-ng on an x86_64 ArchLinux machine, I found that it fails on the step Installing cross-gdb due to the wrong Python being used:
[INFO ] Installing cross-gdb
[ERROR] configure: error: failure running python-config --includes
The error is a syntax difference between Python2 and 3. I could not work out how to configure the toolchain build to use the correct python path. To get around this I disabled the debug tools in the config until I can find the correct solution:
#
# Debug facilities
#
# CT_DEBUG_dmalloc is not set
# CT_DEBUG_duma is not set
#CT_DEBUG_gdb=y
#CT_GDB_CROSS=y
# CT_GDB_CROSS_STATIC is not set
# CT_GDB_CROSS_SIM is not set
#CT_GDB_CROSS_PYTHON=y
#CT_GDB_CROSS_EXTRA_CONFIG_ARRAY=""
# CT_GDB_NATIVE is not set
#CT_GDB_GDBSERVER=y
#CT_GDB_GDBSERVER_STATIC=y
Config used:
https://raw.github.com/raspberrypi/tools/master/configs/bcm2708hardfp-ct-ng.config
Host uname:
Linux 3.6.10-1-ARCH #1 SMP PREEMPT Tue Dec 11 09:40:17 CET 2012 x86_64 GNU/Linux
Hi,
experimenting with usbbootcode, buildroot, etc on pizero trying to get it to boot without sd card.
I find that the libusb_control_transfer function fails on a timeout if the message length is greater than 0x00C0 0000.
Is this the expected behaviour ?
regards
Andy
Hi,
To be able to cross-compile some patched kernels, like with grsecurity, we need the gcc-x.y-plugin-dev (gcc-4.9-plugin-dev by instance).
Is it possible to add it?
Thanks!
undefined reference to `__cxa_throw_bad_array_new_length@CXXABI_1.3.8'
Received this error as other issue suggested to used 4.9.3 cross compiler but i am working in 32-bit enviroment.
By default, mkknlimg doesn't "use warnings;". I was trying to debug what turned out to be a permissions issue, but I noticed that with this added in, the result I get is:
$ sudo mkknlimg --dtok arch/arm/boot/zImage /boot/0/kernel/kernel-3.18.9
Use of uninitialized value $pos in substitution (s///) at /usr/bin/mkknlimg line 229.
Use of uninitialized value $pos in concatenation (.) or string at /usr/bin/mkknlimg line 230.
tail: +: invalid number of bytes
DT: y
Use of uninitialized value in pack at /usr/bin/mkknlimg line 247.
Use of uninitialized value in pack at /usr/bin/mkknlimg line 247.
Use of uninitialized value in pack at /usr/bin/mkknlimg line 247.
Use of uninitialized value in pack at /usr/bin/mkknlimg line 247.
... although it does appear to have worked:
$ knlinfo /boot/0/kernel/kernel-3.18.9
Kernel trailer found at 1973120/0x1e1b80:
KVer: ""
DTOK: true
I'm not sure whether the kernel version not being populated is significant.
Can I use this toolchain to build binaries that will run on both the Raspberry Pi and the BeagleBoard Black? If so, are there any particular compiler options that I should watch out for?
Thanks in advance
when I execute patch -p1 < ../tools/usbboot/buildroot.patch it fails:
$ patch -p1 < ../tools/usbboot/buildroot.patch
patching file board/raspberrypi/usb_test/busybox.config
patching file board/raspberrypi/usb_test/linux.config
patching file board/raspberrypi/usb_test/post_build.sh
patching file configs/raspberrypi_defconfig
Hunk #1 FAILED at 4.
Hunk #2 FAILED at 20.
2 out of 2 hunks FAILED -- saving rejects to file configs/raspberrypi_defconfig.rej
This issue is still not resolved.
I continue to function with an altered linux/i2c-dev.h
As suggested in the earlier discussion, a better solution is to make sure that
/usr/include
is in the search chain before the tool-specific include directories.
Please fix this.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.