I found these instructions How to build a cross compiler for your Raspberry Pi. It is a great walk through using a crosstool-ng tool which simplifies configuring a cross-compiler build A LOT (it has a nice curses-based interface) and it supports GCC 4.7.
I've followed these steps and ended up with a successful build of a 4.7 cross-compiler.
First, we need to install the required prerequisites. I assume you have sudo access.
sudo apt-get install git ncurses-dev make gcc-arm-linux-gnueabi
git is the version control system used by the Linux kernel team.
ncurses is a library for build console menus. It is necessary for menuconfig.
make runs the compilation for us.
At a command prompt, type
to view CPU information.
The ARM11 chips use version 6 of the ARM instruction set, ARMv6. More recent chips from the ARM Cortex range like the Cortex A7, A8 etc all use the ARMv7 instruction set.
All Pi boards are shipped with an ARM11. The options on the second line look like a better fit for building ...
I am eager to get compiling and I would like to use the latest and the best tools.
In fact, the latest and best tools do not need to be built by yourself. On the Raspberry Pi Tool GitHub Repository you will find the X86_64 and x686 toolchains for cross-compiling software.
I recommend using the x86-linux64-cross-arm-linux-hardfp toolchain, as that will ...
These instructions assume you have a working cross-compiler on the slave. Please read How to build a GCC 4.7 toolchain for cross-compiling? if you haven't. It is also useful to have make installed on the master.
First, we must install distcc. We shall use the prebuilt packages supplied by the operating systems' package management systems, but ...
Github user Geoff Flarity has created a raspberry pi specific patch that allows node.js to be compiled for the raspberry pi.
On top of this he includes pre-built binaries for the latest version of node and clear instructions.
You can find this all here https://github.com/gflarity/node_pi
The only problem with hardfloat binaries on softfloat system is application binary interface (ABI) incompatibility. And ABI is about interfacing between libraries. You won't be able to link dynamically to the system libraries if you use wrong ABI. If you provide your own hardfp libraries and configure linker to use them instead of system libraries, there ...
When using Linux kernel, kernel.img file is just a renamed linux/arch/arm/boot/Image. It should also be possible (or at least it was possible last time I checked) to use compressed version of this file - zImage.
It can contain integrated initramfs (ramdisk) but it is not required. For example, stock kernel.img file does not contain ...
to take advantages on the performance
This begs the question that the people who put "an existing OS" together were not concerned about performance, or that you understand it better than them (in which case you would not be asking this kind of question -- I'm not trying to belittle you, just stating the obvious). If people approached their cars the way ...
No, software compiled for hardfp will not work on a softfp system, as the calling conventions are different - the soft float conventions involve passing floats through integer registers (though technically, the kernel isn't the real issue - the problem is the linker and all of the standard libraries). This is why the Raspbian project was such a big ...
Cross-compilation is the process of compiling code for use on one platform on another platform. For example, you can compile software for the Raspberry Pi on a desktop (x86).
In your case, you want to compile software for the Raspberry Pi on the Raspberry Pi - this is normal. Just install gcc and use it as you would on a normal computer. It will default to ...
I want to modify the distro according to my needs. [...] What about
the source for the actual distro? Is it all there? Am I insane?
The distro has sources, but these are either the same as or slightly patched versions of the original sources -- a distro does not really contain any original software per se (discounting the package manager), it is just an ...
What is the difference between kernel "3.18.11" and "3.18.11-v7+"?
The -v7+ is tacked on to indicate this isn't from a vanilla source tree, and that it was compiled specifically for the Pi 2.
I'm planning to get this kernel source: wget https://github.com/raspberrypi/linux/archive/rpi-3.18.y.tar.gz Is this the correct source for my kernel?
No. If you ...
Important: Follow these instructions meticulously
Note: The OP is using Wheezy and the latest kernel version from raspberrypi-bootloader then is 4.1.7-v7+, while on jessie that version is 4.1.13-v7+ and that's a critical difference!
If you're going to apply these steps to your own situation, adjust the values accordingly.
Step 1: Get the git_hash from ...
In short, Yes, they will work. Both repositories use the same upstream code to build their packages.
That is, armhf binaries from armbian will run on an armhf raspbian.
Your problem won't binary compatibility but dependency compatibility. Using a statically linked executable will resolve the dependency compatibility at the expense of binary size.
I think Alex is right but the gcc-arm-linux-gnueabi is compiled for arm cpus without hardware floating point unit. You can find a cross-compiler with armhf support on: https://github.com/raspberrypi/tools
and a good tutorial to start with here: http://hertaville.com/2012/09/28/development-environment-raspberry-pi-cross-compiler/
Note that when building the toolchain using ct-ng on centos 6.3 on a 64 bit system I was forced to deselect the option to statically link libstdc++ because static linking was not supported on the platform (apparently).
Also, while it would be great to use the prebuilt toolchain from the git repository, that chain does not seem to work on Centos 6.3 - ...
The recommended way to build .deb packages targeting Debian or Rasbian is to compile the package on the machine or inside an emulated machine. Thus the recommended way to cross-compile a .deb for Raspberry Pi is to emulate a complete system using qemu on a X86 machine and use it to do the compiles.
It is possible to compile x86_64 code on the Raspberry Pi, and i have just built a cross-compile toolchain on my Pi 2 (with more than 27 hrs of compilation and some hours of bug fixing).
You can directly download it from here: Link
(GCC 4.9.3, built with GCC 4.9.2-10 on Raspbian JESSIE (2015-Nov-21) and crosstool-ng 1.22.0)
Here's how i built my toolchain
Shared or dynamic libraries are needed at run time. So you need the library not only on the build system but in on the target system, in this case on the PI.
This is different from static libraries. If you use a static library at build time, all the needed code from the library would be included in the executable, and the library would not be needed to run ...
The folks at Qucik2Wire agree with your observation regarding security and the need to run any code that accesses the Pi's GPIO pins as root. To address this they have developed a project called gpio-admin which allows non root control of the GPIO pins.
There are some different ways to approach the problem.
A first hacky way to proceed would be to copy the libraries you built on the RPi on your PC and link your software against them.
Another strategy would be to cross-compile OpenCV to have it on your PC. Something like the command you proposed would work. I experimented with cross compiling CMake ...
It might be worth checking in with the QTonPi guys. There's a link to the mailing lists and the IRC channel there.
On linux, you have to configure qtbase appending the following to ./configure
-opengl es2 -device linux-rasp-pi-g++ -device-option CROSS_COMPILE=$CC/bin/arm-linux-gnueabihf
Then, once qtbase is built and you have the new qmake, you use that ...
Theres several seperate but related issues here.
kernel support, the kernel must support vfp so it can correctly save the registers.
compiler FPU use, does the compiler use the FPU
procedure call abi, how are parameters passed to procedures?
binary tagging, is the binary tagged with what ABI it uses and does the OS do anything with that information.
The kernel does not create device files.
The kernel creates and destroys the actual device, but something in userspace - typically either udev or you the sysadmin - must create/remove the device files.
Device files are ultimately just a handle for major/minor number pairs - you can give them any name you like. It's entirely possible to have a device file ...