Crosscompile program for LLVM for ARMv6 on Ubuntu 32bit i686 - c++

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

Related

How can I build on ubuntu something that was meant for FreeBSD?

I'm trying to build this: https://github.com/hselasky/hpsat_generate
this is their makefile:
PROG_CXX=hpsat_generate
PREFIX?=/usr/local
MAN=
SRCS= hpsat_generate.cpp
BINDIR?=${PREFIX}/bin
.if defined(HAVE_DEBUG)
CFLAGS+= -g -O0
.endif
CFLAGS+= -I${PREFIX}/include
LDFLAGS+= -L${PREFIX}/lib -lgmp -lgmpxx
.include <bsd.prog.mk>
using just make . results in
Makefile:7: *** missing separator. Stop.
so after some searching I found that I need to use FreeBSD make, so I tried:
bmake . hpsat_generate
which complains that mergesort is not declared, which is a FreeBSD function so I can only assume it doesn't really includes it.
I tried finding a way to make it run but I'm out of ideas..
The Makefile requires some changes for Linux (and NetBSD). The bsd.prog.mk implementation that comes with bmake on Linux is slightly off, and requires a workaround to link the program correctly, also, on Linux you need libbsd:
These issues are fixed by PR #1.
Instead of running the makefile just execute this:
g++ -o sat sat.cpp -lgmp -lgmpxx -l:libbsd.a
you may need to install the gmp and libbsd libraries

Speed up RcppArmadillo: How to link to OpenBlas in an R package

I am working on an R package which uses RcppArmadillo. I am trying to take advantage of faster matrix multiplication found in OpenBLAS. In the documentation of the C++ armadillo library, it says if we have OpenBLAS on our machine then Armadillo would use OpenBLAS instead of BLAS. However, when I compile my R package, I get something like this:
g++ -m64 -std=c++11 -shared -L/usr/lib64/R/lib -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o PackageTest.so class1.o class2.o class3.o class4.o class5.o class6.o class7.o RcppExports.o class8.o class9.o class10.o -L/usr/lib64/R/lib -lRlapack -L/usr/lib64/R/lib -lRblas -lgfortran -lm -lquadmath -L/usr/lib64/R/lib -lR
So it is compiling with the -lRlapack and -lRblas options. How can I properly modify the Makevars and Makevars.win files to have RcppArmadillo compile the package with the option -lopenblas? My attempt to solve this problem was to modify the Makevars file in the following way:
PKG_LIBS = $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)
PKG_CXXFLAGS =-fopenmp -std=c++11 -lopenblas
PKG_CXX1XFLAGS = $(PKG_CXXFLAGS)
The package did compile with -lopenblas, but is this the best way to do it?
That is a problem with your RedHat installation which chose to rely on the internal LAPACK sources for R when installing R --- plus the fact that RcppArmadillo uses whatever R uses.
On my Debian/Ubuntu based machine, it happens differently. Ie for
R> library(Rcpp)
R> cppFunction("arma::mat foo(arma::mat x) { return x + x;} ", depends="RcppArmadillo", verbose=TRUE)
I get (inter alia)
g++ -Wl,-S -shared -L/usr/lib/R/lib -Wl,-Bsymbolic-functions \
-Wl,-z,relro -o sourceCpp_4.so file677111d81351.o \
-fopenmp -llapack -lblas -lgfortran -lm -lquadmath \
-L/usr/lib/R/lib -lR
and we see -llapack -lblas -lgfortran as expected.
Instructions for compiling R, OpenBLAS and linking R with OpenBLAS (GNU/Linux)
I believe your biggest problem is linking R to the OpenBLAS library. So the steps I write below can help you succeed in this link.
Compiling OpenBLAS
Initially download the R and OpenBLAS(Open Optimized BLAS Library) source codes in OpenBLAS. In the file directory, perform the following steps.
tar -zxvf OpenBLAS*
cd OpenBLAs*
make -j $nproc
sudo make install
export LD_LIBRARY_PATH=/opt/OpenBLAS/lib/
or
git clone https://github.com/xianyi/OpenBLAS.git
cd OpenBLAS*
make -j $nproc
sudo make install
export LD_LIBRARY_PATH=/opt/OpenBLAS/lib/
Note: This will make the compilation run faster using all the features of your CPU. To know the number of cores, do: nproc.
Compiling Armadillo C++ with OpenBLAS
For those who use C++ codes in R using the Rcpp library, setting up the Armadillo with the OpenBLAS library may be of some benefit.
tar -xvf armadillo*
cd armadillo*
./configure -DCMAKE_PREFIX_PATH=/opt/OpenBLAS/lib/
cmake . -DCMAKE_PREFIX_PATH=/opt/OpenBLAS/lib/
make -j $nproc
sudo make install
Note: Further details regarding the compilation of the Armadillo library can be found at https://gitlab.com/conradsnicta/armadillo-code.
Compiling R with OpenBLAS
After compiling OpenBLAS, download the R code. It is not necessary to compile R to make use of OpenBLAS, but compiling the language may bring some benefits that may be insignificant depending on what is being done in R. That way, download the source code of the language R.
Note: In my operating system, Arch Linux, OpenBLAS) was installed in the /opt directory. Search for the OpenBLASinstallation directory in your GNU/Linux distribution.
In the directory where the R was downloaded, do the following:
tar -zxvf R*
cd R-* && ./configure --enable-R-shlib --enable-threads=posix --with-blas="-lopenblas -L/opt/OpenBLAS/lib -I/opt/OpenBLAS/include -m64 -lpthread -lm"
make -j $nproc
sudo make install
Most likely the OpenBLAS library will be bound to R. To check, run in the R the sessionInfo() code. Something like the output below should appear:
Matrix products: default
BLAS/LAPACK: /opt/OpenBLAS/lib/libopenblas_haswellp-r0.3.6.dev.so
If linking does not occur, follow the steps outlined in the code below.
We need to link the R with the file libopenblas_*, created in the process of compiling the library OpenBLAS. In my case, the file is ibopenblas_haswellp-r0.2.20.so. Look for this in /opt/OpenBLAS/lib or in the directory where OpenBLAS was installed on your GNU/Linux system. Also look for the libRblas.so file directory found in the R language installation directory. In Arch, this directory is /usr/local/lib64/R/lib.
cd /usr/local/lib64/R/lib
mv libRblas.so libRblas.so.keep
ln -s /opt/OpenBLAS/lib/libopenblas_haswellp-r0.2.20.so libRblas.so
Start a section of language R and do sessionInfo(). You should note something like:
Matrix products: default
BLAS/LAPACK: /opt/OpenBLAS/lib/libopenblas_haswellp-r0.3.6.dev.so
To make use of multithreaded processing, do export OPENBLAS_NUM_THREADS=1 before starting a R section.
NOTE: For intel processors,sudo cpupower frequency-set -g performance, can boost performance. Read more at https://wiki.archlinux.org/index.php/CPU_frequency_scaling.

