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 <[email protected]>")
("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.

[pkgw]

Here's a variation of this issue that I've run into. See also rust#36250 and #3366.

I've been attempting to build a Rust project using the conda-forge build infrastructure. My project uses pkg-config in its build script, and the conda-forge version of pkg-config links with a conda-forge version of libiconv that's incompatible with the system version.

The crux of the problem is that when Cargo runs the build script, it's setting DYLD_LIBRARY_PATH. In particular the value is of the form:

$conda_work_dir/target/release/deps:$conda_build_environment_prefix/lib

Somehow our pkg-config ends up depending on the system libcups, which wants the system libiconv, which ends up getting pulled in as the conda-forge version of the library rather than the system version, which means that pkg-config dies:

dyld: Symbol not found: _iconv
  Referenced from: /usr/lib/libcups.2.dylib
  Expected in: /Users/travis/miniconda3/conda-bld/tectonic_1539811878682/_build_env/lib/libiconv.2.dylib
 in /usr/lib/libcups.2.dylib

This kills the build script and the build. If pkg-config is invoked with DYLD_LIBRARY_PATH unset, it works fine.

I don't understand Cargo well, but I could imagine that the bits that are responsible for cargo run are also responsible for invoking the build script.