I’m trying to write a Nix package for a closed-source, precompiled binary with an unusual twist. The binary is statically-linked, but it contains an embedded binary that is dynamically-linked. Is there some way I can use patchelf or another tool to path the interpreter path in the embedded binary?

The embedded binary does not have any runtime library dependencies, but it does need an interpreter which it expects at the hard-coded path /lib64/ld-linux-x86-64.so.2. It is embedded using the golang “embed” library.

I have a workaround that wraps the binary using buildFHSEnv. That works, but the resulting closure is about 300 MB bigger than it needs to be.

    • hallettj@leminal.spaceOPEnglish
      1·
      2 days ago

      That’s a good point! The string is in there, and I can see it with strings. But in my research so far it’s looking like making a simple string substitution might not be an option. The replacement string would be a Nix store path which would be longer. That would shift over subsequent bytes in the binary which it sounds like would produce alignment issues that would break things.

      Apparently it’s ok to change the length of the ELF header, which is what patchelf does. But shifting bytes in the ELF body is a problem.

      Now what I haven’t verified yet is whether the embedded binary is in the body or in the header. If it’s in the header - or even if just the interpreter string is in the header then I might be good to go.