3

I would like to package a binary file for use with NixOS. For it to work I have to change the interpreter by patchelf to link to one inside the nix store. So far so good. The binary also has shared libraries, but I get a strange error message if I use patchelf's --set-rpath option followed by the : concatenated list of library paths: 

./result/bin/exe: ./result/bin/exe: no version information available (required by ./result/bin/exe)
./result/bin/exe: ./result/bin/exe: no version information available (required by ./result/bin/exe)
./result/bin/exe: ./result/bin/exe: no version information available (required by ./result/bin/exe)
./result/bin/exe: ./result/bin/exe: no version information available (required by ./result/bin/exe)
./result/bin/exe: ./result/bin/exe: no version information available (required by ./result/bin/exe)
...
./result/bin/exe: relocation error: ./result/bin/exe: symbol , version  not defined in file  with link time reference

(I removed some of the repeating lines)

I have found questions asked on stackoverflow regarding the first error, which should not cause any trouble (linked library doesn't contain version information, while the executable defines what version it wants), although what I find strange is that the name of the libraries are missing. The problem is the next line, I found similar error messages saying that maybe a different version of gcc could solve the problem, but again, missing library names. The command I use is patchelf --interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)" --set-rpath /nix/store/qt-4.8.7/lib:/nix/store/zlib-1.2.11/lib:/nix/store/gcc-6.4.0-lib/lib:/nix/store/libSM-1.2.2/lib:/nix/store/libICE-1.0.9/lib:/nix/store/libX11-1.6.5/lib:/nix/store/libXext-1.3.3/lib:/nix/store/libXt-1.1.5/lib:/nix/store/mesa-17.1.6/lib exe (with the long hashes removed).

The strange thing is that I can get the program to run by creating a wrapper that sets LD_LIBRARY_PATH to the exact same thing I try to do with patchelf (I still have to change the interpreter but that causes no problem.), but this is not the solution I want.. What should I try to do next?

FloriOn
  • 245
  • 1
  • 12

1 Answers1

1

I recently encountered this problem. It seems to be happening if you call strip -g on the binary on which you ran patchelf. In fact, strip gives the following warning

warning: allocated section `.dynsym' not in segment

My binary seems to be working fine if I don't run strip on it.

EDIT: The problem seems to be happening only when the new rpath value is longer than the old one.

Rahul
  • 759
  • 6
  • 11