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.

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.

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

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.

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

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

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