Qt Forum

    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Unsolved

    Need help with segfault in crosscompiled application for Raspberry Pi

    Installation and Deployment
    raspberry pi gnu c++ cross-compile cross compile crosscompile raspberry
    2
    2
    2400
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • P
      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):

      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.

      1 Reply Last reply Reply Quote 0
      • A
        awsomedevsigner last edited by 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.

        1 Reply Last reply Reply Quote 1
        • First post
          Last post