Builds made with patchelf from master segfault

[probonopd]

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

[probonopd]

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

[probonopd]

I really suspect that the latest patchelf from their master repository might be crippling libQt5Core.so.5. Can anyone confirm?

[TheAssassin]

Any patchelf beyond 0.8 is broken.

[probonopd]

Any patchelf beyond 0.8 is broken.

Thanks for confirming this.

Oh wow, I had even reported this over 2 years ago:

• Running patchelf on a dynamic executable causes a segfault NixOS/patchelf#110
• patchelf cripples libQt5Core.so NixOS/patchelf#124

[probonopd]

Check out whether we could use LIEF to replace patchelf as suggested by @lkollar in NixOS/patchelf#174 (comment).

(Python) example for using LIEF to replace patchelf:
https://github.com/pypa/auditwheel/pull/187/files

[petrmanek]

@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

[petrmanek]

Quick update: yes, I just tried patchelf 0.17.2 and can confirm that it does not produce corrupted binaries

[probonopd]

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.

[TheAssassin]

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.