2
votes

Compiling rust on Linux with rustc or cargo build produces a shared library instead of an executable file.
My file manager (thunar) and file command show that file type as shared library.

And the compiled binary can only be executed via terminal by $ /path/to/file or $ cargo run.
That file cannot be executed just by double clicking as other executables can be.
Output from file command:

$ file rust_bin

rust_bin: ELF 64-bit LSB shared object, x86_64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=cb8cd... , with debug_info, not stripped`

3
Please show what exact commands you are running and what exact messages they produce.n. 1.8e9-where's-my-share m.

3 Answers

11
votes
  1. Your compiler produces an executable file. There is no big difference between a shared library and a dynamically linked executable file. They follow the same basic format. The string interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0 indicates that this is an executable and not a library. Libraries don't normally have an interpreter set. Try running file on some files you know are executables, and some other files you know are libraries, and see for yourself. An interpreter is usually a small system program that loads and executes a shared object. A file can actually serve as both a library and an executable at the same time (the most common example is your libc.so.6 or whatever it is called on your system; try running it).
  2. If you can run this executable from your shell but not from your file manager, the problem is with the file manager, not with the executable. You may have to specifically instruct the file manager that your program should run in a terminal. This usually can be done by creating a .desktop file that describes your program. In addition, desktop tools may mis-recognise modern executables as shared libraries. This is a common problem. It too can be remedied by creating a .desktop file for your executable. It is not specific to rust in any way.

Bottom line, there's nothing wrong with rustc or cargo or the way you are running them.

1
votes

When you create your project initially you can simply use cargo new (or init) to get the right type

cargo new my_project_name
# OR create a lib project
cargo new --lib my_library_name

when you use rustc you can use a command-line option

rustc lib.rs
# lib.rs has to contain a main function
# OR to build a lib
rustc --crate-type=lib lib.rs

Your finding about shared object is misleading your error hunt: https://askubuntu.com/questions/690631/executables-vs-shared-objects - it's not a problem, an executable can be a shared object.

I think in your case the problem is another. What does you binary do? Does basically just print something via stdout and that's it? Maybe this is the reason why double clicking in the gui file browser does not show you anything, it runs a millisecond and is over before you know it.

Have you tried waiting for input at the end of the main function? Just so that the user can read the output and hit Return key.

use std::io;
fn main() {
    // do and print stuff

    // Wait for return key
    let mut input = String::new();
    match io::stdin().read_line(&mut input);
}

Not sure how thunar will deal with it but eventually he will open a terminal and show the result and close the terminal when enter is pressed.

-1
votes
cargo build

creates an executable file in target/debug/rust_bin Then just

./target/debug/hello_cargo # or .\target\debug\hello_cargo.exe on Windows

to execute, or just

cargo run

PS: you need to create a Cargo.toml file with the appropriate data inside.