tools's People
Forkers
benosteen duduke berte defcom isidresole bilgit mugenken cihanyyt mecury421 trevd zrecore mpapq chrislh p07r0457 jankomuz ygmpkk oxid2178 torros kirtash qrenbor znode martinrunge manhthiep eleree rrsprinkhuizen warriorlious sert00 bazzpi morganlombard machinoid claeslund mamorukotani krom9ra wolfses gintogeorge child-pi raspberrypilinux qrwteyrutiyoup trebonian yyolk clonepig papaxiong85 chelovladimir sntitan greatfruitomsk kentzhang-geek painkiller2008 vinchu sean93park meldundas stonezb narayananms profmobius haihv1983 ivodeconinck gevision imclab rozzied illuminux weijunzhou jeffreyshemmans amogsiddh dxtr felixvocentrix lonkingss bgauthiersii namgk cheaven easonic stevedonovan pvukovic1 lyr316 tbrinthan pierrechicoine zexx86 saumyasbosch mochizuku xthomasbhx tuyj hideo-k rmamba albertov george-gallant tzengys zuoyangithub jinpc0716 kirannevaskar panikrpi kimokono willemwouters clarkchen633 badcop howdo-zhangli robertsmigielski charliejung bmarutha pibox maximus-ms dhucha ben3726tools's Issues
Unable to Link libbluetooth: undefined reference to '__fdelt_chk@GLIBC_2.15'
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?
ld search path for arm cross compilers include host system paths
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.
Windows filesystem doesn't respect capitalization leaving multiple file collisons...
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.
Some GCC errors due to relatively old tools
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.
`
gcc-x.y-plugin-dev required in some "make"
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!
how to connect usb?
straight through or crossover?
Bad developer support / 4.9.3 toolchain for Mac
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!!!!
rpiboot fail to upload buildroot.elf + fatimage when fatimage is larger than a few MB
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.
c++11 compiler specifications
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 ?
Missing license information
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
Cross-compiling problem with target Jessie (using Ubuntu 14.0.4)
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
Toolchain, compatible gcc and gdbserver for raspbian
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
Explans differences between different tool chains
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.)
internal compiler error
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.
Toolchain build fails on ArchLinux host due to Python path
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
arm-linux-gnueabihf-gcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
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)
$
make problem Syntax error: "(" unexpected
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?
Please provide us with a current gcc version + CMake sample for Mac, Linux, Windows
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!
Warning: swp{b} use is deprecated for this architecture
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?
jemalloc on raspberrypi
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.
libusb support
How to add libusb (to build RPi program which can use device connected to RPi USB port)?
Can libusb be included in this toolset?
libusb_control_transfer fails if length > 0x00C00000
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
mkknlimg produces numerous 'Use of uninitialized value' warnings, and doesn't appear to modify kernel images correctly
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 also use this toolchain with the BeagleBoard Black?
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
No README file or documentation included
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?
Cross-compilation and multiarch
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
Document first32k.bin
What is this loader?
How does it work?
What is it expecting?
What are the text files placed over-top of it?
Compile Error when using i2c_smbus_write_i2c_block_data
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.
outdated hardfp cross compiler toolchain for raspbian
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.
4.9 toolchain issue
I was able to cross compile my project successfully for Jessie using the previous gcc-linaro-4.9-2015.02-3-x86_64_arm-linux-gnueabihf toolchain that was added briefly a few days ago. However, with the new replacement 4.9 toolchain arm-rpi-4.9.3-linux-gnueabihf I get this error when calling cmake:
/home/solderspot/pidev/pitools/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/4.9.3/../../../../arm-linux-gnueabihf/bin/ld:
cannot find crt1.o: No such file or directory
Any suggestions as to what the problem is?
Here is the CMAKE_TOOLCHAIN_FILE that works fine for the previousgcc-linaro-4.9-2015.02-3-x86_64_arm-linux-gnueabihf toolchain, as well as gcc-linaro-arm-linux-gnueabihf-raspbian-x64:
SET(CMAKE_SYSTEM_NAME Linux)
SET(CMAKE_SYSTEM_VERSION 1)
SET(DEVROOT $ENV{HOME}/pidev)
SET(PIROOT ${DEVROOT}/piroot)
SET(PITOOLS ${DEVROOT}/pitools)
#SET(TOOLROOT ${PITOOLS}/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64)
SET(TOOLROOT ${PITOOLS}/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf)
# specify the cross compiler
SET(CMAKE_C_COMPILER ${TOOLROOT}/bin/arm-linux-gnueabihf-gcc)
SET(CMAKE_CXX_COMPILER ${TOOLROOT}/bin/arm-linux-gnueabihf-g++)
SET(FLAGS "-Wl,-rpath-link,${PIROOT}/opt/vc/lib -Wl,-rpath-link,${PIROOT}/lib/arm-linux-gnueabihf -Wl,-rpath-link,${PIROOT}/usr/lib/arm-linux-gnueabihf -Wl,-rpath-link,${PIROOT}/usr/local/lib")
UNSET(CMAKE_C_FLAGS CACHE)
UNSET(CMAKE_CXX_FLAGS CACHE)
SET(CMAKE_CXX_FLAGS ${FLAGS} CACHE STRING "" FORCE)
SET(CMAKE_C_FLAGS ${FLAGS} CACHE STRING "" FORCE)
SET(CMAKE_SYSROOT ${PIROOT})
SET(CMAKE_FIND_ROOT_PATH ${PIROOT})
# search for programs in the build host directories
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
# for libraries and headers in the target directories
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
[More details about the project can be found here: https://solderspot.wordpress.com/2016/02/04/cross-compiling-for-raspberry-pi-part-ii/]
Buildroot + toolchain -- kernel too old
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
Usb boot could be updated.
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.
Error with current toolchain (outdated, maybe?)
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:
error Your compiler is too buggy; it is known to miscompile kernels
^
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?
4.9.3 Toolchain for 32 bit.
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.
No longer support for rpi 1?
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!
Please package again amd64 version
It was available but is no more.
Syntax error: ")" unexpected
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 ??
Patch failing
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
-std=c++14 support
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
rpiboot problem
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
Hardcoded libpthread.so.0 path
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.
"/usr/bin/env python2" in mkimage/imagetool-uncompressed.py won't work on most systems
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.
Absolute path in pthread and libc linker scripts break cross-compilation
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 ?
Add Python support to arm-linux-gnueabihf-gdb from linaro toolchain
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.
Toolchain to use on jessie
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?
Is this cross compiler valid for Raspberry Pi 2?
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.
Cross building with CMAKE
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?
Python 2 configure error: "You must get working getaddrinfo() function."
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.
Compile Error when using i2c_smbus_write_i2c_block_data
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
usbboot LIBUSB_LOG_LEVEL_WARNING undeclared
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.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 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.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
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.