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

SGaist · wrote on 9 Apr 2019, 20:45

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 · wrote on 10 Apr 2019, 06:47

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 · 11 Apr 2019, 06:07

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

eglimi · S SGaist 10 Apr 2019, 21:51

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 · wrote on 19 Jun 2019, 17:49

@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 · wrote on 20 Jun 2019, 07:11

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 · 20 Jun 2019, 10:51

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 · wrote on 20 Jun 2019, 10:51

@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 · 20 Jun 2019, 12:30

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 · 30 Aug 2019, 23:39

@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 · wrote on 11 Jul 2019, 12:50

Well another three weeks and no news about this topic?

ruisebastiao · E eglimi 20 Jun 2019, 12:26

@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 · 2 Sept 2019, 23:14

@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 · 9 Mar 2019, 11:31

@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