Problems cross compiling Qt 4.7 from source for ARM - c++

I'm trying to cross-compile Qt 4.7.1 from source, here are some notes on my setup:
my expected output is the shared object libraries that are required to be present in order to run a Qt application.
My target platform is a TI AM335x processor which is of the ARM Cortex-A8 architecture.
My development platform is a x86 64-bit Ubuntu virtual machine
My understanding of how this should work is that I download the toolchain for my target platform (this is the Linaro toolchain from TI), I download the source code for Qt 4.7.1, I set the mkspec to use my tool chain, run configure, then just need to run make/make install and I should be able to find all the .so's where I told it to install to. I'm having a lot of problems getting this idea to work however.
First I downloaded the TI SDK version: ti-sdk-am335x-evm-06.00.00.00 which has the arm tool's at:
[root_install_dir]/linux-devkit/sysroots/i686-arago-linux/usr/bin
I updated my $PATH with that directory:
mike#mike-VirtualBox:~$ echo $PATH
/home/mike/ti-sdk-am335x-evm-06.00.00.00/linux-devkit/sysroots/i686-arago-linux/usr/bin
:/usr/local/Trolltech/Qt-4.8.5/bin:/home/mike/bin:/usr/lib/lightdm/lightdm:
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/mike/bin
I then created my own mkspec based on the closest example:
cp -R [qt_install_dir]/mkspecs/qws/linux-arm-gnueabi-g++/ [qt_install_dir]/mkspecs/qws/linux-am335x-g++
and I modified the linux-am335x-g++/qmake.conf to point to the tools from the TI sdk:
# modifications to g++.conf
QMAKE_CC = arm-linux-gnueabihf-gcc
QMAKE_CXX = arm-linux-gnueabihf-g++
QMAKE_LINK = arm-linux-gnueabihf-g++
QMAKE_LINK_SHLIB = arm-linux-gnueabihf-g++
# modifications to linux.conf
QMAKE_AR = arm-linux-gnueabihf-ar cqs
QMAKE_OBJCOPY = arm-linux-gnueabihf-objcopy
QMAKE_STRIP = arm-linux-gnueabihf-strip
Then I ran a configure command:
./configure -prefix /home/mike/qt4.7.1_source/my_qt -embedded arm -platform qws/linux-x86_64-g++ -xplatform qws/linux-am335x-g++ -no-mmx -no-3dnow -no-sse -no-sse2 -no-glib -no-cups -no-largefile -no-accessibility -no-openssl -no-gtkstyle -fast -opensource
It runs for a while then completes and says it's ready to do make/make install at this point I run make and that's where it starts to fail:
/home/mike/qt4.7.1_source/qt-everywhere-opensource-src-4.7.1/bin/moc
-DQT_SHARED -DQT_BUILD_CORE_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_USE_FAST_OPERATOR_PLUS -DQT_USE_FAST_CONCATENATION -DELF_INTERPRETER=\"/lib64/ld-linux-x86-64.so.2\" -DHB_EXPORT=Q_CORE_EXPORT -DQT_HAVE_NEON -DQT_NO_DEBUG -I../../mkspecs/qws/linux-am335x-g++ -I. -I../../include -I../../include/QtCore -I.rcc/release-shared-emb-arm -Iglobal -I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4 -I.moc/release-shared-emb-arm kernel/qobject.h -o .moc/release-shared-emb-arm/moc_qobject.cpp arm-linux-gnueabihf-g++ -c
-include .pch/release-shared-emb-arm/QtCore -pipe -fno-exceptions -mfpu=neon -O2 -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -D_REENTRANT -fPIC -DQT_SHARED -DQT_BUILD_CORE_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_USE_FAST_OPERATOR_PLUS -DQT_USE_FAST_CONCATENATION -DELF_INTERPRETER=\"/lib64/ld-linux-x86-64.so.2\" -DHB_EXPORT=Q_CORE_EXPORT -DQT_HAVE_NEON -DQT_NO_DEBUG -I../../mkspecs/qws/linux-am335x-g++ -I. -I../../include -I../../include/QtCore -I.rcc/release-shared-emb-arm -Iglobal -I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4 -I.moc/release-shared-emb-arm -o .obj/release-shared-emb-arm/qobject.o kernel/qobject.cpp {standard input}: Assembler messages:
{standard input}:1294: Error: selected processor does not support Thumb mode 'swp r6,r4,[r3]'
make[1]: [.obj/release-shared-emb-arm/qobject.o] Error 1* make[1]: Leaving directory
'/home/mike/qt4.7.1_source/qt-everywhere-opensource-src-4.7.1/src/corelib'
make: * [sub-corelib-make_default-ordered] Error 2
So, the question...
Why is the compiler complaining that the thumb mode is not supported? Since this is a cross compile tool chain for an ARM based processor, it should be supported. The fact that it's not makes me feel that make is somehow picking up the wrong version of g++.
Any thoughts on what went wrong and how to fix this?

