-
-
Notifications
You must be signed in to change notification settings - Fork 498
binary fails to load (_dl_check_map_versions) after patchelf --set-rpath #192
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
According to git bisect, this is the commit introducing the regression: c4deb5e
|
osmocom-gerrit
pushed a commit
to osmocom/osmo-ci
that referenced
this issue
Feb 14, 2020
Due to [1], we require both debian9 patchelf v0.9 and v0.10 to be available and used by osmo-gsm-teser depending on the binary to be patched. [1] NixOS/patchelf#192 Related: OS#4389 Change-Id: I28825d723b85900fb51cc5b8a9d14c6ef346e667
I confirm that the current patchelf (0.10) damages ELFs. In my use case I need to first remove rpath/runpath and then set if explicitly as rpath. This procedure damaged most of my ELFs, and I had to find workarounds to patchelf, which were tricky and time consuming. |
rpurdie
added a commit
to rpurdie/patchelf
that referenced
this issue
Jun 3, 2020
When running patchelf on some existing patchelf'd binaries to change to longer RPATHS, ldd would report the binaries as invalid. The output of objdump -x on those libraryies should show the top of the .dynamic section is getting trashed, something like: 0x600000001 0x0000000000429000 0x335000 0x0000000000335000 0xc740 0x000000000000c740 0x1000 0x0000000000009098 SONAME libglib-2.0.so.0 (which should be RPATH and DT_NEEDED entries) This was tracked down to the code which injects the PT_LOAD section. The issue is that if the program headers were previously relocated to the end of the file which was how patchelf operated previously, the relocation code wouldn't work properly on a second run as it now assumes they're located after the elf header. This change forces them back to immediately follow the elf header which is where the code has made space for them. Should fix NixOS#170 and NixOS#192 Signed-off-by: Richard Purdie <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Original ticket tacking the issue: https://osmocom.org/issues/4389
So, in summary:
I was using patchelf 0.9-1+b1 from debian9 repos, but run into issue #47 with binary "srsue" from srsLTE.git [1]:
so I then went into building/installing a new version of patchelf. I tried with following patchelf versions:
All of them fix the issue #47 on binary "srsue". However, all those new versions introduce a new bug with another binary generated by srsLTE.git [1] called "srspec". Patching itself seems to be working fine (patchelf doesn't exit with !=0), but afterwards the loader is unable to load the binary:
This issue doesn't show up with the original patchelf 0.9-1+b1 from debian9 I was using, so it's a regression added at some point after that and yet not fixed last release nor in currentmaster.
[1] https://github.com/srsLTE/srsLTE
The text was updated successfully, but these errors were encountered: