Planned maintenance has been done but it did not solve the problem. So work will continue on this and a new time for trying updates will be announced asap.
Need help with segfault in crosscompiled application for Raspberry Pi
pmendl last edited by
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):
- 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.
- 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 last edited by awsomedevsigner
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.