{standard input}:1294: Error: selected processor does not support Thumb mode 'swp r6,r4,[r3]'
Why is the compiler complaining that the thumb mode is not supported?
Note, the compiler is complaining about the swp instruction not being available for thumb mode. Your CPU supports thumb, thumb2, and ARM. The Cortex series deprecates the use of swp and prefers ldrex/strex pairs.
Any thoughts on what went wrong and how to fix this?
You need to get gcc to define __ARM_ARCH_7__; this is done with either -mcpu=cortex-a8 or the combination -mtune=cortex-a8 and -march=armv7-a or what ever you like depending on how many types of boards you want Qt to run on.
In detail, see qatomic_arm.h for where a sub-file is selected. You have a very generic ARM selected (I guess), so you get qatomic_armv5.hNote1 where you can see the code around line 125. The right file for your CPU is qatomic_armv7.h, which mainly just includes qatomic_armv6.h. In this file you can find ldrex/strex which is the wholesome goodness that your gcc is requesting.
I also suggest you do not compile with -fast. There is another question where the OP says this solved his issue; but I think this is different.
You can try to pass -armfpa to configure. ./configure -embedded arm --help is useful. configure appears to have selected NEON, so it seems to know you have a more advanced CPU (there is no NEON on an armv5, but this maybe a fault of configure).
For certain, you don't want the swp code and the ldrex/strex is preferred for your system, even if swp could somehow work. I would at least resolve this. Alter the -xplatform qws/linux-am335x-g++ to update -mcpu or possibly pass an explicit -D__ARM_ARCH_7__. You can get a list of defines with arm-gcc -mcpu=cortex-a8 -dM -E - < /dev/null, to verify that the __ARM_ARCH_7__ is being defined. It looks like it is moc failing, so maybe the -D__ARM_ARCH_7_ solution will be needed.
You might also try to alter -mthumb in the compiler option. It is probably best to use -mcpu=cortex-a8 and -mthumb for your system, if you can get that to compile/build. Omitting -mthumb will make the code slightly larger. You might also try -Os. For some reason, I have huge builds with other optimizations and more recent gcc versions. It appears to be due to some C++ feature as normal 'C' doesn't behave this way; but this may just be my compiler. I looked and believe it is the exception tables, but I never confirmed anything and moved on. I am sure you are aware of how long Qt takes to compile.
Note1: The qatomic_armv5.h code is fairly confused and newer gcc or binutils will choke even when this is the correct file to use.
asm volatile("swpb %0,%2,[%3]"
: "=&r"(ret), "=m" (*ptr)
: "r"(newval), "r"(ptr)
: "cc", "memory");
This specifies some inline assembler parameters which are never used. Not to mention the condition codes are not used, etc.
asm volatile("swpb %0,%1,[%2]"
: "=r"(ret)
: "0"(newval), "r"(ptr)
: "memory");
will compile with newer gcc and binutils. It also uses less registers and is optimal for the way Qt is currently using it; there maybe cases where ret needs to be preserved to compare to newval but it is just a user space spin lock currently.
The bracket [x] is a memory operand register and must be different than the other two parameters for a valid swp. I believe the first form was used to stop %0 from being the same as %3. The 2nd form avoids this by making %0 and %1 the same, so %2 must be different.

the answer by usr: artless noise did in fact fix my issue, but since I want to make sure there is a very clear trail for myself (if needed) or others, I want to state exactly what the fix was:
First, I updated my .configure command to:
./configure -prefix /home/mike/qt4.7.1_source/my_qt -embedded arm -platform qws/linux-x86_64-g++ -xplatform qws/linux-am335x-g++ -no-mmx -no-3dnow -no-sse -no-sse2 -no-glib -no-cups -no-largefile -no-accessibility -no-openssl -no-gtkstyle -opensource -qt-mouse-tslib
The only difference from the question's configure command is the removal of the -fast option.
Then in my the linux-am335x-g++/qmake.conf file, I added a few command line options:
QMAKE_CFLAGS= -march=armv7-a -marm -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a8
QMAKE_CXXFLAGS= -march=armv7-a -marm -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a8
With these two change I can now see everything build and install Qt4.7.1 successfully.
I also tried Qt4.8.5 and everything works the same except one more option has to be added to the ./configure command:
-no-pch
This is to avoid an error regarding a: .pch
directory and files in side showing "No such file or directory"

Related

Controlling scons environment checking options

