Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cargo binaries are not run in pristine environment #2888

Closed
nagisa opened this issue Jul 17, 2016 · 7 comments · Fixed by #7565
Closed

Cargo binaries are not run in pristine environment #2888

nagisa opened this issue Jul 17, 2016 · 7 comments · Fixed by #7565
Labels
A-documenting-cargo-itself Area: Cargo's documentation A-environment-variables Area: environment variables A-linkage Area: linker issues, dylib, cdylib, shared libraries, so C-bug Category: bug Command-run

Comments

@nagisa
Copy link
Member

nagisa commented Jul 17, 2016

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
Copy link
Member

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
Copy link
Member

matklad commented Nov 3, 2016

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

@alexcrichton
Copy link
Member

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
Copy link

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
Copy link
Member

@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
Copy link

dchammond commented Mar 17, 2017

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.

@carols10cents carols10cents added A-linkage Area: linker issues, dylib, cdylib, shared libraries, so A-documenting-cargo-itself Area: Cargo's documentation A-environment-variables Area: environment variables C-bug Category: bug Command-run labels Sep 26, 2017
MarcusCalhoun-Lopez added a commit to macports/macports-ports that referenced this issue Mar 30, 2018
Use DYLD_FALLBACK_LIBRARY_PATH instead of DYLD_LIBRARY_PATH
Without this change, --target fails
see https://users.rust-lang.org/t/subprocess-and-dynamic-library-linking-problem-interaction/7873
see rust-lang/cargo#2888
@pkgw
Copy link
Contributor

pkgw commented Oct 18, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-documenting-cargo-itself Area: Cargo's documentation A-environment-variables Area: environment variables A-linkage Area: linker issues, dylib, cdylib, shared libraries, so C-bug Category: bug Command-run
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants