Need help with segfault in crosscompiled application for Raspberry Pi

pmendl

After three days with only partial success I give up and ask wiser for help:

I passed all the way through hell to make my project (simple Hello worlds, console and widgets) to compile (both). However I just run into Segmentation fault when trying to run applications on Raspberry while I can make console application work, but in the sstrange arrangement. (I.e. where I would IMHO expect it not to work it does while does not where I would expect clean success.)

I am running Raspbian (Linux raspberrypi 4.1.7+ #817 PREEMPT Sat Sep 19 15:25:36 BST 2015 armv6l GNU/Linux) updated to actual testing distribution packages, while compiling on amd64 PC (Linux <censored> 4.2.0-1-amd64 #1 SMP Debian 4.2.1-2 (2015-09-27) x86_64 GNU/Linux).
What have I done so far (omitting many dead end paths and not necessary in the chronological order):

Verified, that R-Pi uses hard floating point architecture (according some googled-out blog).
Installed stand-alone gnu g++ cross-compiler (arm-linux-gnueabihf-g++).
Copied following library binaries from R-Pi to my PC (as is):
/lib/arm-linux-gnueabihf/->/usr/local/lib/arm-linux-gnueabihf/
/usr/lib/arm-linux-gnueabihf/->/usr/local/lib/usr/arm-linux-gnueabihf/
Put both paths into both QMAKE_LIBDIR and QMAKE_RPATHLINKDIR.
Did dirty hackery about (missing) /usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-arm-gnueabihf-g++:
5a) copied /usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-arm-gnueabi-g++ to linux-arm-gnueabihf-g++.
5b) manually edited each line in qmake conf specifying arm-linux-gnueabi-g++ to arm-linux-gnueabihf-g++.
Did dirty hackery in library folders about libQt5*.so.<numbers>, creating symlink to them named libQt5*.so just in the same folder
Off course created simple Hello, world C++ program (two of them, console and widgets)

Now the results:

Application compiles, links and deploys without objections (except of widgets version see below)
If I omitted (actually forgot initially) the step 5, compilation uses linux-arm-gnueabihf-g++ while linker uses linux-arm-gnueabi-g++ (notice missing "...hf"). The deployed CONSOLE binary target runs perfectly either from Qt or from sshed R-Pi command line.
The same configuration for WIDGETS complies about different VFS in object files and application (this is where I found step 5 necessary)
After applying step 5 both console and widgets version compiles and deploys BUT both (!) versions fails with Segmentation fault when run on R-Pi. This is verified twice, with step 5 I get Segmentation fault on both versions while w/o this step I get console running normally, while Widgets complains about VFS difference during link phase.

I would simply say I have non-hf version Linux on my R-Pi if not the following:

Aptitude says I am using architecture armhf (cross-checked with in-package descriptions).
Console version runs (sometimes).

For the sake of completeness this is the compilation protocol of console variant with the hf variant (step 5 included):

12:09:13: Running steps for project Test...
12:09:13: Starting: "/usr/bin/make" clean
rm -f main.o
rm -f *~ core *.core
12:09:13: The process "/usr/bin/make" exited normally.
12:09:13: Configuration unchanged, skipping qmake step.
12:09:13: Starting: "/usr/bin/make" 
arm-linux-gnueabihf-g++ -c -pipe -O2 -Wall -W -D_REENTRANT -fPIC -DQT_NO_DEBUG -DQT_CORE_LIB -I../Test -I. -isystem    /usr/include/x86_64-linux-gnu/qt5 -isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -I. -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-arm-gnueabihf-g++ -o main.o ../Test/main.cpp
arm-linux-gnueabihf-g++ -Wl,-O1 -Wl,-rpath-link,/usr/local/lib/arm-linux-gnueabihf/ -Wl,-rpath-link,/usr/local/lib/usr/arm-linux-gnueabihf/ -o Test main.o   -L/usr/local/lib/arm-linux-gnueabihf/ -L/usr/local/lib/usr/arm-linux-gnueabihf/ -lQt5Core -lpthread 
12:09:14: The process "/usr/bin/make" exited normally.
12:09:14: Elapsed time: 00:00.

Questions:

What am I doing wrong or what else should I check?
Could it be worth the effort to mess with dev packages and use "native" armhf Qt includes instead of the "host" x86_64-linux-gnu ones used so far?
How it comes, that application linked with non-hf linker against hf QtCore lib runs normally in hf R-Pi environment?

Thanks in advance for any ideas.

awsomedevsigner

Hi,

I have been starting development using QT a few weeks ago and encountered a similar problem. Everything was fine, compiling the apps and deploying to the PI using QT Creator without issues. But as soon as I started the app (or wanted to debug) the app died with a Segfault.

After some hours, I noticed that libts on Jessie has been quite old. I re-installed Jessie-Lite and compiled libts on my own, directly from the GitHub repository here: lbts GitHub Repo .

Afterwards I simply followed the tutorial to cross-compile QT5 like documented in this tutorial: RaspberryPi2EGLFS

Basically I followed each step within the tutorial and the only thing I did not do, was to install any libts related packages (just check the apt-get install commands in the tutorial and don't install the libts related packages).

I know, the thread is quite old, but maybe someone will look it up.