I'm trying to build mongodb (open source version 4.2) which uses python and scons for building. The problem relates to scons rather than mongodb.
My build fails very early with Couldn't find OpenSSL crypto.h header and library. Verbose details are:
file /.../SConstruct,line 3042:
Configure(confdir = build/scons/opt/sconf_temp)
scons: Configure: Checking for SSLeay_version(0) in C library crypto...
build/scons/opt/sconf_temp/conftest_d6743137aeb7fb2674cc9632f9989034_0.c <-
|
|
|#include "openssl/crypto.h"
|
|int
|main() {
| SSLeay_version(0);
|return 0;
|}
|
gcc -o build/scons/opt/sconf_temp/conftest_d6743137aeb7fb2674cc9632f9989034_0.o -c -std=c11 -ffp-contract=off -fno-omit-frame-pointer -fno-strict-aliasing -ggdb -pthread -Wall -Wsign-compare -Wno-unknown-pragmas -Winvalid-pch -Werror -O2 -Wno-unused-local-typedefs -Wno-unused-function -Wno-deprecated-declarations -Wno-unused-const-variable -Wno-unused-but-set-variable -Wno-missing-braces -Wno-exceptions -fstack-protector-strong -fno-builtin-memcmp -fPIE -DNDEBUG -D_XOPEN_SOURCE=700 -D_GNU_SOURCE build/scons/opt/sconf_temp/conftest_d6743137aeb7fb2674cc9632f9989034_0.c
cc1: error: command-line option '-Wno-exceptions' is valid for C++/ObjC++ but not for C [-Werror]
cc1: all warnings being treated as errors
scons: Configure: no
I'm using Arch Linux which has multiple OpenSSL packages, and the default 3.0 is not compatible with mongodb source. I also have OpenSSL 1.1 and 1.0 installed, and can switch with e.g. gcc -I/usr/include/openssl-1.1.
Unfortunately I have not found a way to instruct SConstruct to use this flag in the command lines it generates to check the environment. I have tried CFLAGS, CCFLAGS, CPPPATH both as environment variables and scons command line parameters.
I also tried reverse enginering it, and tracked this to Conftest and TryBuild but it's not obvious how I can influance theses from the command line, so I'm trying my luck with you guys before going deeper in scons code.
If you look at the SConstruct and search for openssl, you'll find this blurb under the logic to detect on macOS
NOTE: Recent versions of macOS no longer ship headers for the system OpenSSL libraries.
NOTE: Either build without the --ssl flag, or describe how to find OpenSSL.
NOTE: Set the include path for the OpenSSL headers with the CPPPATH SCons variable.
NOTE: Set the library path for OpenSSL libraries with the LIBPATH SCons variable.
NOTE: If you are using HomeBrew, and have installed OpenSSL, this might look like:
\tscons CPPPATH=/usr/local/opt/openssl/include LIBPATH=/usr/local/opt/openssl/lib ...
NOTE: Consult the output of 'brew info openssl' for details on the correct paths."""
I'd bet if you did the same but pointed at the proper locations on your system for the openssl libs and header files, you'd be able to build.
(see: https://github.com/mongodb/mongo/blob/r4.2.0/SConstruct#L3015 )

g++ arm-none-eabi upgrade from 4.9 to gcc 8.2. Generated binary do not fit any more in flash

I recently updated my Linux laptop from Ubuntu 16.04 to 18.04.
I had a STM32 (Cortex-M4) Makefile based project that compiled correctly with the arm-none-eabi g++ version provided by Ubuntu. The generated file required 47620 bytes in the .text section.
With the Ubuntu upgrade, I have also installed an up-to-date version of gcc (from ARM website). Version is 8.2.1.
When I compile the same project (make clean && make), the generated binary do not fit in flash (97424 bytes required, more than twice!). The project is exactly the same (sources, link script, startup files, Makefile).
The compiler options are: -mthumb -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -DSTM32F303x8 -DARMCM4 -O0 -g -Wall -fexceptions -Wno-deprecated.
The linker options are -mthumb -mcpu=cortex-m4 -Tstm32f303K8.ld -mfloat-abi=hard -mfpu=fpv4-sp-d16 --specs=nosys.specs -lm -Wl,--start-group -lm -Wl,--end-group -Wl,--gc-sections -Lsys -Xlinker -Map=test.elf.map
When I look at the .Map generated file, all the user functions take approximatively the same size (new version saves 8 bytes!). But after, it includes C++ sepcific parts, and one is more than 26Kb (from map file):
.text 0x00000000080079e8 0x683c /usr/local/gcc-arm-none-eabi-8-2018-q4-major/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libstdc++.a(cp-demangle.o)
0x000000000800e13c __cxa_demangle
Note: there is no problem with C only projects, only with C++. The library included are the same (gcc 4.9.3 -> armv7e-m/fpu, and gcc 8.2.1 -> thumb/v7e-m+fp/hard):
libm.a libstdc++.a libc.a libnosys.a libgcc.a
Is there a way to get rid of that so that I can compile and flash my (no so old) project?
regards,
I found a solution using the libstdc++_nano (instead of implicit libstc++). With that, the code size is reduced from 84kb to 26kb!
LDFLAGS += -lstdc++_nano
It just works. Thanks #Henrik, #Matthieu and #EOF for your support!
It might be related to exception handling, as std::terminate(), which is used with exceptions, might call the demangling routine. If you don't need exceptions then try disabling them with -fno-exceptions as described here.
Another solution might be to look at the GCC headers:
Demangling routine.
ABI-mandated entry point in the C++ runtime library for demangling.
[...]
returns a pointer to the start of the NUL-terminated demangled
name, or NULL if the demangling fails. The caller is
responsible for deallocating this memory using free.
The prototype is:
char*
__cxa_demangle(const char* __mangled_name, char* __output_buffer,
size_t* __length, int* __status);
So you could probably just supply your own dummy function returning NULL (Given that all library functions are weak, and can be overridden). I'll advise you to look at the disassembled code first though, and find out how and why it is being called in the first place, since it might change behaviour to just discard functionality).
They also give other advise in This forum post, which might be useful for you as well:
Optimize for size with -Os instead of -O0 (possibly add the -Og option instead, if you prefer easily debuggable code, it is often both smaller and faster than -O0).
Optimize at link-time with -flto while compiling and linking.
Maybe disable RTTI if not used.

Unable to cross compile Linux openGL program with mingw32. Config.log error: undefined reference to `_glEnable'

I am attempting to cross-compile an OpenGL program using Mingw32 but have run into a road block. After invoking mingw32-configure; the compilation is interrupted by
configure: error: lacking proper OpenGL support
I checked the config.log file and found the following entries:
configure:21709: checking GL/gl.h usability
configure:21726: ccache i686-pc-mingw32-g++ -c -O2 -g -pipe -Wall -,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -mms-bitfields conftest.cpp >&5
configure:21732: $? = 0
configure:21746: result: yes
configure:21750: checking GL/gl.h presence
configure:21765: ccache i686-pc-mingw32-g++ -E conftest.cpp
configure:21771: $? = 0
configure:21785: result: yes
configure:21813: checking for GL/gl.h
configure:21820: result: yes
configure:21834: checking for glEnable in -lGL
configure:21869: ccache i686-pc-mingw32-g++ -o conftest.exe -O2 -g -pipe - Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -mms- bitfields conftest.cpp -lGL >&5
/tmp/ccjGmlvX.o: In function 'main':../rpmbuild/SOURCES/poker3d-1.1.36/conftest.cpp:34: undefined reference to `_glEnable'
collect2: ld returned 1 exit status
configure:21875: $? = 1
configure: failed program was:
| /* confdefs.h. */
I have added the llvm software rasterizer to my system after a suggestion on this website from another thread related to this problem and have also implemented a suggestion from the Mingw site to copy libopengl32.a to libGL.a. So far nothing has changed the errors that I get after each compile attempt.
Give me some advice on how to resolve this.
autotools/autoconf is abysmally bad for crosscompilation. The way the generated configure script works is, that for many tests it attempts to compile and execute short test snippet programs. Of course the whole "execute" part will miserably fail for cross compiled libraries, due to either lack in instruction set support (compiling for a different CPU) or targeting an entirely different OS.
At least in Linux one can work around this using the "misc binfmt" kernel support, which allows to register interpreters for non-native executable formats. For Windows targets you'd use Wine as an interpreter and for foreign CPUs you can use QEmu which not only can emulate whole machines, but focus CPU emulation on a single process/binary. And of course you can combine it.
However this is just a crutch and honestly you should probably ditch autoconf/autotools entirely and just write Makefiles. Today the *nix-ish systems are so similar that none of these compiled tests make a lot of sense at all.

Cross-compiling to Raspberry Pi, using Qt and opencv

There are various ways to cross-compile to Raspberry Pi, and there are also solutions posted for cross-compiling Qt or opencv.
However, I couldn't find any solution to cross-compile a program with Qt which also uses opencv.
I tried the following, using debian on a 64-bit PC:
I compiled and set up Qt as a cross-compiler to ARM7, using this tutorial. It didn't work without issues though, here is an answer I posted which solved it for me. I can now run my Qt programs with graphical GUI on the Raspberry Pi (although only full-screen, but that's a completely different issue)
I followed the guide on the official opencv website to build opencv. It failed with No CMAKE_CXX_COMPILER could be found.
Knowing from experience (I used Qt with opencv both on Windows and Linux) that Qt and opencv work together only if both are compiled with the same compiler, I tried to use the same cross-compiler for opencv which I used successfully to compile Qt: gcc-4.7-linaro-rpi-gnueabihf
I specified the gnueabihf I previously used to compile Qt, as the compiler:
I created the directory ~/opt/opencv_build_arm7/ and in it, I tried:
sudo cmake -DCMAKE_CXX_COMPILER=/home/<user>/opt/gcc-4.7-linaro-rpi-gnueabihf/bin/arm-linux-gnueabihf-g++ -DCMAKE_C_COMPILER=/home/<user>/opt/gcc-4.7-linaro-rpi-gnueabihf/bin/arm-linux-gnueabihf-gcc -DCMAKE_TOOLCHAIN_FILE=/usr/dev/opencv/platforms/linux/arm-gnueabi.toolchain.cmake /usr/dev/opencv/
(Where the downloaded opencv sources were in /usr/dev/opencv/ which I recently used successfully to compile opencv for an x64 platform, using the g++ compiler which came with my Qt installation.) Note, that <user> is the username for the current session, in case other beginners might try these methods in the future.
This failed with the following error (where <user> is my username)
CMake Error at
/usr/share/cmake-3.0/Modules/CMakeTestCXXCompiler.cmake:54 (message):
The C++ compiler
"/home//opt/gcc-4.7-linaro-rpi-gnueabihf/bin/arm-linux-gnueabihf-g++"
is not able to compile a simple test program.
It fails with the following output :
Change Dir: /home//temp/CMakeFiles/CMakeTmp
Run Build Command:"/usr/bin/make" "cmTryCompileExec117178613/fast"
/usr/bin/make -f CMakeFiles/cmTryCompileExec117178613.dir/build.make
CMakeFiles/cmTryCompileExec117178613.dir/build
make1: Entering directory '/home//temp/CMakeFiles/CMakeTmp'
/usr/bin/cmake -E cmake_progress_report
/home//temp/CMakeFiles/CMakeTmp/CMakeFiles 1
Building CXX object
CMakeFiles/cmTryCompileExec117178613.dir/testCXXCompiler.cxx.o
/home//opt/gcc-4.7-linaro-rpi-gnueabihf/bin/arm-linux-gnueabihf-g++
-mthumb -fdata-sections -Wa,--noexecstack -fsigned-char -Wno-psabi -mthumb -fdata-sections -Wa,--noexecstack -fsigned-char -Wno-psabi -o CMakeFiles/cmTryCompileExec117178613.dir/testCXXCompiler.cxx.o -c /home//temp/CMakeFiles/CMakeTmp/testCXXCompiler.cxx
/home//temp/CMakeFiles/CMakeTmp/testCXXCompiler.cxx: In
function ‘int main()’:
/home//temp/CMakeFiles/CMakeTmp/testCXXCompiler.cxx:4:10:
sorry, unimplemented: Thumb-1 hard-float VFP ABI
CMakeFiles/cmTryCompileExec117178613.dir/build.make:57: recipe for
target
'CMakeFiles/cmTryCompileExec117178613.dir/testCXXCompiler.cxx.o'
failed
make1: ***
[CMakeFiles/cmTryCompileExec117178613.dir/testCXXCompiler.cxx.o] Error
1
make1: Leaving directory '/home//temp/CMakeFiles/CMakeTmp'
Makefile:118: recipe for target 'cmTryCompileExec117178613/fast'
failed
make: *** [cmTryCompileExec117178613/fast] Error 2
I specified an absolute path for the compiler, but even if I don't specify it, and just add it to my $PATH, it still has the same problem.
export PATH=$PATH:/home/<user>/opt/gcc-4.7-linaro-rpi-gnueabihf/bin/
sudo cmake -DCMAKE_TOOLCHAIN_FILE=/usr/dev/opencv/platforms/linux/arm-gnueabi.toolchain.cmake /usr/dev/opencv/
The compiler itself is found correctly, if I type
arm-linux-gnueabihf-g++ -v
it is found successfully:
Using built-in specs. COLLECT_GCC=./arm-linux-gnueabihf-c++
COLLECT_LTO_WRAPPER=/home/vszabi/opt/gcc-4.7-linaro-rpi-gnueabihf/bin/../libexec/gcc/arm-linux-gnueabihf/4.7.2/lto-wrapper
Target: arm-linux-gnueabihf Configured with:
/opt/dev/src/crosstool-ng/crosstool-ng-linaro-1.13.1-2012.07-20120720/builds/arm-linux-gnueabihf-linux/.build/src/gcc-linaro-4.7-2012.07/configure
--build=i686-build_pc-linux-gnu --host=i686-build_pc-linux-gnu --target=arm-linux-gnueabihf --prefix=/opt/dev/src/crosstool-ng/crosstool-ng-linaro-1.13.1-2012.07-20120720/builds/arm-linux-gnueabihf-linux/install
--with-sysroot=/opt/dev/src/crosstool-ng/crosstool-ng-linaro-1.13.1-2012.07-20120720/builds/arm-linux-gnueabihf-linux/install/arm-linux-gnueabihf/libc
--enable-languages=c,c++,fortran --enable-multilib --with-arch=armv6zk --with-tune=arm1176jzf-s --with-fpu=vfp --with-float=hard --with-pkgversion='crosstool-NG linaro-1.13.1-2012.07-20120720 - Linaro GCC 2012.07'
--with-bugurl=https://bugs.launchpad.net/gcc-linaro --enable-__cxa_atexit --enable-libmudflap --enable-libgomp --enable-libssp --with-gmp=/opt/dev/src/crosstool-ng/crosstool-ng-linaro-1.13.1-2012.07-20120720/builds/arm-linux-gnueabihf-linux/.build/arm-linux-gnueabihf/build/static
--with-mpfr=/opt/dev/src/crosstool-ng/crosstool-ng-linaro-1.13.1-2012.07-20120720/builds/arm-linux-gnueabihf-linux/.build/arm-linux-gnueabihf/build/static
--with-mpc=/opt/dev/src/crosstool-ng/crosstool-ng-linaro-1.13.1-2012.07-20120720/builds/arm-linux-gnueabihf-linux/.build/arm-linux-gnueabihf/build/static
--with-ppl=/opt/dev/src/crosstool-ng/crosstool-ng-linaro-1.13.1-2012.07-20120720/builds/arm-linux-gnueabihf-linux/.build/arm-linux-gnueabihf/build/static
--with-cloog=/opt/dev/src/crosstool-ng/crosstool-ng-linaro-1.13.1-2012.07-20120720/builds/arm-linux-gnueabihf-linux/.build/arm-linux-gnueabihf/build/static
--with-libelf=/opt/dev/src/crosstool-ng/crosstool-ng-linaro-1.13.1-2012.07-20120720/builds/arm-linux-gnueabihf-linux/.build/arm-linux-gnueabihf/build/static
--with-host-libstdcxx='-L/opt/dev/src/crosstool-ng/crosstool-ng-linaro-1.13.1-2012.07-20120720/builds/arm-linux-gnueabihf-linux/.build/arm-linux-gnueabihf/build/static/lib
-lpwl' --enable-threads=posix --disable-libstdcxx-pch --enable-linker-build-id --enable-gold --with-local-prefix=/opt/dev/src/crosstool-ng/crosstool-ng-linaro-1.13.1-2012.07-20120720/builds/arm-linux-gnueabihf-linux/install/arm-linux-gnueabihf/libc
--enable-c99 --enable-long-long Thread model: posix gcc version 4.7.2 20120701 (prerelease) (crosstool-NG linaro-1.13.1-2012.07-20120720 -
Linaro GCC 2012.07)
What could I try next? Opening the gui version of cmake with opencv/platforms/linux/arm-gnueabi.toolchain.cmake shows very few options (only ARM_LINUX_SYSROOT, CMAKE_BUILD_TYPE, CMAKE_CONFIGURATION_TYPES, CMAKE_INSTALL_PREFIX, GCC_COMPILER_VERSION and LIBRARY_OUTPUT_PATH_ROOT, but none of the BUILD_opencv_xyz with which I can disable individual packages), much fewer than the case when I built opencv for an x86 or x64 platform.
I'm afraid that searching for a different compiler might cause issues with Qt, because as far as I know, for opencv to work within Qt, it has to be compiled with the same compiler as what is used both to build the Qt libraries and build my program. Whenever I tried it in the past without being careful that these 3 things (Qt libs, opencv, my program) need to be compiled with the same compiler, I always experienced weird crashes either as soon as I included any opencv header, or whenever I called any function from opencv.
The tutorial at http://docs.opencv.org/doc/tutorials/introduction/crosscompilation/arm_crosscompile_with_cmake.html seems to be either wrong or out of date.
Downloading the source of opencv 3.0, the opencv/platforms/linux/arm-gnueabi.toolchain.cmake seems to be insufficiently configured for the Raspberry Pi.
Configure
Visiting the workgroup page of the creators of the arm-linux-gnueabihf toolchain, it seems that for the ARM7 in the Raspberry Pi to be supported, the following options have to be passed to the compiler: -mcpu=cortex-a7 -mfloat-abi=hard -mfpu=vfpv4
So, we have to edit the opencv/platforms/linux/arm-gnueabi.toolchain.cmake file and change
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mthumb -fdata-sections -Wa,--noexecstack -fsigned-char -Wno-psabi")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -mthumb -fdata-sections -Wa,--noexecstack -fsigned-char -Wno-psabi")
to
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mthumb -fdata-sections -Wa,--noexecstack -fsigned-char -Wno-psabi -mcpu=cortex-a7 -mfloat-abi=hard -mfpu=vfpv4")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -mthumb -fdata-sections -Wa,--noexecstack -fsigned-char -Wno-psabi -mcpu=cortex-a7 -mfloat-abi=hard -mfpu=vfpv4")
running cmake again, the configuration was successfully completed!
Make
During the building process, if the following error appears
CMakeFiles/opencv_core.dir/src/rand.cpp.o: relocation
R_ARM_THM_MOVW_ABS_NC against `a local symbol' can not be used when
making a shared object; recompile with -fPIC
CMakeFiles/opencv_core.dir/src/rand.cpp.o: could not read symbols: Bad
value
just add the -fPIC flag to the CMAKE_C_FLAGS and CMAKE_CXX_FLAGS in the cmake file and run make again.
Deployement
Using Qt Creator to deploy, just set up the headers and libraries in your .pro file, for example:
INCLUDEPATH += <your build dir>/install/include/opencv2/
INCLUDEPATH += <your build dir>/install/include/
LIBS += -L "<your build dir>/install/lib/"
LIBS += -lopencv_calib3d
LIBS += -lopencv_core
#... and so on
You also have to copy the compiled libraries (found in <your build dir>/install/lib/) to the Raspberry Pi. Using a USB stick might mess up the symlinks, so I would recommend using scp to copy the files.
If you are relatively new to Linux (just as myself), don't forget that executables don't automatically look into their own folders for dynamic libraries as they did in Windows.
Therefore you should either copy the libraries to a place which is usually searched for them (like /usr/local/bin) or update your LD_LIBRARY_PATH accordingly.
For a quick and dirty test, to see if everything works, you might copy the libraries into the same folder where your executable is deployed, and run it by using
$ LD_LIBRARY_PATH=. ./your_program
Testing
Opencv should work now in your Qt program on the Raspberry Pi.
Unless my google-fu is very weak, this might be the first documented case of running a Qt GUI application on a Raspberry Pi with opencv working in it. :)
However, note that there might still be some issues with window management.
Trying to open an opencv window, for example, cv::namedWindow("image"); might fail with the following error:
OpenCV Error: Unspecified error (The function is not implemented.
Rebuild the library with Windows, GTK+ 2.x or Carbon support. If you
are on Ubuntu or Debian, install libgtk2.0-dev and pkg-config, then
re-run cmake or configure script) in cvNamedWindow, file
/usr/dev/opencv/modules/highgui/src/window.cpp, line 516 terminate
called after throwing an instance of 'cv::Exception' what():
/usr/dev/opencv/modules/highgui/src/window.cpp:516: error: (-2) The
function is not implemented. Rebuild the library with Windows, GTK+
2.x or Carbon support. If you are on Ubuntu or Debian, install libgtk2.0-dev and pkg-config, then re-run cmake or configure script in
function cvNamedWindow
I guess we should do as it says, but cvNamedWindow is not very useful in a Qt GUI application, as it's usually only required for debugging. Therefore if the image has to be shown in your application, converting it to QImage might be better anyway than opening up an independent window.
However, everything else seems to work, I managed to successfully run complicated image matching algorithms on the Raspberry Pi.
(... will update if I find a good solution for running the Qt application in a window and using cvNamedWindow)

Crosscompile program for LLVM for ARMv6 on Ubuntu 32bit i686

I'm near to frustration ;-). Since more than a week I try to crosscompile on my ubunutu 12.04 box i686 Linux machine for a ARMv6 machine (arm1176jzf-s - known as Raspberry Pi) an own developed program with LLVM 3.4.2.
After days I was able to compile and link successfully. But as I've tried to execute my code on the Raspberry Pi I only received a memory access error. It has turned out that a segmentation fault is raised. I have analyzed it with gdb. Please refer please to the enclosed picture.
.
Basically I have done the following:
I build the C and C++ files: #echo 'Compiling' $(1).$(2); cd $(BIN); $(4) -c $(COMPILE_FLAGS) ../$(3)/$(1).$(2) -o $(1).o $(LLVM_CONFIG_COMPILE); cd ..
I llvm-linked it: cd $(BIN); $(LINK) -o tl.bc $(1)
Then I called the system compiler: cd $(BIN); $(LLC) $(LINKER_FLAGS) -filetype=obj tl.thumb.opt.bc -o tl.thumb.opt.o
And I called the linker, i.e. the arm-linux-gnueabihf-g++: $(LD) -o bin/tl bin/tl.thumb.opt.o $(LINK_OPTION) $(THREAD_LIB_DIR) $(call INFLATE_config)
`test -f bin/tl` && echo 'Make was successful. Find Turbo Lisp in folder' $(BIN)
Take a look at my console output for my make file:
Building Turbo Lisp 0.01 for machine i686 with operating system GNU/Linux
COMPILE_FLAGS used:
-fno-strict-aliasing -emit-llvm -mfloat-abi=hard -mcpu=arm1176jzf-s -mfpu=vfpv3-d16 -mthumb -target arm-unknown-linux-gnueabihf -I/usr/include/arm-linux-gnueabihf/c++/4.6 -I/usr/include/arm-linux-gnueabihf/c++/4.6/arm-linux-gnueabihf -I/usr/lib/gcc/arm-linux-gnueabihf/4.6/include -I/usr/local/lib/LLVM_ARM/BOOST -ccc-gcc-name arm-linux-gnueabihf-gcc
Compiling precedence.cpp
Compiling util.cpp
Compiling ast.cpp
Compiling abstractParser.cpp
Compiling metaparser.cpp
Compiling parserLisp.cpp
Compiling parserToy.cpp
Compiling preconfiguredLanguages.cpp
Compiling handler.cpp
Compiling helper.cpp
Compiling lexer.cpp
Compiling config_reader.cpp
Compiling tl.cpp
Compiling external_functions.c
Compiling error_util.cpp
Building binary code from:
tl.o preconfiguredLanguages.o handler.o external_functions.o abstractParser.o parserLisp.o parserToy.o metaparser.o ast.o helper.o util.o error_util.o config_reader.o lexer.o precedence.o
Linking...
cd bin; <myhome>/projects/llvm-3.4.2.src/buildARMCompileX86/Release+Asserts/bin/llvm-link -o tl.bc tl.o preconfiguredLanguages.o handler.o external_functions.o abstractParser.o parserLisp.o parserToy.o metaparser.o ast.o helper.o util.o error_util.o config_reader.o lexer.o precedence.o
Optimizing...
cd bin; <myhome>/projects/llvm-3.4.2.src/buildARMCompileX86/Release+Asserts/bin/opt tl.bc -o tl.thumb.opt.bc -float-abi=hard -std-compile-opts
System compiling...
cd bin; <myhome>/projects/llvm-3.4.2.src/buildARMCompileX86/Release+Asserts/bin/llc -float-abi=hard -march=arm -mtriple=arm-unknown-linux-gnueabihf -filetype=obj tl.thumb.opt.bc -o tl.thumb.opt.o
...And finally linking to native...
arm-linux-gnueabihf-g++ -o bin/tl bin/tl.thumb.opt.o -v -L/usr/lib/arm-linux-gnueabihf -L/usr/local/lib/LLVM_ARM/BOOST -L/usr/local/lib/LLVM_ARM -L/usr/lib/arm-linux-gnueabihf -L/usr/local/lib/LLVM_ARM/BOOST -L/usr/local/lib/LLVM_ARM -lz -lpthread -lrt -ldl -lm -lLLVMInterpreter -lLLVMMCJIT -lLLVMJIT -lLLVMRuntimeDyld -lLLVMExecutionEngine -lLLVMARMDisassembler -lLLVMARMCodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMCodeGen -lLLVMObjCARCOpts -lLLVMScalarOpts -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMARMAsmParser -lLLVMMCParser -lLLVMARMDesc -lLLVMARMInfo -lLLVMTarget -lLLVMCore -lLLVMARMAsmPrinter -lLLVMMC -lLLVMObject -lLLVMSupport -lpthread -ldl
`test -f bin/tl` && echo 'Make was successful. Find Turbo Lisp in folder' bin
Make was successful. Find Turbo Lisp in folder bin
It would be very nice, if anybody knowing much more about compiling for ARM could share his knowledge with me and direct me to the point I made so wrong.
Would like to comment but can't due to low "reputaion"...
Since you are "near to frustration" I would suggest trying gcc instead of LLVM because then it's likely easier to get help.
Eventually, I did it!
Maybe many of you are more interested in gcc than in LLVM and clang. But I think the issue here is more generally, than specific to LLVM. After I tried to compile LLVM and clang for ARM I ran another gdb session. It has turned out that glibc has different versions on my raspberry (2.13) and on my ubuntu (2.15). So I copied the libc from my ARM to my ubuntu system, but this didn't worked. I received messages from my gdb like "invalid machine instruction". This has caused me to check a bit more thoroughly the configure.log file of the clang build.
And, yes, the gcc cross compiler of ubuntu is simply compiled for an ARMv7 architecture, but the Raspberry is of ARMv6 (with ARM11 chip set).
So, the next point was to build my own gcc toolchain. First I tried to build my binutils, which allegedly was successful. Then I was heading to compile gcc linaro. And this has cost me days. At the end I hadn't achieved this mission. Either some include files were missing or linker issues have stopped me.
But I had the brilliant idea to make some more research, especially with keywords for the rasperry pi. And this has then pushed me back on track as I found crosstool-ng. What a great tool! You only need to configure in a kind of a menu which platform you like to address and then this tool downloads all your required files for a complete toolchain and installs it. Great! As I made this hurdle, it was pretty easy to build LLVM and clang.
The only point everybody needs to manage is to upgrade the Raspberry Pi, i.e. upgrade libc and libstdc++ by apt-get with the "testing" stage.
Feel free to ignore it or just check it out if you have also troubles to build up a correct gcc toolchain: Tutorial to setup crosstool-ng for RPi