Cargo binaries are not run in pristine environment

[nagisa]

cargo pollutes the environment with a lot of stuff, thus potentially skewing the behaviour of binaries run with cargo run and directly.

$ bash -c 'env -i PATH="$PATH" HOME="$HOME" ~/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/bin/cargo run'
     Running `target/debug/tst`
("PATH", "/home/nagisa/local/bin:/usr/bin/:/usr/sbin/::/home/nagisa/.cargo/bin/")
("HOME", "/home/nagisa")
("SSL_CERT_FILE", "/etc/ssl/cert.pem")
("SSL_CERT_DIR", "/etc/ssl/certs")
("CARGO_PKG_VERSION_MAJOR", "0")
("CARGO_PKG_VERSION_MINOR", "1")
("CARGO_MANIFEST_DIR", "/tmp/tst")
("CARGO_PKG_VERSION_PATCH", "0")
("CARGO_PKG_HOMEPAGE", "")
("CARGO_PKG_VERSION", "0.1.0")
("CARGO_PKG_AUTHORS", "Simonas Kazlauskas <git@kazlauskas.me>")
("CARGO_PKG_NAME", "tst")
("LD_LIBRARY_PATH", "/tmp/tst/target/debug:/tmp/tst/target/debug/deps")
("CARGO_PKG_VERSION_PRE", "")
("CARGO_PKG_DESCRIPTION", "")
("OUT_DIR", "/tmp/tst/target/debug/build/tst-023656d15f5dd082/out")
$ bash -c 'env -i PATH="$PATH" HOME="$HOME" ./target/debug/tst'
("PATH", "/home/nagisa/local/bin:/usr/bin/:/usr/sbin/::/home/nagisa/.cargo/bin/")
("HOME", "/home/nagisa")

Most notably, the $LD_LIBRARY_PATH may result in binaries not “just” working when run without cargo run, but also susceptible are SSL_* things. I do not see anybody removing the $LD_LIBRARY_PATH hack, but ideally all other environment variables would just not exist.

[alexcrichton]

Some of these could probably get trimmed, but I don't think it's really up to Cargo to provide a 100% "pristine environment" to run executables, to do that reliably you'd basically always want to run the executable itself first.

[matklad]

Messing with LD_LIBRARY_PATH seems especially unkind: https://users.rust-lang.org/t/subprocess-and-dynamic-library-linking-problem-interaction/7873 :)

[alexcrichton]

Note that this is required for correctness with LD_LIBRARY_PATH for many compilations. For example running plugins, etc, or when native libraries are compiled as dylibs. I'd prefer to dig into what's happening rather than just declaring bankruptcy

[matematikaadit]

So, if we do cargo install on a binary that depend on this LD_LIBRARY_PATH hack, we will got a broken binary. Is there a way to fix this? Or at least an option to tell what env variable that must be set so that we can make the binary working again.

[alexcrichton]

@matematikaadit binaries installed through cargo install which depend on dylibs in the build directories are unfortunately inherently broken as the dylibs aren't copied out (intentionally). In general binaries installed which link to dylibs need to only use system dylibs.

[dchammond]

This issue is still causing a number of annoying and unexpected behavior. For example, I got bit by this problem using arrayfire-rust. People are going to continually encounter this issue and be confused, only to end up annoyed with cargo run as a tool.

I understand from rust-lang/rust#28640 that this is not necessarily a trivial problem, but I don't think it is getting the attention it needs. Messing with environment variables does not even seem to be mentioned in the cargo docs, yet is very important for a user to be aware of.

cargo run needs at least more documentation on the main website about this issue. Hopefully it can be fixed once and for all.