Compiling freetype library on I386 (simulator) for iPhone

I'm trying to compile FreeType2 2.5.3 as a static library on I386 arch,
then use it on an iPhone OpenGL application.
I'm building the .a it with this script:
./configure '--without-bzip2' '--without-zlib' 'CFLAGS=-arch i386'
make clean
make
cp objs/.libs/libfreetype.a /Users/vlzvl/Desktop/libfreetype-i386.a
I'm not entirely sure but iPhone Simulator can run I386 arch library? should i build it on other arch instead (running Mountain Lion 10.8.2) on Virtualbox with iOS 6.0 SDK and XCode 4.5 ?
Anyway, i'm then loading the library on XCode through Build Phase -> Link Binary With Libraries and use the Other option to locate it.
My app crashes on first freetype function, the FT_Init_FreeType with a Signal SIGABRT error.
I finally succeeded compiling my static freetype library for i386 arch using the following script (with a help of some SO answers and some folder changes eg. /iPhonesimulator instead of /iPhoneOS)
./configure '--without-bzip2' '--without-zlib' '--without-png' '--host=arm-apple-darwin' '--enable-static=yes' '--enable-shared=no' 'CC=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc' 'CFLAGS=-arch i386 -pipe -std=c99 -Wno-trigraphs -fpascal-strings -O2 -Wreturn-type -Wunused-variable -fmessage-length=0 -fvisibility=hidden -miphoneos-version-min=6.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.0.sdk/'
make clean
make
cp objs/.libs/libfreetype.a /Users/vlzvl/Desktop/libfreetype-i386.a

Problems cross compiling Qt 4.7 from source for ARM

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"

how to port c/c++ applications to legacy linux kernel versions

