-
-
Notifications
You must be signed in to change notification settings - Fork 498
patchelf --set-interpreter fails with cannot find section
#66
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
I have same error, also go binary. |
For anyone encountering this problem, if your go program can be compiled as a purely static library (doesn't need to link to libc or any other c library), this worked for me:
But of course this won't help programs that do need to link to libc. |
I'm having the same problem. The Go binary in question is Otto (64-bit). |
👍 I'm also hitting this issue with an internal library (distributed as a binary) that is very simple. |
I hit this issue again and tried |
Same situation as above. |
Same patchelf error for binaries built with golang 1.6 |
The
which is a different problem than the original report, i.e.
PR #95 may fix the latter, but it's not clear to me whether skipping sections with empty names (which is not necessarily the same as an empty section) is the right thing to do. |
Same error here: binary in question is pretty sure it is a go-packaged binary, but it is closed source so I can't rebuild it myself
|
The heroku tool has changed and now downloads a binary to do bulk of the work. This PR also downloads the binary to wrap it properly, but due to NixOS/patchelf#66 we cannot ```patchelf``` the binary and it doesn't work. So for now we instead wrap it in a buildFHSUserEnv so at least things are working again. Once the patchelf issue has been solved, I'll update this again.
Same issue with the minio binary client. Building from scratch myself worked as expected. |
There's one positive thing about this issue, more go packages are built
from source for nix :)
…On Thu, Dec 15, 2016, 12:17 PM Viktor Stanchev ***@***.***> wrote:
Same issue with the minio binary client. Building from scratch myself
worked as expected.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#66 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAjvSwmxG0LPvpVz1G9NI4XZprEPAWoEks5rISG0gaJpZM4F-fzi>
.
|
@purefn came up with this nice solution: { stdenv }:
stdenv.mkDerivation rec {
name = "example";
src = example.tar.gz;
phases = [ "unpackPhase" "installPhase" ];
installPhase = ''
mkdir -p $out/bin
cp example $out/bin/example.wrapped
echo $(< $NIX_CC/nix-support/dynamic-linker) $out/bin/example.wrapped \"\$@\" > $out/bin/example
chmod +x $out/bin/example
'';
} Which runs the linker with the binary instead of patching the binary to use the linker. Pretty cool 👍 |
The above trick works for standalone plugins, but I'm hitting this now trying to get a terraform plugin (which is again just a go binary) to work. Running from the terminal is fine, but it crashes out when terraform tries to use it (which is perhaps not terribly surprising). |
I just did a horrible thing but got it to work. One day I'll craft a proper solution, but for the moment I
Seems to work, good enough for the moment, and perhaps another useful trick for anyone rolling by here who needs to get out of a tight spot! |
I encountered this problem also, with a Go biniary, and I think I have some form of "fix" for patchelf. To recount the problem symptoms: with patchelf 0.8 you get an assertion failure, Here's my understanding of the bug: Most of the code in patchelf ignores the first entry in the section header table, but there is a call to C++ I'm not totally confident in this area, but I'd like to offer my fix. |
… and not overwriting NOBITS entries.
… and not overwriting NOBITS entries.
See PR #149. |
Same with argo-cd go binary ;( |
Fix issue #66: ignore 0th section header when sorting, don't overwrite NOBITS
#149 was merged. This issue can be closed. |
… and not overwriting NOBITS entries.
I ran into this problem today and for anyone who comes by here, I had to install |
@steshaw you had issues with 0.10 version? |
@offlinehacker I checked the versions: nixpkgs.patchelf is 0.9 and I had to install the unstable version which reports |
Yeah 0.10 is still not merged in nixpkgs |
Quick hack if it helps: you can invoke the dynamic interpreter with the program as the argument, to get it running at least... So instead |
I'm still getting this issue when trying to patch the latest version of Go: https://golang.org/dl/go1.15.3.linux-amd64.tar.gz
Using patchelf version 0.12 |
I have a binary compiled with the Go 1.4 compiler from
nixpkgs
, and I'd like to run it outside of a nix environment, so I'm trying to patch the interpreter.patchelf 0.8 gives the following error:
Which I think was fixed in pull 39.
I built a patchelf from master @ 63296c4, and I now get a different error:
headers:
The text was updated successfully, but these errors were encountered: