Compiled binary uses relative RPATH to multiruse

[gyscos]

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?

[brson]

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.

[brson]

Oh, also multirust run will set up the environment correctly.