| Summary: | Cross compiled Qt applications aren't working anymore | ||
|---|---|---|---|
| Product: | buildroot | Reporter: | ramtheconqueror |
| Component: | Other | Assignee: | unassigned |
| Status: | RESOLVED MOVED | ||
| Severity: | blocker | CC: | buildroot, martinv1985, yann.morin.1998 |
| Priority: | P5 | ||
| Version: | 2019.05 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Host: | Target: | arm-linux-gnueabihf | |
| Build: | |||
| Attachments: |
QmlTest Code
defconfig file to reproduce bug |
||
Tried setting up LD_LIBRARY_PATH with export. Added qt.conf file as well. [Paths] Prefix=/usr Libraries=lib Headers=include/qt5 Plugins=lib/qt/plugins Examples=lib/qt/examples Even the Qt cinematic experience which is compiled as part of the buildroot is not working a well. # CinematicExperience-demo /usr/share/Qt5/CinematicExperience/Qt5_CinematicExperience: error while loading shared libraries: /home/ram/work/Linux-tool/buildroot-output/2019.05-rc3/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libGLESv2.so: cannot open shared object file: No such file or directory Could you try reverting 951d438ddd212eb8163a67670383f2c86a8abc1b and see if it helps ? (In reply to Thomas Petazzoni from comment #3) Hello Thomas, I've reverted that change and still no use. [Paths] Prefix=@@HOST_DIR@@ Sysroot=@@STAGING_DIR@@ Headers=/usr/include/qt5 Libraries=/usr/lib LibraryExecutables=/usr/libexec Binaries=/usr/bin Plugins=/usr/lib/qt/plugins Examples=/usr/lib/qt/examples Qml2Imports=/usr/qml Imports=/usr/imports Translations=/usr/translations Examples=/usr/lib/qt/examples Demos=/usr/lib/qt/examples Tests=/usr/tests Settings=/usr Documentation=/usr/doc ArchData=/usr Data=/usr Anything else please? Thanks for your help. Hello, 2019.05 released with this P5 blocker? Any workaround for this problem please? I was having similar issues when compiling a image with qt for arm. Even qtdiag, which was also build using buildroot, had the error that the EGL/GLES libraries where linked using the absolute paths of the machine running buildroot. However, when testing Qt version 5.14 this problem seems to be resolved. The qtdiag works again and i can also compile and run one of the example programs myself. Never observed the problem myself..., can you provide a .config or defconfig file to reproduce the problem (and report the used buildroot version and/or additional patches)? Do your use a buildroot toolchain or an extenal one? Is your buildroot compile in-tree or out-of-tree? Created attachment 8361 [details]
defconfig file to reproduce bug
See the attached custom_qt_link_bug_defconfig for a minimal configuration for this bug.
I used buildroot master (cloned on Tue Feb 4, commit 4fb3c69854b01fd8f6483a8dbbb73d05ef26e96a) with 2 patches i found on patchwork. The patches are '[RFC,v3,1/2] package/qt5: bump latest version to 5.13.2' and '[RFC,v3,2/2] package/qt5: bump latest version to 5.14.1'. I did need to slightly adjust the patches to get them working with that specific commit. I still need to look up the best way to give the feedback on those patches, but for now i will mention it here.
I had to change the patch for the files 'package/qt5/qt5x11extras/5.13.2/qt5serialport.hash' and 'package/qt5/qt5x11extras/5.13.2/qt5x11extras.hash'. These
files where changed in master after the patch was created. The first line in each files where changed, ending in '.sha256' instead of '.mirrorlist'.
I used a toolchain that buildroot compiled. I did change the host dir to an out-of-tree folder.
With buildroot-2019.11.1 qtdiag did not work. The output of 'readelf -d' already showed that libGLES is linked using absolute paths and on the target device i also got the "no such file or directory" errors. Using the buildroot-master & qt5.14 patches readelf did not show absolute paths and qtdiag worked on the target device.
I hope this is enough information. I am still learning to use buildroot etc.
(In reply to Martin from comment #8) Small copy-paste error in comment #8. 'package/qt5/qt5x11extras/5.13.2/qt5serialport.hash' should be 'package/qt5/qt5serialport/5.13.2/qt5serialport.hash'. (In reply to Martin from comment #9) Hello Martin, can reproduce your problem with the given defconfig (independent of the custom setting BR2_HOST_DIR or using the default). Using sunxi-mali-mainline I get: $ readelf -d target/usr/bin/qtdiag | grep libGLESv2 0x00000001 (NEEDED) Shared library: [/my_build_path/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libGLESv2.so] Same defconfig changed to rpi-userland leads to: $ readelf -d target/usr/bin/qtdiag | grep libGLESv2 0x00000001 (NEEDED) Shared library: [libGLESv2.so] For sunxi-mali-mainline: $ cat host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/pkgconfig/glesv2.pc prefix=/usr exec_prefix=${prefix} libdir=${exec_prefix}/lib includedir=${prefix}/include Name: glesv2 Description: ARM Mali implementation of OpenGL ESv2 Version: 2.0 Requires: Libs: -L${libdir} -lGLESv2 -lGLESv1_CM Cflags: -I${includedir} For rpi-userland: $ cat host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/pkgconfig/glesv2.pc prefix=/usr exec_prefix=${prefix} libdir=${exec_prefix}/lib includedir=${prefix}/include Name: glesv2 Description: RasberryPi implementation of OpenGL ESv2 Version: 2.0 Libs: -L${libdir} -lGLESv2 Cflags: -I${includedir}/ Did not see where the different linking comes from... Regards, Peter Yes, seems to be fixed with the Qt-5.14.1 update, one difference I see is:
$ diff -u build_qt_5_12_7/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libQt5OpenGLExtensions.prl build_qt_5_14_1/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libQt5OpenGLExtensions.prl
--- build_qt_5_12_7/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libQt5OpenGLExtensions.prl 2020-02-17 12:28:55.931270726 +0100
+++ build_qt_5_14_1/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libQt5OpenGLExtensions.prl 2020-02-17 13:25:00.047405910 +0100
@@ -1,6 +1,7 @@
-QMAKE_PRL_BUILD_DIR = /.../build_qt_5_12_7/build/qt5base-5.12.7/src/openglextensions
+QMAKE_PRL_BUILD_DIR = /.../build_qt_5_4_1/build/qt5base-5.14.1/src/openglextensions
[...]
-QMAKE_PRL_VERSION = 5.12.7
-QMAKE_PRL_LIBS = -latomic $$[QT_INSTALL_LIBS]/libQt5Gui.so $$[QT_INSTALL_LIBS]/libQt5Core.so -lpthread $$[QT_INSTALL_LIBS]/libGLESv2.so -lrt -lpthread -ldl
+QMAKE_PRL_VERSION = 5.14.1
+QMAKE_PRL_LIBS = -latomic $$[QT_INSTALL_LIBS]/libQt5Gui.so $$[QT_INSTALL_LIBS]/libQt5Core.so -lpthread -L$$[QT_INSTALL_LIBS] -lGLESv2 -lGLESv1_CM -lrt -lpthread -ldl
Thank you for your report.
The issue tracker for the Buildroot project has been moved to
the Gitlab.com issue tracker:
https://gitlab.com/buildroot.org/buildroot/-/issues
We are taking this opportunity to close old issues in this old
tracker. If you believe your issue is still relevant, please
open one in the new issue tracker.
Thank you!
|
Created attachment 8071 [details] QmlTest Code Used Buildroot 2019.05-rc3 Linaro 7.4.1 toolchain Compiled fine and then installed Qt Creator and setup qmake and cross compiler. Created a blank QML application, compiled, deployed and ran the app only to see shared libs related errors. # /opt/QmlTest/bin/QmlTest /opt/QmlTest/bin/QmlTest: error while loading shared libraries: /home/ram/work/linux-tool/buildroot-output/2019.05-rc3/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libGLESv2.so: cannot open shared object file: No such file or directory I'm using buildroot 2018.05 which works fine for the same application.