Unsolved Absolute paths to EGL library in libQt5Gui.so since Qt 5.12.1
-
From the looks of it, I think the script should be run prior to configure and build.
-
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!
-
@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.
-
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.
-
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.
-
@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 runarm-linux-gnueabihf-readelf -d libGLESv2.so | grep SONAMEto check if SONAME is missing on your libs too? -
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.
-
@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. -
Well another three weeks and no news about this topic?
-
@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 -
@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
-
@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.
