Weird undefined symbol error after patchelf about patchelf HOT 4 CLOSED

Huh, interesting. The binary has an import for a symbol named lib:

   228: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  UND lib

and the DT_RUNPATH entry value ends in lib:

[/nix/store/gflcr9v02x8248p061jpjyfrbzxmhsn9-strongswan-5.5.2/lib/ipsec:/nix/store/gflcr9v02x8248p061jpjyfrbzxmhsn9-strongswan-5.5.2/lib64:/nix/store/gflcr9v02x8248p061jpjyfrbzxmhsn9-strongswan-5.5.2/lib:/nix/store/w0djd8vbmjxkwdd8vi7xiy16cymlxh4c-gcc-5.4.0/libexec/gcc/x86_64-unknown-linux-gnu/5.4.0:/nix/store/izxnyg94352qxa4a4783dzgnpy5cwazj-glibc-2.25/lib:/nix/store/ayyq8sq4hf4psmk4jqj5jyfskd7fa1xx-gcc-5.4.0-lib/lib]

So I think the linker decided to save some space by pointing the lib symbol table entry to the last 3 bytes of the string in DT_RUNPATH! Then, when we shrink the RPATH we overwrite the old RPATH with Xs and thus the imported symbol name gets mangled as well.

I suppose that instead of overwriting the entire RPATH with X, we only remove the hash parts (like nuke-refs does) in the old RPATH.

from patchelf.

Please open a new issue if someone wants to pursue this.

from patchelf.

@shlevy Any idea if this issue has been fixed?

I had to migrate all my development setup because some R packages cannot be built.

Another user reports the same issue here: https://discourse.nixos.org/t/shared-object-error-in-rpackages-seurat/211

from patchelf.

I can confirm that patchelf 0.10 cripples ELFs with XXXXX. patchelf 0.9 did not suffer from this. So maybe a bisect is needed to find out which commit exactly broke this.

from patchelf.