linuxdeployqt
linuxdeployqt copied to clipboard
Builds made with patchelf from master segfault
Builds that use patchelf
from their git master segfault. Difference seems to be in libQt5Core. See https://github.com/probonopd/linuxdeployqt/releases/tag/de6d873. Why? Is the latest patchelf
crippling it?
cc @TheAssassin
I notice that the two builds contain different patchelf
versions, so possibly that has to do with it? I'm genuinely confused and it's too late today...
me@host:~$ GOOD/squashfs-root/usr/bin/linuxdeployqt
linuxdeployqt 6 (commit de6d873), build 672 built on 2019-04-10 05:52:44 UTC
me@host:~$ cp GOOD/squashfs-root/usr/lib/libQt5Core.so.5 BAD/squashfs-root/usr/lib/
me@host:~$ BAD/squashfs-root/usr/bin/linuxdeployqt
linuxdeployqt 6 (commit 32bf3de), build 676 built on 2019-04-24 23:01:23 UTC
I really suspect that the latest patchelf
from their master repository might be crippling libQt5Core.so.5
. Can anyone confirm?
Any patchelf beyond 0.8 is broken.
Any patchelf beyond 0.8 is broken.
Thanks for confirming this.
Oh wow, I had even reported this over 2 years ago:
- https://github.com/NixOS/patchelf/issues/110
- https://github.com/NixOS/patchelf/issues/124
Check out whether we could use LIEF to replace patchelf
as suggested by @lkollar in https://github.com/NixOS/patchelf/issues/174#issuecomment-520609300.
(Python) example for using LIEF to replace patchelf
:
https://github.com/pypa/auditwheel/pull/187/files
@probonopd I just encountered this on the latest Ubuntu Focal with patchelf
0.18.0.
It appears that linuxdeployqt
attempts to strip and set rpath of one of the XCB libraries, which somehow corrupts the file to the point that ld.so
does not recognize it anymore. Here is my minimal example that you can run e.g. in a docker container in a temporary directory:
cp /lib/x86_64-linux-gnu/libxcb-image.so.0 .
ldd libxcb-image.so.0
linux-vdso.so.1 (0x00007ffcde5e9000)
libxcb-shm.so.0 => /lib/x86_64-linux-gnu/libxcb-shm.so.0 (0x00007f1b1a17e000)
libxcb-util.so.1 => /lib/x86_64-linux-gnu/libxcb-util.so.1 (0x00007f1b19f78000)
libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f1b19f4e000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1b19d5c000)
libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007f1b19d56000)
libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f1b19d4e000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1b1a39b000)
libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f1b19d32000)
patchelf --set-rpath \$ORIGIN libxcb-image.so.0
ldd libxcb-image.so.0
not a dynamic executable
The last output causes linuxdeployqt
not to find any dependencies, so that when it accesses the first dependency libraries[0]
of an empty list on this line it SEGFAULTs due to assertion failure.
This appears to be related to this issue upstream. I have already reported my findings there. It may be a regression since 0.17.2, which seems to be the latest unaffected version of patchelf
. I will try to confirm that and report back
Quick update: yes, I just tried patchelf
0.17.2 and can confirm that it does not produce corrupted binaries
TheAssassin commented on Apr 30, 2019
Any patchelf beyond 0.8 is broken.
So for now I'd say avoid any patchelf version above 8.0.
Later patchelf versions have seen some fixes indeed. However, at the moment, I don't have any problems just using 0.8. So I'll keep using that until something breaks.