Ok, this is just a bit of a fun exercise, but it can't be too hard compiling programmes for some older linux systems, or can it?
I have access to a couple of ancient systems all running linux and maybe it'd be interesting to see how they perform under load. Say as an example we want to do some linear algebra using Eigen which is a nice header-only library. Any chance to compile it on the target system?
user#ancient:~ $ uname -a
Linux local 2.2.16 #5 Sat Jul 8 20:36:25 MEST 2000 i586 unknown
user#ancient:~ $ gcc --version
egcs-2.91.66
Maybe not... So let's compile it on a current system. Below are my attempts, mainly failed ones. Any more ideas very welcome.
Compile with -m32 -march=i386
user#ancient:~ $ ./a.out
BUG IN DYNAMIC LINKER ld.so: dynamic-link.h: 53: elf_get_dynamic_info: Assertion `! "bad dynamic tag"' failed!
Compile with -m32 -march=i386 -static: Runs on all fairly recent kernel versions but fails if they are slightly older with the well known error message
user#ancient:~ $ ./a.out
FATAL: kernel too old
Segmentation fault
This is a glibc error which has a minimum kernel version it supports, e.g. kernel 2.6.4 on my system:
$ file a.out
a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
statically linked, for GNU/Linux 2.6.4, not stripped
Compile glibc myself with support for the oldest kernel possible. This post describes it in more detail but essentially it goes like this
wget ftp://ftp.gnu.org/gnu/glibc/glibc-2.14.tar.bz2
tar -xjf glibc-2.14.tar.bz2
cd glibc-2.14
mkdir build; cd build
../configure --prefix=/usr/local/glibc_32 \
--enable-kernel=2.0.0 \
--with-cpu=i486 --host=i486-linux-gnu \
CC="gcc -m32 -march=i486" CXX="g++ -m32 -march=i486"
make -j 4
make intall
Not sure if the --with-cpu and --host options do anything, most important is to force the use of compiler flags -m32 -march=i486 for 32-bit builds (unfortunately -march=i386 bails out with errors after a while) and --enable-kernel=2.0.0 to make the library compatible with older kernels. Incidentially, during configure I got the warning
WARNING: minimum kernel version reset to 2.0.10
which is still acceptable, I suppose. For a list of things which change with different kernels see ./sysdeps/unix/sysv/linux/kernel-features.h.
Ok, so let's link against the newly compiled glibc library, slightly messy but here it goes:
$ export LIBC_PATH=/usr/local/glibc_32
$ export LIBC_FLAGS=-nostdlib -L${LIBC_PATH} \
${LIBC_PATH}/crt1.o ${LIBC_PATH}/crti.o \
-lm -lc -lgcc -lgcc_eh -lstdc++ -lc \
${LIBC_PATH}/crtn.o
$ g++ -m32 -static prog.o ${LIBC_FLAGS} -o prog
Since we're doing a static compile the link order is important and may well require some trial and error, but basically we learn from what options gcc gives to the linker:
$ g++ -m32 -static -Wl,-v file.o
Note, crtbeginT.o and crtend.o are also linked against which I didn't need for my programmes so I left them out. The output also includes a line like --start-group -lgcc -lgcc_eh -lc --end-group which indicates inter-dependence between the libraries, see this post. I just mentioned -lc twice in the gcc command line which also solves inter-dependence.
Right, the hard work has paid off and now I get
$ file ./prog
./prog: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
statically linked, for GNU/Linux 2.0.10, not stripped
Brilliant I thought, now try it on the old system:
user#ancient:~ $ ./prog
set_thread_area failed when setting up thread-local storage
Segmentation fault
This, again, is a glibc error message from ./nptl/sysdeps/i386/tls.h. I fail to understand the details and give up.
Compile on the new system g++ -c -m32 -march=i386 and link on the old. Wow, that actually works for C and simple C++ programmes (not using C++ objects), at least for the few I've tested. This is not too surprising as all I need from libc is printf (and maybe some maths) of which the interface hasn't changed but the interface to libstdc++ is very different now.
Setup a virtual box with an old linux system and gcc version 2.95. Then compile gcc version 4.x.x ... sorry, but too lazy for that right now ...
???
Have found the reason for the error message:
user#ancient $ ./prog
set_thread_area failed when setting up thread-local storage
Segmentation fault
It's because glibc makes a system call to a function which is only available since kernel 2.4.20. In a way it can be seen as a bug of glibc as it wrongly claims to be compatible with kernel 2.0.10 when it requires at least kernel 2.4.20.
The details:
./glibc-2.14/nptl/sysdeps/i386/tls.h
[...]
/* Install the TLS. */ \
asm volatile (TLS_LOAD_EBX \
"int $0x80\n\t" \
TLS_LOAD_EBX \
: "=a" (_result), "=m" (_segdescr.desc.entry_number) \
: "0" (__NR_set_thread_area), \
TLS_EBX_ARG (&_segdescr.desc), "m" (_segdescr.desc)); \
[...]
_result == 0 ? NULL \
: "set_thread_area failed when setting up thread-local storage\n"; })
[...]
The main thing here is, it calls the assembly function int 0x80 which is a system call to the linux kernel which decides what to do based on the value of eax, which is set to
__NR_set_thread_area in this case and is defined in
$ grep __NR_set_thread_area /usr/src/linux-2.4.20/include/asm-i386/unistd.h
#define __NR_set_thread_area 243
but not in any earlier kernel versions.
So the good news is that point "3. Compiling glibc with --enable-kernel=2.0.0" will probably produce executables which run on all linux kernels >= 2.4.20.
The only chance to make this work with older kernels would be to disable tls (thread-local storage) but which is not possible with glibc 2.14, despite the fact it is offered as a configure option.
The reason you can't compile it on the original system likely has nothing to do with kernel version (it could, but 2.2 isn't generally old enough for that to be a stumbling block for most code). The problem is that the toolchain is ancient (at the very least, the compiler). However, nothing stops you from building a newer version of G++ with the egcs that is installed. You may also encounter problems with glibc once you've done that, but you should at least get that far.
What you should do will look something like this:
Build latest GCC with egcs
Rebuild latest GCC with the gcc you just built
Build latest binutils and ld with your new compiler
Now you have a well-built modern compiler and (most of a) toolchain with which to build your sample application. If luck is not on your side you may also need to build a newer version of glibc, but this is your problem - the toolchain - not the kernel.