Weird undefined symbol error after patchelf

[shlevy]

After NixOS/nixpkgs@140e1de:

strings lib/ipsec/libstrongswan.so.0.0.0 | grep XX
XXt&

Before:

$ strings lib/ipsec/libstrongswan.so.0.0.0 | grep XX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

See NixOS/nixpkgs#5045, this causes an undefined symbol error.

[dezgeg]

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.

[shlevy]

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

[solna86]

@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

[probonopd]

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.