@Milav said in segmentation fault: the difference between host pc and Embedded target board is only QT source. Host pc => qmake (qt version 5.4.0 ) Embedded target => qmake (qt version 4.8.7) You should have stated these settings from the very beginning... :-) Anyway, could it be possible that you build Qt 4.8.7 for PC (host) and build your example again with that Qt version and run in PC to see what happens.

@sierdzio Okay Thank You. :)

Hi, Two question: Why Qt 5.7.1 ? The current LTS is 5.12.5 Can you use a more recent version of GCC ? 4.4 is a bit old.

It's not a problem of Qt Creator. The mkspec used for the RPI3 is still valid unless your sysroot comes from a Debian Stretch were they have changed the library name. You need to modify the mkspec under devices that matches the Rpi3

Hi, If you copy the files over your target respecting the same folders as your desktop machine, then you won't have anything special to do.

@ruisebastiao well this is a rather hacky workaround to fix something Qt has broken within a LTS version. The thing is that libmali uses a unified lib which contains all symbols for EGL, OpenGL ES etc. so it would be wrong to apply a single .so name. It worked fine in 5.12.0 so it's probably time to come up with a solution for this "use absolute paths" nonsense has introduced. it works once you duplicate the unified lib & patch it. So Qt needs to deal with this kind of libs instead of forcing users to patch stuff. https://forum.qt.io/topic/104015/cross-compilation-generates-full-paths-in-libqt5gui-so-for-libglesv2-so-and-libgl-so-then-cannot-be-found-in-execution-time/3

@SGaist thanks I‘ll bookmark that as well I was just googleing qtcharts source and took the firts link 🙈

Did you try the this https://bugreports.qt.io/browse/QTBUG-62216 For the pi2 configuration the change should be something like this: -QMAKE_LIBS_EGL = -lEGL -lGLESv2 -QMAKE_LIBS_OPENVG = -lEGL -lOpenVG -lGLESv2 +QMAKE_LIBS_EGL = -lbrcmEGL -lbrcmGLESv2 +QMAKE_LIBS_OPENGL_ES2 = -lbrcmEGL -lbrcmGLESv2 +QMAKE_LIBS_OPENVG = -lbrcmEGL -lbrcmOpenVG -lbrcmGLESv2

Because I had the same Issues with the same Tutorial and often came along this discussion while searching for possible solutions, I took the privilege to dig up this old thread. With the help of What would be a pratical example of sysroot and prefix options for Qt and especially the mentioned option, quote:" -no-gcc-sysroot very specific hack for compilers that can't find their own crt inside --sysroot passes sysroot to pkgconfig and others, but not to gcc so that gcc will be called with -L/sysroot/lib/ correctly, but doesn't try to find implicit paths (crt) here. ", I was able to fix the problem.

@CybeX 1:I saw on google that someone else had this error with gcc 4.8. Upgrading solved it. Not saying it will for you. But was the only errors i could find in your log. 2: Sorry I don't know how to solve this. People are compiling for the PI but I never got around to try one so the details of getting it to work is also unknown to me. Update: I have a good eye to https://www.ics.com/blog/configuring-qt-creator-raspberry-pi but no board so didnt try yet.

To build QtCharts calling qmake CONFIG+=debug_and_release make debug make release make install should be enough to build and install it

@BruceNaylor Hmm that's interesting! I posted on the C++ Gurus forum and a couple guys there suggested I use the MinGW that gets installed with QT Creator (when you select that option) and that actually fixed my issue with registry keys. I was going to give cross compiling another try on Windows, maybe your fudges will fix some other issues I've into. I appreciate the suggestions!

Yeah, I have right. I copy all Qt library to RPI and use this in rpi terminal: export LD_LIBRARY_PATH="/home/pi/QtBase-5.7.0/lib" ./Test and everything work. Tomorrow I'll try just install qt in rpi, and this should work without terminal. Another topic solved.