I want to build Angstrom kernel on Ubuntu 13.04 host machine using OpenEmbedded.
git clone git://github.com/Angstrom-distribution/setup-scripts.git
cd setup-scripts
MACHINE=beagleboard./oebb.sh config beagleboard
MACHINE=beagleboard./oebb.sh update
MACHINE=beagleboard./oebb.sh bitbake virtual/kernel
The reason of building kernel is to be able to cross-compile a kernel driver on host machine, targeting on Angstrom distribution (BeagleBoard). Beagleboard runs a prebuilt image of 2.6.32.
As I know, the cross-compile must target not only the Angstrom distribution, but the same kernel version that BeagleBoard runs. How does OE choose "preferred" version? Is there any way I can choose the kernel version that BitBake will build?
Depending on PREFERRED_PROVIDER_virtual/kernel you choose, you can specify the version
this is an example:
PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
PREFERRED_VERSION_linux-yocto ?= "3.10%"
remember the '%' means that numbers following 3.10 doesn't matter.
another example
PREFERRED_PROVIDER_virtual/kernel ?= "linux-imx"
PREFERRED_VERSION_linux-imx ?= "3.10.2"
Related
I'm using an m1 pro macbook pro.
Up until now, I used intel macbook.
My program is written in c/c++ and the target is ubuntu x86_64.
I tried running ubuntu x86 docker (qemu) and it's super slow - to the point it's unusable.
I have linux ubuntu (arm) installed using parallels and would like to compile for x86 target instead of arm.
How do I do it?
On Ubuntu, I would suggest an apt install gcc-x86-64-linux-gnu g++-x86-64-linux-gnu, and then invoking the installed compiler with the x86-64-linux-gnu prefix (for gcc, x86-64-linux-gnu-gcc) to create x86_64 binaries.
Do note that if you target x86_64 you won't be able to run the programs you build natively, but you should be able to package the binaries created for execution on an x86_64 machine.
Install docker-desktop on your mac and run this docker container with the command:
docker container run --platform=linux/amd64 -it -p 6080:6080 -e WIDTH=1920 -e HEIGHT=1080 yoas1/xubuntu-desktop:1.0
Don't forget to create volume to the code directory.
In your browser go to: http://localhost:6080/vnc.html to access the xubuntu desktop
Image on Dockerhub
I'm trying to build a project (https://wpewebkit.org/) on Debian Buster for armv7 on a x86 host of the same OS.
I am able to successfully install an arm C++ toolchain and I can successfully compile and run trivial applications.
Where I'm stuck is many of the projects I want to compile require many dependencies that I normally install through the OS's package manager (ex apt-get install libjpeg-dev). When cross compiling, it looks like I can just download & make install the sources I need. However, this project has hundreds of dependencies - it would take a long time to download and compile all of them. At the same time, the arm versions of these dependencies already exist in apt for arm.
How can I, on the host system, install the armhf versions of these dependencies and make them available to my cross compiling toolchain? I've tried dpkg add-architecture armhf and then installing via apt-get install libjpeg-dev:armhf but cmake can't seem to find the installed dependencies.
#artless-noise guides were a good jumping off point, but unfortunately most of the guides weren't helpful in accomplishing what I wanted to do (or if they were, they weren't straightforward in explaining how to accomplish what I needed).
What I ended up doing was using qemu-debootstrap
sudo qemu-debootstrap --arch armhf buster /mnt/data/armhf http://deb.debian.org/debian/
And then just using sudo chroot /mnt/data/armhf and I had a functioning shell where I could just apt-get anything I needed, run any scripts and get armhf binaries.
There are many ways to do this. The key concept is that you need a shadow filesystem that mimics the ARM and you need to tell the package build mechanism where they are. There are many distributions variants LTIB is rpm based, Yocto uses BitBake and supports deb, rpm and ipkg. As well you need to differentiate between build tools and deployed binaries. This is an added concept when cross compiling. The only point above is that Ltib, Yocto, buildroot, etc all keep a shadow root files system and some place to keep host/build binaries. Since you have a Debian system, it is best to stick to their tools.
It is possible to install with dpkg --root. And if you have a complete environment, you can chroot arm_root and then build the package there with host binaries but ARM development files (headers and libraries).
The Debian maint-guide is an overview of building debian packages for the normal case. The Debian cross-compile wiki uses the chroot methods and has reference to building with either sbuild or pbuild packages. The schroot package is very nice as it allows you to build the shadow file system without becoming root. It is very easy to destroy your host file system when learning to cross distribution build and I highly recommend this method. Another key difference between the maint-guide and cross wiki is to install the package cross build essentials.
sudo apt-get install build-essential crossbuild-essential-armhf
Otherwise, most everything is the same but building with the chroot shadow ARM filesystem.
Here is a translation for Ubuntu hosts... you need Zenial or better to use the cross-compile debian wiki method. Ie, a Ubuntu x86 Bionic build for raspberry PI or similar. This method takes care of a lot of things for you, especially preventing filesystem corruption by mistake; thank the kind souls at Debian.
The info under nomenclature is quite important,
build means the architecture of the chroot/dpkg/compiler's executable, i.e. the architecture of the build system (called host by cmake/kernel/etc)
host means the architecture of produced executable objects, i.e. the architecture of the host system where these guest objects will run on (called target or sometimes build elsewhere)
target is what the produced executable objects will generate when producing executable objects, i.e. the architecture of the systems the built programs target their results to run on (relevant only for compilers and similar)
People change the names for the same concepts in cross-building and that can be confusing.
Additional info
Kernel cross build
Meson Cross Compilation
Clang cross compile
I'm currently trying to compile a project and port it to a 32bit target deploying a Linux based system.
My host machine runs x86_64 Debian Stretch and my target is an Atmel SAMA5d2 running a custom Linux.
My cross toolchain is generated from buildroot.
At the moment I'm able to cross compile applications for the target using the buildroot generated toolchain. However, I would like to integrate Qt and build Qt apps for the target.
To be able to build my applications for the targetted platform I need to compile Qt for my target.
To do so I have to tell Qt to use the buildroot toolchain instead of the native one.
From what I found I either have to provide -device <device> --device-option CROSS_COMPILE=$TOOLCHAIN_PATH or -xplatform <mkspec> to configure Qt with the expected toolchain.
Obviously my target is not in the device list under qtbase/mkspecs/devices so I think the best solution is to create a mkspec for my target.
My command should look like this :
./configure -xplatform <my_mkspec> -embedded arm -prefix <customQtPath>
However I'm kinda lost and I don't know how to do it only from documentation and what I found by googling my problem.
Also do I need to specify the target is 32bit as armv7 is only 32bits?
I would be glad to have some help on this.
Thanks.
Your assumptions are correct. You can read similar specs and create your own, those are pretty simple. For instance Pi2 is an armv7 device, you can start from this qmake.conf. Then, pass to configure:
-device <given_name> -device-option CROSS_COMPILE=<path_and_prefix> -sysroot <your_sysroot>
just change paths, tune cflags if needed etc... Then follow build tutorials.
Where qmake.conf file is located and how it should look for armhf debian wheezy platform? (BeagleBone Black)
I am trying to follow these steps, but some of them are unreasonable like that one about qmake.
Also what does export PATH=path/to/cross/compiler:$PATH will do?
I enter something like this in path/to/cross/compiler
export PATH=/usr/bin/arm-linux-gnueabihf-g++:$PATH
export PATH=/usr/bin/arm-linux-gnueabihf-g++:$PATH
you should add directory to PATH not path to file, in your case it is /usr/bin,
but because of /usr/bin is already in your PATH you can skip this step.
Where qmake.conf file is located and how it should look for armhf debian wheezy platform?
Look at mkspecs/linux-arm-gnueabi-g++/ in qt source directory, your qmake.conf should looks like it, you can just modify this file to point to your compiler.
After a week of trying to configure arm qt cross-compiler on my Debian 7 Wheezy, I decided to try to follow these steps on Ubuntu 14.04, and everything went as expected! So, don't lose your time playing with Debian Wheezy host machine, try with newest Ubuntu distribution and save your time!
I am compiling an application using the gcc arm cross compiler(arm-eabi-g++). I want to execute the code on the jetson tk1 target. When I copy the executable and run it on the target. I get an error saying -bash: ./Proj: No such file or directory
Should I include any extra conditions while building, inorder to run it on the target?
Can anyone suggest any other cross compiler that works?
It might be differing of system architecture and program architecture.
Look for the architecture of TX1 with command
uname -p
From JetPack v2.2 Jetson TX1 can be installed with aarch64 or armhf architecture
Simpliest way to cross compile is to use arm-linux-gnueabihf-g++ for armhf and aarch64-linux-gnu-g++ for aarch64. You can run armhf programs on aarch64 but you need to install armhf versions of all necessary libraries like libc or libstdc++:
sudo apt-get install libc6-dev:armhf