Compiled binary uses relative RPATH to multiruse
Opened this issue · 2 comments
When compiling a small rust program with multirust (using stable rust), the resulting binary embed a relative RPATH (which is used for dynamic lib locating), as seen with objdump (look for the RPATH line):
$ objdump -p target/debug/varf
target/debug/varf: file format elf64-x86-64
Program Header:
PHDR off 0x0000000000000040 vaddr 0x0000000000000040 paddr 0x0000000000000040 align 2**3
filesz 0x00000000000001f8 memsz 0x00000000000001f8 flags r-x
INTERP off 0x0000000000000238 vaddr 0x0000000000000238 paddr 0x0000000000000238 align 2**0
filesz 0x000000000000001c memsz 0x000000000000001c flags r--
LOAD off 0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**21
filesz 0x0000000000561134 memsz 0x0000000000561134 flags r-x
LOAD off 0x0000000000561140 vaddr 0x0000000000761140 paddr 0x0000000000761140 align 2**21
filesz 0x000000000002c501 memsz 0x000000000002d800 flags rw-
DYNAMIC off 0x000000000058ca10 vaddr 0x000000000078ca10 paddr 0x000000000078ca10 align 2**3
filesz 0x0000000000000260 memsz 0x0000000000000260 flags rw-
NOTE off 0x0000000000000254 vaddr 0x0000000000000254 paddr 0x0000000000000254 align 2**2
filesz 0x0000000000000044 memsz 0x0000000000000044 flags r--
TLS off 0x0000000000561140 vaddr 0x0000000000761140 paddr 0x0000000000761140 align 2**4
filesz 0x00000000000000e8 memsz 0x00000000000000e8 flags r--
EH_FRAME off 0x0000000000449c4c vaddr 0x0000000000449c4c paddr 0x0000000000449c4c align 2**2
filesz 0x000000000002c31c memsz 0x000000000002c31c flags r--
STACK off 0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**4
filesz 0x0000000000000000 memsz 0x0000000000000000 flags rw-
Dynamic Section:
NEEDED libssl.so.1.0.0
NEEDED libcrypto.so.1.0.0
NEEDED libdl.so.2
NEEDED libpthread.so.0
NEEDED libgcc_s.so.1
NEEDED librt.so.1
NEEDED libc.so.6
NEEDED ld-linux-x86-64.so.2
NEEDED libm.so.6
RPATH $ORIGIN/../../../../.multirust/toolchains/stable/lib/rustlib/x86_64-unknown-linux-gnu/lib:/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib
INIT 0x0000000000036648
FINI 0x00000000004026d0
INIT_ARRAY 0x0000000000761228
INIT_ARRAYSZ 0x0000000000000010
FINI_ARRAY 0x0000000000761238
FINI_ARRAYSZ 0x0000000000000008
GNU_HASH 0x0000000000000298
STRTAB 0x0000000000001370
SYMTAB 0x00000000000002c0
STRSZ 0x0000000000000a60
SYMENT 0x0000000000000018
DEBUG 0x0000000000000000
PLTGOT 0x000000000078ccb8
PLTRELSZ 0x0000000000000f78
PLTREL 0x0000000000000007
JMPREL 0x00000000000356d0
RELA 0x0000000000002088
RELASZ 0x0000000000033648
RELAENT 0x0000000000000018
VERNEED 0x0000000000001f38
VERNEEDNUM 0x0000000000000006
VERSYM 0x0000000000001dd0
RELACOUNT 0x000000000000223c
Version References:
required from librt.so.1:
0x09691a75 0x00 15 GLIBC_2.2.5
required from libdl.so.2:
0x09691a75 0x00 10 GLIBC_2.2.5
required from ld-linux-x86-64.so.2:
0x0d696913 0x00 09 GLIBC_2.3
required from libgcc_s.so.1:
0x09276060 0x00 13 GCC_4.2.0
0x09275a60 0x00 12 GCC_4.0.0
0x0b792653 0x00 11 GCC_3.3
0x0b792650 0x00 07 GCC_3.0
0x09265f61 0x00 05 GCC_3.3.1
required from libc.so.6:
0x06969194 0x00 16 GLIBC_2.14
0x09691974 0x00 14 GLIBC_2.3.4
0x06969198 0x00 08 GLIBC_2.18
0x09691972 0x00 06 GLIBC_2.3.2
0x09691a75 0x00 03 GLIBC_2.2.5
required from libpthread.so.0:
0x09691972 0x00 04 GLIBC_2.3.2
0x09691a75 0x00 02 GLIBC_2.2.5
Though DYLD_LIBRARY_PATH appears to be correctly set to an absolute path:
$ multirust run stable bash -c 'echo $DYLD_LIBRARY_PATH'
/home/gyscos/.multirust/toolchains/stable/lib:
This simple program happen to not need any of these dynamic libraries, but for other, bigger ones that do rely on these libraries, using relative RPATH obviously lead to dynamic linking error after moving the binary (a concrete example of that is rusti).
Is this a multirust issue or a rust one? Or is it just my installation?
EDIT: apparently people just don't like rpaths, and want us to set LD_LIBRARY_PATH instead. Oh well. Any way to easily add the current toolchain to this path?
This is the behavior of the -C rpath flag to the compiler. It's known to be kinda buggy, though once upon a time it encoded both the relative and absolute paths in an attempt to make things just work.
Because it's unreliable across platforms there's a bug open to just disable it completely.
I'd be open to having a command that sets the LD_LIBRARY_PATH correctly via source, e.g. source multirust env nightly.
Oh, also multirust run will set up the environment correctly.