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

[Ignacio_Alvarez]

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.

[Ignacio_Alvarez]

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.

[Ignacio_Alvarez]

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]

[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.

[vikramg]

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.