I am trying to build my own rootfile system for RPI using buildroot.
I am new to buildroot.
I have downloaded following cross compiler folder from git :--
https://github.com/raspberrypi/tools/tree/master/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian
as mentioned in this link :--
http://hertaville.com/2012/09/28/development-environment-raspberry-pi-cross-compiler/
How i will come to know what is the kernel header is used by above cross compiler ?
My installer GCC compiler is :--
arm-linux-gnueabihf-gcc
crosscompiler is downloaded from git at following location:--
~/home/gcc-linaro-arm-linux-gnueabihf-raspbian
Please suggest what value to fill here for toolchain selection :--
Toolchain type : External toolchain
Toolchain : Custom toolchain
Toolchain origin : Pre-installed toolchain
Toolchain path : ?
Toolchain prefix : ?
external Toolchain kernel header series : ?
external toolchain c library : ?
Mention the path of the cross compiler
Also mention the prefix. Since you are using arm-linux-gnueabihf-gcc your prefix is arm-linux-gnueabihf
external toolchain library : eglibc
Related
Advice on working with Buildroot cross compilation would be helpful.
I am currently using customer specific buildroot and trying to cross compile our applications using the provided toolchain. The toolchain provided by customer is in dir [...]/opt/gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf/bin. The toolchain from buildroot is in buildroot/output/host/usr/bin.
Previously I have worked with Yocto Project and in yocto before using cross compilation we need to install the toolchain/sdk which is generated by bitbake -c populate_sdk <image recipe> and then each time we wish to use the toolchain we need to source the environment script. Do we have similar things in buildroot? Do we need to source any environment script? And also do I need to modify anything in menuconfig? Currently the toolchain set in menuconfig is "Linaro ARM 2018.05".
Can anyone please let me know how to continue with Buildroot? My end goal is to cross-compile and generate binaries using this toolchain.
Your help will be much appreciated.
Thanks in advance.
My understanding is that you want to use an external toolchain for building BSP.
In the buildroot menuconfig navigate to Toolchain and use below settings -
Toolchain type - External Toolchain
Toolchain - Custom toolchain
Toolchain origin - Pre-installed Toolchain
Toolchain Path - here you can choose the path [...]/opt/gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf/bin
and make necessary settings for remaining toolchain settings and build.
snapshot
I am using Buildroot 2018.02 for an IMX6 board and the Linaro external toochain 2017.11 based on GCC 2017.11 (GCC 7.2.1)
Now i am adding some debug tools such as gdbserver on the target.
Everything is OK if i use the option "Build cross gdb for the host" and selecting the gdb debugger version 7.11.x for the host along with the gdbserver (BR2_PACKAGE_GDB_SERVER) in the "Target Packages > Debugging,.." menu. There are also other version of gdb available in Buildroot such as 7.12.x and 8.0.x.
However, for an external toolchain the recommended way is :
https://github.com/mbats/eclipse-buildroot-bundle/wiki/Tutorial-:-How-to-debug-a-remote-application-%3F which means to activate only the "Copy gdb server to the Target" option in Buildroot (although the post is a bit old)
I have noticed that the BR2_TOOLCHAIN_EXTERNAL_LINARO_ARM description says that Linaro gdb is based on gdb 8.0 so a newer version that the one i am using (7.11.x).
But when i do that, i have the following message on the target board :
# gdbserver
-sh: gdbserver: not found
despite the following :
# which gdbserver
/usr/bin/gdbserver
gdbserver binary is on the target.
How to fix this in Buildroot ?
Moreover i have two additional questions :
Does it really matter to have the Linaro toolchain gdb instead of
the gdb 7.11.x that works "out of the box" in my case ?
If i don't use the Linaro gdb then should i use the gdb version
8.0.x ( because the Linaro version is based on the 8.0 of GDB ) ?
Thank you for your help.
The gdbserver binary in the Linaro 2017.11 toolchain is broken: it requests /usr/lib/ld.so.1 as the program interpreter (see below), but that program interpreter doesn't exist.
You can try to create a symlink /usr/lib/ld.so.1 -> /lib/ld-linux-armhf.so.3 (add that to your filesystem overlay if it works). Alternatively, you can specify the program interpreter explicitly by putting it before the executable, i.e. /lib/ld-linux-armhf.so.3 /usr/bin/gdbserver.
The "program interpreter" is a parameter of an ELF file that points to a program that is used to load the ELF file into memory and to start executing it. The main responsibility of the program interpreter is to find and load the dynamic libraries that the program needs. Thus, it is usually called the "dynamic library loader", or ld.so. It is built and installed together with the toolchain - specifically, the standard C library (glibc). When a program is linked, the linker will also set the program interpreter (it is copied from libc.so). Apparently Linaro did something really peculiar to end up with a wrong program interpreter in the gdbserver executable.
# gdbserver
-sh: gdbserver: not found
depsite the following :
# which gdbserver
/usr/bin/gdbserver
Most likely:
The gdbserver is a dynamically linked binary, and
The ELF interpreter that this binary is linked to use is not present on the target system.
Use readelf -l /usr/bin/gdbserver | grep -i interpreter to find out what runtime loader this gdbserver requires. Verify that that file is not present on the target. Copy it to the target and enjoy.
I'm trying to compile a shared library with cmake to use it further with the "dlfcn" lib in a C program. I am on Windows with Cygwin, but I don't know how to use "dlfcn" with the shared libraries of windows (.dll and .dll.a) and my teammates are using Linux. So I would like to create not .dll and .dll.a libraires but a .so library. I'm a beginner with cmake, is there a possibility to do it or am I obliged to install a Linux VM ?
So, thanks to #Florian, I finally made it. To the ones who want to know how it works, it's quite simple :
Create a new .cmake file :
# this mandatory command will be the one that will make your cross-compiling work
set(CMAKE_SYSTEM_NAME Linux)
# indicate compilers (optional)
set(CMAKE_C_COMPILER gcc)
set(CMAKE_CXX_COMPILER g++)
When calling your cmake command, add an argument like this :
cmake -DCMAKE_TOOLCHAIN_FILE=./myToolChainFile.cmake ..
I got a cross compiled rootfs in ${ARMHOST} which I previously created via buildroot for a armv5te/ARM9 (ARM926t core also known as ARM926ej-s) target trying to use the CodeLite toolchain
waf distclean
ARMHOST="${HOME}/buildroot-2013.08/output/host";
export PKG_CONFIG_PATH="${ARMHOST}/usr/lib/pkgconffg/";
export CC="${ARMHOST}/opt/ext-toolchain/arm-none-linux-gnueabi/bin/gcc";
export AR="${ARMHOST}/opt/ext-toolchain/arm-none-linux-gnueabi/bin/ar";
export CROSS_COMPILE="/usr/bin/arm-none-eabi-";
export CFLAGS="-march=armv5te -I${ARMHOST}/usr/include/ -I${ARMHOST}/opt/ext-toolchain/arm-none-linux-gnueabi/include/";
export LDFLAGS="-L${ARMHOST}/usr/lib/";
waf configure debug
Resulting in
'distclean' finished successfully (0.000s)
Setting top to : ~/Desktop/myapp
Setting out to : ~/Desktop/myapp/build
Checking for 'gcc' (c compiler) : not found
Checking for 'icc' (c compiler) : not found
could not configure a c compiler!
(complete log in ~/Desktop/myapp/build/config.log)
The wscript uses context.load('compiler_c gnu_dirs glib2') in each stage to load features.
Update #1 - if I replace compiler_c by gcc then I endup with:
CC="${ARMHOST}/opt/ext-toolchain/arm-none-linux-gneabi/bin/gcc" AR="${ARMHOST}/opt/ext-toolchain/arm-none-linux-gnueabi/bin/ar" ./waf configure
Setting top to : ~/myapp
Setting out to : ~/myapp/build
Checking for program gcc,cc : ${ARMHOST}/opt/ext-toolchain/arm-none-linux-gnueabi/bin/gcc
Could not determine the compiler type
So how can I tell waf that this compiler is gcc based? (code sourcery lite 2013 toolchain)
Do I have to create a new compiler profile or is there an easier way?
Do not use .../host/opt/ext-toolchain/arm-none-linux-gnueabi/bin/gcc but .../host/opt/ext-toolchain/bin/arm-none-linux-gnueabi-gcc - gcc detection is obviously done by some voodoo
I am trying to insert a .ko kernel module into the linux running in arm processor. I built a .ko file in my desk PC which is a x86 one. How do I cross compile it to arm specs. I am new to this field.
Thanks in advance
For that you need to download the ARM compilers first. I suggest you download the compiler from http://www.linaro.org/downloads/ then set the CROSS_COMPILE environment variable to arm-linux-gcc.
set the bin directory path in PATH variable.You can do it by export PATH=$PATH:/path/to/arm/binaries/
Finally compile the code then run in ARM.
use file <filename> whether it is ARM executable or not.
For this you have to do the following steps.
Check you have cross compiler tool chain or not.
If you don't have cross compiler tool chain
you can download from one of the free ARM cross compiler from net.
You can generate your own cross tool chain using Buildroot tool. below you can get the link of Buildroot user manual.
http://buildroot.uclibc.org/downloads/manual/manual.html#_using_buildroot
Install cross tool chain in your host PC.
Export the cross tool chain path in your host PC using export command.
Change the make file of the kernel module to set the compiler as CROSS_COMPILE.
Do make.
Move the .ko file to target and insert it.