patchelf --set-interpreter fails with `cannot find section ` about patchelf

[puffnfresh]

@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 👍

[robinp]

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 patchelf --set-interpreter foo bar, you can do foo bar.

[offlinehacker]

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> .

[rlupton20]

I just did a horrible thing but got it to work. One day I'll craft a proper solution, but for the moment I

• downloaded the binary to my home directory
• symlinked the dynamic linker with an absolute file name the same length as the one in the elf header
• edited the elf header in vim to use the symlink as interpreter

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!

[steshaw]

I ran into this problem today and for anyone who comes by here, I had to install nixpkgs.patchelfUnstable to get it working.

[offlinehacker]

I have same error, also go binary.

[pmahoney]

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:

# build static binary
CGO_ENABLED=0 go build -v -a -tags netgo -installsuffix netgo <package>

see golang/go#9369 (comment)

But of course this won't help programs that do need to link to libc.

[chris-martin]

I'm having the same problem. The Go binary in question is Otto (64-bit).

[aaronlevin]

👍 I'm also hitting this issue with an internal library (distributed as a binary) that is very simple.

[aaronlevin]

I hit this issue again and tried patchelf-0.9, still no luck.

[puffnfresh]

Same situation as above.

[thearchitect]

Same patchelf error for binaries built with golang 1.6

[edolstra]

The otto binary gives:

cannot find section .interp

which is a different problem than the original report, i.e.

cannot find section 

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.

[sleexyz]

Same error here:

binary in question is ngrok

pretty sure it is a go-packaged binary, but it is closed source so I can't rebuild it myself

> patchelf --set-interpreter /nix/store/y5js9j7zgrmz4j2dqcy0nvaqyk3izbv7-glibc-2.24/lib64/ld-linux-x86-64.so.2 --debug ngrok
patching ELF file `ngrok'
Kernel page size is 4096 bytes
replacing section `.interp' with size 82
this is an executable
using replaced section `.interp'
last replaced is 2
looking at section `'
replacing section `' which is in the way
looking at section `.interp'
first reserved offset/addr is 0xc00/0x400c00
first page is 0x400000
needed space is 656
clearing first 2504 bytes
cannot find section 

