Rustc produces shared objects rather than executables
Closed this issue · 3 comments
Running file on Rust executables produces this output:
/usr/local/bin/rustc: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
Executables produced by other compilers, such as Clang and GCC, have a different result:
/usr/lib/llvm-3.5/bin/clang: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=28da30b6a880213e65f2b23b6ff53776a35d35cb, stripped
/usr/bin/gcc-4.9: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=d182242d47da0d32e551a92278787b7b4375c417, stripped
The result of this difference is that while executing Rust programs from the command line works fine, opening them through GUI file managers produces this error, which is the same as when you try to open shared libraries (.so):
This issue is present in all Rust executables I have encountered, including those obtained from rustup.sh.
Your file manager is buggy and doesn't know how to run executables with ASLR support. It's using the output of file or libmagic which will detect relocatable executables as shared objects. There's nothing Rust can do about that.
Rust defaults to producing position independent executables to enable ASLR. This can be enabled with gcc or clang by using -fPIE to build object files and -pie to link them and is the default on some distributions. The gcc and clang default can be replicated with rustc using -C dynamic-no-pic but it's not likely that you want that.
Here's the file / libmagic bug:
Thanks for the link. Hopefully this issue will be resolved soon.