I am using Buildroot (2017.02.5) to build a custom cross compilation toolchain. I have two buildroot configurations; one to build the RFS and one purely to build a toolchain. I have things configured this way because I don't want the toolchain to be rebuilt unless I intentionally rebuild it- the configuration which builds the RFS references this toolchain as an external toolchain.
Generally, the built toolchain works fine, but I have some existing applications (Linux userspace) which #include's <openssl/md5.h>. When I try to compile this, I get a "<openssl/md5.h>: No such file or directory" error, which is expected because the sysroot dir of the generated toolchain does not contain an openssl directory.
How can I make buildroot include openssl in the toolchain? All searches I have done seem to point to cross compiling openssl for my embedded target, which is not an issue. The issue is that I need to include it in the toolchain.
I have Target packages --> Libraries --> Crypto --> openssl set to y, but I don't think this makes any difference in this scenario since I believe it relates only to the RFS (and the defconfig in question does not build an RFS, only a toolchain).
I could compile OpenSSL outside of the buildroot tree and install it to the sysroot dir, but this doesn't seem correct as it would pollute sysroot.
I'm sure I'm missing something simple here- any help would be appreciated.
After some further reading of the buildroot documentation (which is very good), I figured that packages selected under Target packages do in fact get pushed into the sysroot of the toolchain (or are supposed to at least) which would make sense. The reason this didn't appear to be working was because I was doing a make toolchain as opposed to make all (or just a simple make). The packages didn't get built with the former, so they weren't in the sysroot of the toolchain.
Related
I'd like our product's builds to use a more recent version of Clang/LLVM than what is available in our distribution's package manager. I built it from source, making sure to include libc++, libc++abi, compiler-rt, clang, and lld. When configuring the project, I used -DCMAKE_INSTALL_PREFIX=/some/folder/under/my/repo.
After building, I ninja installed it. When I try to compile a file using this version of clang, and passing --sysroot /some/folder/under/my/repo, it is able to find libc++ and libc headers, but not system headers. For example, the first file that it can't find is features.h, which is under /usr/include and is not part of LLVM.
I tried symlinking a few of these and was planning to check in the symlinks, but eventually I reasoned with myself "Why bother, I can just -I/usr/include, because the sysroot would take priority anyway."
But even this is not enough. I next encountered sys/cdefs.h. This file is actually under /usr/include/x86_64-linux-gnu/sys/cdefs.h, so even a -I/usr/include isn't sufficient.
I can certainly keep going down this path and copying/symlinking every single dependency from /usr/include over to my new sysroot, but I can't help but think I'm going about this all wrong. That said, asking every engineer in the company to build clang from source and install it to /usr is a non-starter. Is there any way to check in binaries into a repo, have the build pull the compiler, headers, libs, etc straight out of the repo, but still pull non-LLVM system headers from /usr/include?
I want to install and build just the toolchain for my Buildroot project. make help suggests that the command make <options> toolchain should work; however, running that command simply returns Nothing to be done for 'toolchain'. and output/host is never created.
You first have to configure Buildroot in order to instruct it about what toolchain you want to produce. See Buildroot quick start in the Buildroot user manual.
If you just downloaded Buildroot, the steps to produce a toolchain are:
run make menuconfig
In Target options select your hardware platform and ABI
In Toolchain configure the kind of toolchain you want
exit saving
run make toolchain
The toolchain is in output/host/.
A more recent way to build just the toolchain, which can be used both within and outside of Buildroot, is documented in the Buildroot manual.
Though make toolchain in Luca's answer does build the toolchain, it also places other host dependencies into output/host/, making it slightly more difficult to get a clean toolchain as compared to make sdk below, which produces a toolchain tarball in output/images/:
6.1.3. Build an external toolchain with Buildroot
The Buildroot internal toolchain option can be used to create an external toolchain. Here are a series of steps to build an internal toolchain and package it up for reuse by Buildroot itself (or other projects).
Create a new Buildroot configuration, with the following details:
Select the appropriate Target options for your target CPU architecture
In the Toolchain menu, keep the default of Buildroot toolchain for Toolchain type, and configure your toolchain as desired
In the System configuration menu, select None as the Init system and none as /bin/sh
In the Target packages menu, disable BusyBox
In the Filesystem images menu, disable tar the root filesystem
Then, we can trigger the build, and also ask Buildroot to generate a SDK. This will conveniently generate for us a tarball which contains our toolchain:
make sdk
This produces the SDK tarball in $(O)/images, with a name similar to arm-buildroot-linux-uclibcgnueabi_sdk-buildroot.tar.gz. Save this tarball, as it is now the toolchain that you can re-use as an external toolchain in other Buildroot projects.
I am having difficulties with cross compiling stunnel for an ARM device.
Cross compiling OpenSSL was done via this CMake project: http://www.valvers.com/open-software/projects/openssl-cmake/ and it runs successfully on the target device.
The CMake toolchain file I use when compiling OpenSSL:
SET(CMAKE_SYSTEM_NAME Linux)
SET(CMAKE_C_COMPILER /home/elias/toolchains/axotec/3.4.1/bin/arm-linux-gcc)
SET(CMAKE_CXX_COMPILER /home/elias/toolchains/axotec/3.4.1/bin/arm-linux-g++)
SET(CMAKE_FIND_ROOT_PATH /home/elias/toolchains/axotec/3.4.1/arm-linux /home/elias/toolchains/axotec/3.4.1/library-for-ramdisk )
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
My question is how do I cross compile stunnel in a similar fashion? I'm struggling with passing stunnel makefile the whole sysroot dir just like in the cmake toolchain file SET(CMAKE_FIND_ROOT_PATH /home/elias/toolchains/axotec/3.4.1/arm-linux /home/elias/toolchains/axotec/3.4.1/library-for-ramdisk )
My atempts include, after running the configure, rewriting the makefile CFLAGS with --sysroot= but where to put the second folder?(library-for-arm)
General idea:
The openssl-cmake project uses CMake build infrastructure. Hence just specifying the toolchain worked for you. I looked at stunnel source code and they use the traditional GNU Autotools for the build infrastructure which means you cannot use cmake directly on that project. (./configure && make && make install)
You would have to use ExternalProject_Add to compile stunnel using cmake.
Take a look at the following links for more information.
http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html
http://www.cmake.org/cmake/help/v3.2/module/ExternalProject.html
Also this:
Pass parameter with spaces to CMake ExternalProject_Add BUILD_COMMAND
CMakeLists.txt
cmake_minimum_required (VERSION 3.2)
include(ExternalProject)
set(CROSS_INFO CC=${CMAKE_C_COMPILER} CXX=${CMAKE_CXX_COMPILER} AR=${CMAKE_AR})
ExternalProject_Add(
stunnel
URL http://www.stunnel.org/downloads/stunnel-5.17.tar.gz
CONFIGURE_COMMAND <SOURCE_DIR>/configure --host=powerpc --with-sysroot=${CMAKE_FIND_ROOT_PATH} ${CROSS_INFO}
)
Additional info:
I tried to run the above project locally on my system and I ended up spending an hour debugging it with the powerpc toolchain file I have. There is some problem with the configure script of stunnel. The way sysroot and with-ssl dir are being calculated is kind of not correct. You might have to mess with the configure file to get the cross compile to work. But the general idea is specified above.
I got a little confused when it comes to QT and cross compiling
appliations for my arm-linux:
So far I have a linux running on my AT91SAM9263-EK and an appropriate
filessystem including QT libs build via buildroot.
Also I have build QT-4.8 on my ubuntu.
Now I want to build an example application:
I created a makefile in an examples folder in QT on my ubuntu using
qmake; I used the given qmake.conf in mkspecs/qws/linux-arm-g++.
when executing make I get an error because it includes qatomic_i386.h
and the message "error: impossible constraint in 'asm'".
this header file does obviously not match to my arm toolchain.
my question:
how to configure Qt on my ubuntu to build Qt binaries for my embedded linux
on arm? Do I need to include any libs build by the arm toolchain?
any help is appreciated!
regards
EDIT:
I use the -spec flag and pass the path to "mkspecs/qws/arm-linux-g++" where a "qmake.conf" is located. I did not change anything in here because I dont know wich qmake variable are relevant to link to my arm related libs.
So the right compiler is used, which I could verify when the make process starts. But I observed that in a config file called qconfig.h there is an ARCH flag which is set to i386 but I didnt figure out how one can configure this. I dont think I should manually edit this file.
EDIT2:
someone knows whats behind the file qconfig.h?? should I adjust it manually?
I will solve it by myself :)
After struggling a while and scanning the web I got a little deeper involved how everything works together. I did not understand how to generate an executable for my ARM target device. I figured out two things:
do not add your QT path for X11 at the beginning in your PATH variable. this might mess up your cross compilation.
edit the qmake.conf correspondingly. add your libs build for the target device which in my case are located within buildroot. Add theses lines to your qmake.conf file:
QMAKE_CFLAGS += -O3 -march=armv5te
QMAKE_CXXFLAGS += -O3 -march=armv5te
QMAKE_INCDIR_QT = /home/user/arm/toolchain/buildroot-2010.11/output/staging/usr/include
QMAKE_LIBDIR_QT = /home/user/arm/toolchain/buildroot-2010.11/output/staging/usr/lib
I got it running now. thanks to everyone!
Yes, either you provide the Qt libraries in your toolchain or you tell qmake where to find them. Also, I suspect you're calling qmake without the -spec parameters. If you are using the qmake you find in your distribution, it will use the default spec, which is not arm I guess. Add the -spec parameter and point it to the arm mkspec. Also, make sure the generated g++ commands link to the correct Qt libs compiled for arm.
You shall install QtSDK for embedded linux befor you use it to build your application. I'm afraid you just have QtSDK for x86 right now. After QtSDK for embedded linux installed, it has qws/linux-arm-g++ as the default mkspace typically. If you don't have QtSDK for embedded linux, you can build it from source. Then run qmake to create Makefile for you application.
$QTDIR_FOR_ARM/qmake
Reference:
Installing Qt for Embedded Linux and Cross-Compiling Qt for Embedded Linux Applications
Good day
Currently, I'm working on an embedded device based on arm-linux. I want to build GCC for my target architecture with Glibc. GCC builds successful, but I have trouble with Glibc build.
I use the latest version of Glibc (ftp.gnu.org/gnu/glibc/glibc-2.12.1.tar.gz) and port for them (ftp.gnu.org/gnu/glibc/glibc-ports-2.12.1.tar.gz)
my configuration line:
../../glibc-2.12.1/configure --host=arm-none-linux-gnueabi --prefix=/home/anatoly/Desktop/ARM/build/glibc-build --enable-add-ons --with-binutils=/home/anatoly/Desctop/ARM/toolchain/arm/bin/
configuration script work fine, but i get some compile error:
...
/home/anatoly/Desktop/ARM/src/glibc-2.12.1/malloc/libmemusage_pic.a(memusage.os): In function me':
/home/anatoly/Desktop/ARM/src/glibc-2.12.1/malloc/lmemusage.c:253: undefined reference to__eabi+read_tp'
...
I also tried using the old version (2.11, 2.10) but have the same error.
Does anybody know the solution for this problem?
Use a precompiled toolchain, like those provided by code sourcery.
If you want to make your own, optimised (premature optimization is the root of all evil), use crosstool-NG, which is a tool dedicated to cross-compilation toolchain building.
If you are not convinced, and want to do everything with your own hands, ask your question on the crosstool-NG mailing list.
Try substituting arm-linux-gnueabi for arm-none-linux-gnueabi. Check that a compiler, loader etc. with the prefix you used for "host" exist on your path.