> readelf -e ngrok
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x486020
  Start of program headers:          64 (bytes into file)
  Start of section headers:          568 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         9
  Size of section headers:           64 (bytes)
  Number of section headers:         33
  Section header string table index: 11

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .text             PROGBITS         0000000000400c00  00000c00
       000000000042facf  0000000000000000  AX       0     0     16
  [ 2] .plt              PROGBITS         00000000008306e0  004306e0
       0000000000000170  0000000000000010  AX       0     0     4
  [ 3] .rodata           PROGBITS         0000000000831000  00431000
       0000000000388af0  0000000000000000   A       0     0     32
  [ 4] .typelink         PROGBITS         0000000000bb9af0  007b9af0
       0000000000001c30  0000000000000000   A       0     0     8
  [ 5] .gosymtab         PROGBITS         0000000000bbb720  007bb720
       0000000000000000  0000000000000000   A       0     0     1
  [ 6] .gopclntab        PROGBITS         0000000000bbb720  007bb720
       00000000001a24e4  0000000000000000   A       0     0     32
  [ 7] .rela             RELA             0000000000d5dc10  0095dc10
       0000000000000018  0000000000000018   A      14     0     8
  [ 8] .gnu.version      VERSYM           0000000000d5dc40  0095dc40
       0000000000000038  0000000000000002   A      14     0     2
  [ 9] .gnu.version_r    VERNEED          0000000000d5dc80  0095dc80
       0000000000000040  0000000000000000   A      12     2     8
  [10] .hash             HASH             0000000000d5dcc0  0095dcc0
       0000000000000090  0000000000000004   A      14     0     8
  [11] .shstrtab         STRTAB           0000000000000000  0095dd60
       0000000000000185  0000000000000000           0     0     1
  [12] .dynstr           STRTAB           0000000000d5df00  0095df00
       0000000000000189  0000000000000000   A       0     0     1
  [13] .rela.plt         RELA             0000000000d5e0a0  0095e0a0
       0000000000000210  0000000000000018   A      14     2     8
  [14] .dynsym           DYNSYM           0000000000d5e2c0  0095e2c0
       00000000000002a0  0000000000000018   A      12     0     8
  [15] .got              PROGBITS         0000000000d5f000  0095f000
       0000000000000008  0000000000000008  WA       0     0     8
  [16] .got.plt          PROGBITS         0000000000d5f020  0095f020
       00000000000000c8  0000000000000008  WA       0     0     8
  [17] .dynamic          DYNAMIC          0000000000d5f100  0095f100
       0000000000000130  0000000000000010  WA      12     0     8
  [18] .noptrdata        PROGBITS         0000000000d5f240  0095f240
       000000000001878c  0000000000000000  WA       0     0     32
  [19] .data             PROGBITS         0000000000d779e0  009779e0
       000000000000c1d0  0000000000000000  WA       0     0     32
  [20] .bss              NOBITS           0000000000d83bc0  00983bc0
       0000000000009ce0  0000000000000000  WA       0     0     32
  [21] .noptrbss         NOBITS           0000000000d8d8a0  0098d8a0
       00000000000149c8  0000000000000000  WA       0     0     32
  [22] .interp           PROGBITS         0000000000400be4  00000be4
       000000000000001c  0000000000000000   A       0     0     1
  [23] .symtab           SYMTAB           0000000000000000  00984000
       0000000000055608  0000000000000018          24   197     8
  [24] .strtab           STRTAB           0000000000000000  009d9608
       000000000007888b  0000000000000000           0     0     1
  [25] .tbss             NOBITS           0000000000000000  00000000
       0000000000000010  0000000000000000 WAT       0     0     8
  [26] .debug_abbrev     PROGBITS         0000000000000000  00a51e93
       00000000000000fd  0000000000000000           0     0     1
  [27] .debug_line       PROGBITS         0000000000000000  00a51f90
       00000000000533e6  0000000000000000           0     0     1
  [28] .debug_frame      PROGBITS         0000000000000000  00aa5376
       000000000006cc14  0000000000000000           0     0     1
  [29] .debug_info       PROGBITS         0000000000000000  00b11f8a
       00000000001c8d26  0000000000000000           0     0     1
  [30] .debug_pubnames   PROGBITS         0000000000000000  00cdacb0
       0000000000086302  0000000000000000           0     0     1
  [31] .debug_pubtypes   PROGBITS         0000000000000000  00d60fb2
       0000000000035536  0000000000000000           0     0     1
  [32] .debug_aranges    PROGBITS         0000000000000000  00d964e8
       0000000000000030  0000000000000000           0     0     1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  l (large), p (processor specific)

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x0000000000400040 0x0000000000400040
                 0x00000000000001f8 0x00000000000001f8  R      1000
  INTERP         0x0000000000000be4 0x0000000000400be4 0x0000000000400be4
                 0x000000000000001c 0x000000000000001c  R      1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x0000000000000040 0x0000000000400040 0x0000000000400040
                 0x0000000000430810 0x0000000000430810  R E    1000
  LOAD           0x0000000000431000 0x0000000000831000 0x0000000000831000
                 0x000000000052d560 0x000000000052d560  R      1000
  LOAD           0x000000000095f000 0x0000000000d5f000 0x0000000000d5f000
                 0x0000000000024bc0 0x0000000000043268  RW     1000
  DYNAMIC        0x000000000095f100 0x0000000000d5f100 0x0000000000d5f100
                 0x0000000000000130 0x0000000000000130  RW     8
  TLS            0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000010  R      8
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     8
  PAX_FLAGS      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000         8

 Section to Segment mapping:
  Segment Sections...
   00     
   01     .interp 
   02     .text .plt .interp 
   03     .rodata .typelink .gosymtab .gopclntab .rela .gnu.version .gnu.version_r .hash .dynstr .rela.plt .dynsym 
   04     .got .got.plt .dynamic .noptrdata .data .bss .noptrbss 
   05     .dynamic 
   06     .tbss 
   07     
   08

[vikstrous]

Same issue with the minio binary client. Building from scratch myself worked as expected.

[rlupton20]

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).

[ezquat]

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, (off_t) rdi(hdr->e_shoff) >= startOffset'. With patchelf 0.9 you get cannot find section , which is referring to the section with the empty name, which is some kind of dummy placeholder in ELF files, at section index 0.

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++ sort() which can move the entry at index 0, in the case where some other entry also has offset 0 (which is the case for Go binaries, a .tbss section has offset 0). It is easy to skip entry 0 in the sort. Then another problem kicks in, which is that patchelf tries to overwrite some bytes (with 'X's) at that offset 0, even though the .tbss section is marked as NOBITS and thus has no content.

I'm not totally confident in this area, but I'd like to offer my fix.

[ezquat]

See PR #149.

[kuznero]

Same with argo-cd go binary ;(

[iMichka]

#149 was merged. This issue can be closed.

[offlinehacker]

@steshaw you had issues with 0.10 version?

[steshaw]

@offlinehacker I checked the versions: nixpkgs.patchelf is 0.9 and I had to install the unstable version which reports 0.10-pre-20190328. This worked fine for me.

[offlinehacker]

Yeah 0.10 is still not merged in nixpkgs

[maxmcd]

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

patching ELF file `/go/bin/go'
Kernel page size is 4096 bytes
replacing section `.interp' with size 108
this is an executable
using replaced section `.interp'
last replaced is 3
looking at section `'
replacing section `' which is in the way
looking at section `.note.go.buildid'
replacing section `.note.go.buildid' which is in the way
looking at section `.interp'
first reserved offset/addr is 0x1000/0x401000
first page is 0x400000
needed space is 840
clearing first 3472 bytes
cannot find section

Using patchelf version 0.12