Description of problem: patchelf is causing problems in the binaries I'm building in Fedora 41. This is just a Hello World C++ minimal example. Steps: g++ -o hello hello.cpp ./hello Hello, World! patchelf --set-rpath '/usr/lib' ./hello # Any path fails ./hello Segmentation fault (core dumped) Version-Release number of selected component: glibc-2.40-3.fc41 Additional info: reporter: libreport-2.17.15 type: CCpp reason: ld-linux-x86-64.so.2 killed by SIGSEGV journald_cursor: s=02e83006d5204f07a5ebc3923a974cca;i=3344;b=1152881fc7104a8b8a49ee9ad3d4b085;m=70fd05f;t=624a837a513de;x=63c72174d54c2168 executable: /usr/lib64/ld-linux-x86-64.so.2 cmdline: /lib64/ld-linux-x86-64.so.2 ./hello cgroup: 0::/user.slice/user-1000.slice/user/app.slice/run-rc55269c30d94470db711df38bc2b2f17.scope rootdir: / uid: 1000 kernel: 6.11.3-300.fc41.x86_64 package: glibc-2.40-3.fc41 runlevel: N 5 dso_list: /usr/lib64/ld-linux-x86-64.so.2 glibc-2.40-3.fc41.x86_64 (Fedora Project) 1726097924 backtrace_rating: 4 crash_function: elf_setup_debug_entry Truncated backtrace: Thread no. 1 (6 frames) #0 elf_setup_debug_entry at ../sysdeps/generic/dl-debug.h:30 #1 dl_main at rtld.c:1823 #2 _dl_sysdep_start at ../sysdeps/unix/sysv/linux/dl-sysdep.c:141 #3 _dl_start_final at rtld.c:494 #4 _dl_start at rtld.c:581 #5 _start
Created attachment 2052459 [details] File: proc_pid_status
Created attachment 2052460 [details] File: maps
Created attachment 2052461 [details] File: limits
Created attachment 2052462 [details] File: environ
Created attachment 2052463 [details] File: open_fds
Created attachment 2052464 [details] File: mountinfo
Created attachment 2052465 [details] File: os_info
Created attachment 2052466 [details] File: cpuinfo
Created attachment 2052467 [details] File: exploitable
Created attachment 2052468 [details] File: backtrace
This is a bug in patchelf. It should error out instead of producing a corrupt binary. Note that patchelf cannot work reliably in general because it needs to edit allocated sections, and that's not something that was build into the ELF format when it was designed.
Out of curiosity are there any features missing in the static linker or dynamic linker that make you look at patchelf as a solution? In general we try to provide enough features in the system toolchain to enable developers to do all the things the need to do to build applications. In some instances patchelf gets used to work around buildsystems not accepting build flags or incorrectly built binaries being corrected e.g. python3-meson-python, auditwheel.
The problem appeared when building different libraries with VCPKG, where I created the first issue: https://github.com/microsoft/vcpkg/issues/41576 I'm not a maintainer of VCPKG, just a user, but, if I'm not wrong, patchelf is used to adjust the created binaries, correcting them in some way, probably to make them easier to distribute. We found the problem while testing the beta of Fedora 41, in other Fedora versions and other Linux distros all is working ok.
(In reply to aagmega from comment #13) > The problem appeared when building different libraries with VCPKG, where I > created the first issue: https://github.com/microsoft/vcpkg/issues/41576 > I'm not a maintainer of VCPKG, just a user, but, if I'm not wrong, patchelf > is used to adjust the created binaries, correcting them in some way, > probably to make them easier to distribute. > > We found the problem while testing the beta of Fedora 41, in other Fedora > versions and other Linux distros all is working ok. OK, this is in the same class of usage as pip and auditwheel, where the "thin" package manager is working around "Build System Integration" by using patchelf. Thank you for the reference. Patchelf certainly shouldn't be generating corrupt binaries, but there is an underlying desire to be able to adjust where binaries look for their dependencies, it's just that this is in conflict with the flexibility that developers have with their build systems :-)
Reported upstream: https://github.com/NixOS/patchelf/issues/568
Possibly related: bug 2321588
This problem is definitely a bug in patchelf. It is rearranging the segments in the patched binary and ends up assigning the dynamic segment to the wrong loadable segment. The bug is triggered by the fact that the linker is now using defaulting to a different code layout, one which patchelf does not expect. As a workaround reverting to the old layout solves the problem: $ g++ hello.cpp -Wl,-z,noseparate-code $ patchelf --set-rpath --set-rpath '/usr/lib' a.out $ ./a.out Hello World
Err, sorry there is a typo in the patchelf command. It should be: $ patchelf --set-rpath '/usr/lib' a.out
Applying the -Wl,-z,noseparate-code workaround helped developers of my application on Fedora 41 work around the patchelf bug from the vcpkg dependency side. Is there a reason not to push the binutils patch from https://bugzilla.redhat.com/show_bug.cgi?id=2321588 that was applied to rawhide up to Fedora 41 as well? Or is the intention to wait for the patchelf developers to come up with their own fix and apply that to F41? vcpkg: https://github.com/microsoft/vcpkg/issues/41576 ladybird: https://github.com/LadybirdBrowser/ladybird/issues/2149
(In reply to Andrew Kaster from comment #19) > Is there a reason not to push the binutils patch from > https://bugzilla.redhat.com/show_bug.cgi?id=2321588 that was applied to > rawhide up to Fedora 41 as well? Yes - that "patch" is really just a temporary workaround. Plus it breaks GDB. More specifically it stops GDB from being able to automatically locate a separate debug info file associated with a core dump. Thus when users attempt to use GDB to inspect a core, there is a lot less information available. > Or is the intention to wait for the > patchelf developers to come up with their own fix and apply that to F41? That is my hope. My concern is that if I change the linker, then there will no incentive for the patchelf people to fix the real problem. Sooner or later this same problem is going to arise again, so fixing patchelf now would be the best course of action. At least in my opinion.
This message is a reminder that Fedora Linux 41 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 41 on 2025-12-15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '41'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 41 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 41 entered end-of-life (EOL) status on 2025-12-15. Fedora Linux 41 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.