Qt Forum

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

    Qt Academy Launch in California!

    Solved Cross-compilation generates full paths in libQt5Gui.so for libGLESv2.so and libGL.so, then cannot be found in execution time

    Installation and Deployment
    3
    5
    1302
    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.
    • I
      Ignacio_Alvarez last edited by

      I am trying to compile Qt 5.12.3 for Odroid XU4 with Mali support.
      My rootfs is:
      /home/developer/proyectos/Odroid/RootFS
      My configure command is:
      ../qt5/configure -opensource -confirm-license -release -prefix /opt/QtXU4Mali -hostprefix /opt/QtXU4Mali -extprefix /opt/QtXU4Mali -device odroid-xu4-mali-g++ -device-option CROSS_COMPILE=/home/developer/proyectos/Odroid/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf- -sysroot /home/developer/proyectos/Odroid/RootFS -L/usr/lib/arm-linux-gnueabihf -nomake examples -nomake tests -nomake tools -no-pch -opengl es2 -system-zlib -egl -eglfs -no-xcb -skip wayland -v

      When compiling, the resulting libQt5Gui.so contains relative references to all the libraries except for libGLESv2.so and libGL.so, for which the references are absolute including the RootFS path. Everything compiles fine, but when an application has to be executed in the target system, these libraries are not found as their path belongs to the host fs.

      The output of readelf shows this issue:
      $ arm-linux-gnueabihf-readelf -a qtbase/lib/libQt5Gui.so | grep "Shared library"
      readelf: Warning: [ 9]: Info field (0) should index a relocatable section.
      0x00000001 (NEEDED) Shared library: [libQt5Core.so.5]
      0x00000001 (NEEDED) Shared library: [libpthread.so.0]
      0x00000001 (NEEDED) Shared library: [/home/developer/proyectos/Odroid/RootFS/usr/lib/arm-linux-gnueabihf/libGLESv2.so]
      0x00000001 (NEEDED) Shared library: [/home/developer/proyectos/Odroid/RootFS/usr/lib/arm-linux-gnueabihf/libEGL.so]
      0x00000001 (NEEDED) Shared library: [libpng16.so.16]
      0x00000001 (NEEDED) Shared library: [libz.so.1]
      0x00000001 (NEEDED) Shared library: [libstdc++.so.6]
      0x00000001 (NEEDED) Shared library: [libm.so.6]
      0x00000001 (NEEDED) Shared library: [libgcc_s.so.1]
      0x00000001 (NEEDED) Shared library: [libc.so.6]

      I've seen something related to this issue in QTBUG-72903 and QTBUG-73659, but still don't know how to proceed to obtain relative paths (or absolute paths in the target system) in the resulting libQt5Gui.so file for these two specific libraries.

      1 Reply Last reply Reply Quote 2
      • I
        Ignacio_Alvarez last edited by

        Found myself a solution, although it's not nice at all, using patchelf in the target computer (Odroid XU4)

        For each library using libEGL.so or libGLESv2.so (in my case /opt/QtXU4Mali/lib/libQt5Widgets.so , /opt/QtXU4Mali/lib/libQt5Gui.so and /opt/QtXU4Mali/plugins/platforms/libqeglfs.so , use patchelf to remove the bad reference, and then add the good one. For instance, for libQt5Widgets (only dependent on libGLESv2.so):
        $ sudo patchelf --debug --remove-needed /home/developer/proyectos/Odroid/RootFS/usr/lib/arm-linux-gnueabihf/libGLESv2.so /opt/QtXU4Mali/lib/libQt5Widgets.so
        $ sudo patchelf --debug --add-needed libGLESv2.so /opt/QtXU4Mali/lib/libQt5Widgets.so

        Hope this helps someone. Anyway, still pending to know the reason of the bad path assignment in the compilation.

        1 Reply Last reply Reply Quote 1
        • I
          Ignacio_Alvarez last edited by

          Finally found the good solution. It may also solve https://forum.qt.io/topic/101590/absolute-paths-to-egl-library-in-libqt5gui-so-since-qt-5-12-1

          In fact, the problem was that the installed libGLESv2.so and libEGL.so files in the target filesystem did not have the SONAME field, while other similar libraries did have it.

          This can be seen with arm-linux-gnueabihf-readelf -d filename | grep SONAME from the host computer (or with readelf in the target computer).

          For libpng16.so (correctly linked):
          $ arm-linux-gnueabihf-readelf -d libpng16.so | grep SONAME
          0x0000000e (SONAME) Library soname: [libpng16.so.16]

          For libGLESv2.so (linked with full path):
          $ arm-linux-gnueabihf-readelf -d libGLESv2.so | grep SONAME
          <no output>

          Using patch-elf (I executed in the target computer, I don't know if there are other options), I added SONAME field to the conflicting libraries:
          $ sudo patchelf --debug --set-soname libGLESv2.so libGLESv2.so

          And now the output is:
          $ arm-linux-gnueabihf-readelf -d libGLESv2.so | grep SONAME
          0x0000000e (SONAME) Library soname: [libGLESv2.so]

          After new configure and make, the references to these libraries in libQt5Gui.so and others are now correct:
          Before:
          $ arm-linux-gnueabihf-readelf -d qtbase/lib/libQt5Gui.so | grep "libGLESv2"
          0x00000001 (NEEDED) Shared library: [/home/developer/proyectos/Odroid/RootFS/usr/lib/arm-linux-gnueabihf/libGLESv2.so]

          Now:
          $ arm-linux-gnueabihf-readelf -d qtbase/lib/libQt5Gui.so | grep "libGLESv2"
          0x00000001 (NEEDED) Shared library: [libGLESv2.so]

          1 Reply Last reply Reply Quote 3
          • SupervisedThinking
            SupervisedThinking last edited by SupervisedThinking

            This is probably the same problem as https://forum.qt.io/topic/101590/absolute-paths-to-egl-library-in-libqt5gui-so-since-qt-5-12-1 I can confirm that my libmali-midgard-t86x-r14p0-gbm.so is missing the SONAME tag too and I have exact the same problem as described above since the switch to absolute link paths in Qt 5.12.1

            EDIT:
            you should also add your thoughts about that to https://bugreports.qt.io/browse/QTBUG-75098 to show it's a quite important issue.

            1 Reply Last reply Reply Quote 2
            • vikramg
              vikramg last edited by

              This is still a problem in 2022 in building Qt 5.12.12 for Odroid with Mali support. Minor improvement to @Ignacio_Alvarez 's answer is that SONAME should include the major version, so --set-soname to libGLESv2.so.2.

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