heroku fails to run due to invalid interpreter

[peterhoeg]

Issue description

The heroku package is broken immediately after installation as the package it downloads has an invalid interpreter set.

Additionally, the ld-linux-x86-64.so.2 symlink is not present in /run/current-system/sw/lib (this may be a different issue)

Steps to reproduce

First install nix-env -i heroku

Then:

$ heroku
Installing Heroku Toolbelt v4... done.
For more information on Toolbelt v4: https://github.com/heroku/heroku-cli
Error running: /home/peter/.local/share/heroku/cli/bin/heroku with [/home/peter/.heroku/heroku-cli version]
panic: no such file or directory

<the trace has been cut - not relevant>

Notice the interpreter:

$ file ~/.local/share/heroku/cli/bin/heroku
file /home/peter/.local/share/heroku/cli/bin/heroku: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, not stripped

If I then try to set the interpreter using patchelf, I get an error about a missing section:

$ patchelf --set-interpreter /nix/store/pv9sza1cf2kpawck7wbwdnhlip5h57lg-glibc-2.23/lib/ld-linux-x86-64.so.2 heroku                                                             ~/.local/share/heroku/cli/bin
cannot find section

And furthermore, the ld-linux-x86-64.so.2 symlink is not present in /run/current-system/sw/lib (this may be a different issue).

The only way I can get heroku to run, is to manually make a symlink in /lib64 to the ld-linux-x86-64.so.2 file in the nix store. Heroku then runs.

Technical details

• NixOS: 16.09.git.01f57df (Flounder)
• Nix: nix-env (Nix) 1.11.2
• nixpkgs: "16.09pre79453.32b7b00"

cc: @aflatter @mirdhyn

[joachifm]

The patchelf issue looks like NixOS/patchelf#66. An alternative to creating a symlink is to invoke the interpreter directly, as in /path/to/ld.so heroku $*.

[peterhoeg]

The heroku "binary" is really a ruby wrapper, so we need we dig into the ruby code to find the part where the go binary is being called and then prefix that with the correct interpreter. Looks a little bit messy to me...

[peterhoeg]

Actually, it looks more like the heroku package is a ruby script that then downloads a go binary, which then depending on which subcomming is being called, either handles it itself or calls back out to another program (the binary with the invalid interpreter). Yikes. Which kind of makes me wonder if this actually ever worked?

[ocharles]

Sure, it certainly did work - but I think the change is that they are now depending on heroku-cli, and that's what has changed. Previously, I believe everything was just handled by the ruby script... the ruby script that would download node.js and occasionally break there, but that's another story.

[peterhoeg]

That makes sense @ocharles. So now 2 questions come to mind:

1. is there a proper NixOS way to set up the symlink in /lib64 ?
2. or should we instead compile and package heroku-cli the NixWay so we can fix the interpreter properly?

[mythmon]

Any updates here?

[rexim]

Any updates here?

[peterhoeg]

I have a PR #18532 that should fix it, but until NixOS/patchelf#66 is fixed, we cannot patch the downloaded binary.

If you want a temporary workaround, create a symlink in /lib64 to /nix/store/whatever-glibc-is-called-glibc-2.24/lib/ld-linux-x86-64.so.2.

[peterhoeg]

Closing this as things are now working using buildFHSUserEnv. If anyone is still having issues, let me know.

[rasendubi]

@peterhoeg the wrapper script does not seem to pass any command line arguments, so heroku is useless now. (might be worth a separate issue, but I'm in a hurry.)

[rasendubi]

Submitted a fix: #22338

[peterhoeg]

I have a proper fix without the ugly wrapper script. 5 min.

[peterhoeg]

@rasendubi, can you try out that PR? It also solves the psql issue.