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):

1. Verified, that R-Pi uses hard floating point architecture (according some googled-out blog).
2. Installed stand-alone gnu g++ cross-compiler (arm-linux-gnueabihf-g++).
3. 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/
4. Put both paths into both QMAKE_LIBDIR and QMAKE_RPATHLINKDIR.
5. 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++.
6. Did dirty hackery in library folders about libQt5*.so.<numbers>, creating symlink to them named libQt5*.so just in the same folder
7. Off course created simple Hello, world C++ program (two of them, console and widgets)

Now the results:

1. Application compiles, links and deploys without objections (except of widgets version see below)
2. 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.
3. The same configuration for WIDGETS complies about different VFS in object files and application (this is where I found step 5 necessary)
4. 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:

1. Aptitude says I am using architecture armhf (cross-checked with in-package descriptions).
2. 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.