Absolute paths to EGL library in libQt5Gui.so since Qt 5.12.1

eglimi

I cross compile Qt for a custom device (TI AM335x). It uses eglfs as a platform, and therefore needs to link to libEGL, libGLESv2, etc.

The configuration step apparently has been changed in Qt 5.12.1, such that libraries found at configuration time are stored with absolute paths. See Issue #72903.

https://bugreports.qt.io/browse/QTBUG-72903

Now I have the problem that Qt shared objects which link to opengl libraries have absolute paths as dependencies in them.

Here is the output from readelf -d libQt5Gui.so

 0x00000001 (NEEDED)                     Shared library: [libQt5Core.so.5]
 0x00000001 (NEEDED)                     Shared library: [libz.so.1]
 0x00000001 (NEEDED)                     Shared library: [libpthread.so.0]
 0x00000001 (NEEDED)                     Shared library: [/home/work/sdk/sysroot/usr/lib/libEGL.so]
 0x00000001 (NEEDED)                     Shared library: [/home/work/sdk/sysroot/usr/lib/libIMGegl.so]
 0x00000001 (NEEDED)                     Shared library: [/home/work/sdk/sysroot/usr/lib/libsrv_um.so]
 0x00000001 (NEEDED)                     Shared library: [/home/work/sdk/sysroot/usr/lib/libGLESv2.so]
 0x00000001 (NEEDED)                     Shared library: [/home/work/sdk/sysroot/usr/lib/libGLES_CM.so]
 0x00000001 (NEEDED)                     Shared library: [/home/work/sdk/sysroot/usr/lib/libusc.so]
 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]
 0x0000000e (SONAME)                     Library soname: [libQt5Gui.so.5]

The relevant part in my mkspecs/qmake.conf file is as follows

QMAKE_LIBDIR_OPENGL_ES2 = $$[QT_SYSROOT]/usr/lib
QMAKE_LIBDIR_EGL        = $$QMAKE_LIBDIR_OPENGL_ES2

QMAKE_INCDIR_EGL        = $$[QT_SYSROOT]/usr/include
QMAKE_INCDIR_OPENGL_ES2 = $${QMAKE_INCDIR_EGL}

QMAKE_LIBS_OPENGL_ES2   = -lEGL -lIMGegl -lsrv_um -lGLESv2 -lGLES_CM -lusc
QMAKE_LIBS_EGL          = $${QMAKE_LIBS_OPENGL_ES2}

When I install the shared objects on the target device, the libraries are not found, because the path does not exist there.

From the linked issue above, It is not clear to me how I can fix this issue. Does anybody know how to resolve this?

Thanks for reading. Any suggestions are much appreciated.

SGaist

Hi,

I would try running the python script to patch Qt from https://codereview.qt-project.org/#/c/256308/ linked in the bug reported you mentioned.

eglimi

Hello @SGaist,

Thank you for the suggestion. I forgot to mention it in my original post, but I already tried that script. What it does is removing all the absolute paths from .pri, .prl, .la, .pc, and cmake files.

I'm not sure how the script will help here, since Qt5Gui is built as part of qtbase. What I do is the following sequence.

Download and unpack qtbase-everywhere-src-5.12.2.tar.xz
./configure <options>
make && make install

After this, Qt5Gui is built and has the absolute paths as dependencies as shown above. As far as I can see, the script doesn't change this. What I would need is a way to patch the shared object files after they have been built (something like patchelf for ARM). But I suspect this is not the intention, and I'm missing something else.

SGaist

From the looks of it, I think the script should be run prior to configure and build.

eglimi

These absolute paths are only constructed at configure time. Therefore, prior to configure, they are not yet there. I also tried to replace the paths between configure and build, but this didn't work either.

I'll add my issue to the Qt bug report linked above, and report back if I find any solution.

Thank you for your help!

SupervisedThinking

@eglimi @SGaist
Are there any news about this topic? Since Qt v5.12.1 & it's absolute path handling it's basically broken for all of my Mali based builds for SBCs (Amlogic S905 / Rockchip RK3399) since libQt5Gui.so is linked against the absolute path to my buildroot and after it's included in an image this path is obviously broken and libGLESv2.so is "missing". I tried now every new LTS build so 5.12.2/3/4 and it's still messed up.

Correct me if I'm wrong but this https://codereview.qt-project.org/c/qtsdk/qtsdk/+/256308 provides probably no solution for this problem since it patches the build config files afterwards to make sure other packages link against a proper path to Qt libs but this won't help us once the Qt lib itself uses a screwed up path.

eglimi

Hello @SupervisedThinking,

Unfortunately, there is no update on this topic. The absolute path handling also breaks all versions since 5.12.1 for me.

It works for Yocto based images, but not when Qt is cross compiled directly without such an environment. I'm surprised this issue doesn't come up more often or more prominently. I'm not aware of any solutions, and there is no response from Qt.

The issue is described in the following bug report. Maybe you want to add that this is a problem for you as well.

https://bugreports.qt.io/browse/QTBUG-75098

Ignacio_Alvarez

Please check if my solution in 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 is valid for your case.

SupervisedThinking

@Ignacio_Alvarez I checked my output for my Mali libs and indeed the SONAME tag is missing while Broadcom vendor libs like the bcm2835-driver have this tag and link properly. So either Qt fixes the dependency on these tags or we manually add them and fix the binaries.
The main problem is that ARM ships a single Mali lib that features everything you need for egl gbm glesv1 glesv2 and you have to create symlinks with proper names like libGLESv2.so to this file. So you can't just add a TAG to fix this you would have to copy this whole-in-one lib more than one time and patch the SONAME every single time.

arm-linux-gnueabihf-readelf output:
https://pastebin.com/MWVF2Pf1

@eglimi
Can you run arm-linux-gnueabihf-readelf -d libGLESv2.so | grep SONAME to check if SONAME is missing on your libs too?

eglimi

Hello @SupervisedThinking and @Ignacio_Alvarez,

Thank you for the information about the SONAME. I haven't thought about this. And indeed, the SONAME is missing from the libs in question in my installation as well.

I'm not sure patching the libs is the correct solution though, but it might at least provide a workaround.

SupervisedThinking

@eglimi
The problem is what will you add? The unified mali lib I use has a size of 16.8 MB so if I have to patch this lib for EGL / GBM / GLESv2 etc I'm probably not able use symlinks anymore and this will quite increase the image size.

SupervisedThinking

Well another three weeks and no news about this topic?

ruisebastiao

@eglimi as an workaround you can use patchelf with --replace-needed to fix the needed path.
in your case the command will be:

patchelf --replace-needed /home/work/sdk/sysroot/usr/lib/libEGL.so libEGL.so libQt5Gui.so

ruisebastiao

@supervisedthinking you can create multiple copies to EGL / GBM / GLESv2 etc... in the staging dir and then patch them with the soname, they will not be in target image, there will be the sym links

SupervisedThinking

@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