Regression in 0.18.0: --set-rpath creates broken header alignment

[mika-fischer]

Describe the bug

Using --set-rpath with 0.18.0 creates a broken header alignment. Using the patched library leads to error while loading shared libraries: libcudart.so.11.0: ELF load command address/offset not properly aligned. 0.17.2 works fine

Steps To Reproduce

patchelf-regression.zip

> cp libcudart.so.11.8.89.orig libcudart.so.11.8.89 && patchelf --set-rpath '$ORIGIN' libcudart.so.11.8.89
> readelf -Wl libcudart.so.11.8.89
[...]
Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
[...]
  LOAD           0x0a6000 0x0000000000400000 0x0000000000400000 0x003da0 0x003da0 RW  0x200000
[...]

Note that VirtAddr-Offset does is not aligned by Align

Expected behavior
0.17.2 produces

> readelf -Wl libcudart.so.11.8.89
[...]
Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
[...]
  LOAD           0x0a6000 0x00000000002a7000 0x00000000002a7000 0x003da0 0x003da0 RW  0x1000
[...]

Note that VirtAddr-Offset does is aligned by Align

patchelf --version output

patchelf 0.18.0

[mika-fischer]

Might be related to #475

[petrmanek]

I can see a very similar issue in the latest Ubuntu Focal with patchelf 0.18.0 compiled from source. It seems that a call to --set-rpath somehow corrupts the ELF binary to the point where ld.so no longer recognizes it as a dynamic executable. That being said, even though my symptoms fit the description above I am uncertain whether this is due to header alignment. I will try to confirm this and get back.

In the meantime, here is my minimal example that you can try e.g. in a Docker container:

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

I am attaching a side-by-side diff of objdump -x of the patched ELF binary: diff_set_rpath.txt

[RJVB]

Still an issue with HEAD...

[kvoronin]

Any updates on this? We've hit this bug in the context of creating wheels for a project (we used patchelf 0.18.0 and the library was compiled with gcc < 12, not sure if the latter matters)

[adam-azarchs]

I wonder if 0e33894 might fix this? It doesn't seem like anyone's actually paying attention to this issue, even though it's been making what's been the latest release of patchelf for years now essentially broken.

[blochl]

I also encountered this issue when running on older .deb-based distros (Ubuntu 20.04, Debian 10) on Ubuntu 22.04 and Debian 11 this was not manifested. On all the distros it was version 0.18.0, compiled from source. Switching to 0.17.2 solved it.

[RJVB]

On Wednesday December 18 2024 05:10:34 blochl wrote: I also encountered this issue when running on older .deb-based distros (Ubuntu 20.04, Debian 10) on Ubuntu 22.04 and Debian 11 this was not manifested.

Should we read the latter part as meaning the issue doesn't occur on newer distros, i.e. presumably with newer ld.so (= libc)? If ELF specs have evolved, patchelf should also, but IMHO ideally with dynamic detection of whatever spec is supported by the system it runs on. Or at the very least via compile-time logic.