Bug 11926 - Cross compiled Qt applications aren't working anymore
Summary: Cross compiled Qt applications aren't working anymore
Status: RESOLVED MOVED
Alias: None
Product: buildroot
Classification: Unclassified
Component: Other (show other bugs)
Version: 2019.05
Hardware: All Linux
: P5 blocker
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-06-02 19:51 UTC by ramtheconqueror
Modified: 2024-06-15 14:49 UTC (History)
3 users (show)

See Also:
Host:
Target: arm-linux-gnueabihf
Build:


Attachments
QmlTest Code (4.46 KB, application/octet-stream)
2019-06-02 19:51 UTC, ramtheconqueror
Details
defconfig file to reproduce bug (1.78 KB, application/octet-stream)
2020-02-06 09:36 UTC, Martin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ramtheconqueror 2019-06-02 19:51:28 UTC
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.
Comment 1 ramtheconqueror 2019-06-02 19:56:17 UTC
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
Comment 2 ramtheconqueror 2019-06-02 20:14:34 UTC
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
Comment 3 Thomas Petazzoni 2019-06-03 07:01:54 UTC
Could you try reverting 951d438ddd212eb8163a67670383f2c86a8abc1b and see if it helps ?
Comment 4 ramtheconqueror 2019-06-03 14:07:32 UTC
(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.
Comment 5 ramtheconqueror 2019-06-06 10:39:21 UTC
Hello,

2019.05 released with this P5 blocker?

Any workaround for this problem please?
Comment 6 Martin 2020-02-05 15:40:24 UTC
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.
Comment 7 Peter Seiderer 2020-02-05 22:34:19 UTC
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?
Comment 8 Martin 2020-02-06 09:36:47 UTC
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.
Comment 9 Martin 2020-02-06 09:49:03 UTC
(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'.
Comment 10 Peter Seiderer 2020-02-17 12:04:21 UTC
(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
Comment 11 Peter Seiderer 2020-02-17 12:42:44 UTC
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
Comment 12 Yann E. MORIN 2024-06-15 14:49:45 UTC
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!