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 fails in Linux chroot without /proc #4450

Closed
apaprocki opened this issue Aug 30, 2017 · 6 comments
Closed

Cargo fails in Linux chroot without /proc #4450

apaprocki opened this issue Aug 30, 2017 · 6 comments
Labels
A-build-execution Area: anything dealing with executing the compiler C-bug Category: bug Command-build O-linux OS: Linux

Comments

@apaprocki
Copy link

...
running: /tmp/rust-1.19-1.19.0-0/build/x86_64-unknown-linux-gnu/stage0/bin/cargo build \
    --manifest-path /tmp/rust-1.19-1.19.0-0/src/bootstrap/Cargo.toml --verbose
error: couldn't get the path to cargo executable

This is due to this code:

    pub fn cargo_exe(&self) -> CargoResult<&Path> {
        self.cargo_exe.get_or_try_init(||
            env::current_exe().and_then(|path| path.canonicalize())
            .chain_err(|| "couldn't get the path to cargo executable")
        ).map(AsRef::as_ref)
    }

Which ultimately calls this code:

#[cfg(any(target_os = "linux", target_os = "android", target_os = "emscripten"))]
pub fn current_exe() -> io::Result<PathBuf> {
    let selfexe = PathBuf::from("/proc/self/exe");
    if selfexe.exists() {
        ::fs::read_link(selfexe)
    } else {
        Err(io::Error::new(io::ErrorKind::Other, "no /proc/self/exe available. Is /proc mounted?"))
    }
}

Is the project open to modifying this logic to allow the full path to the executable to be specified via config or environment variable if /proc intentionally does not exist?

Something along the lines of CARGO_EXE or [build] cargo = "/path/to/cargo"...

@alexcrichton
Copy link
Member

Hm I sort of forget at this point what we're even using that for. Maybe we can just remove the dependence on calling current_exe?

@carols10cents carols10cents added A-build-execution Area: anything dealing with executing the compiler C-bug Category: bug Command-build O-linux OS: Linux labels Oct 3, 2017
@kivikakk
Copy link
Contributor

@alexcrichton found it! #3778 (comment)

Maybe we could use a method other than env::current_exe for this case? Or just let the user specify CARGO and check if that's present, and if so, use it instead of calling current_exe?

@kivikakk
Copy link
Contributor

I need to read more context first. We're only setting this for external subcommands so we don't use it ourselves per se, but yeah; we could just check if it's set already and not do anything if so, letting the environment propagate.

@kivikakk
Copy link
Contributor

Example of the latter at #4634.

bors added a commit that referenced this issue Oct 26, 2017
Use argv[0] for cargo_exe so we don't rely on /proc on Linux

This is a proposed solution to #4450. I'm not at all wedded to the idea or the code, though, so feel free to shoot it down with abandon if this isn't something that'd work out or that you like.

In short, we use the existing `CARGO_ENV` (`"CARGO"`) if present, and only if not do we attempt to perform a lookup with `env::current_exe()` ourselves. This means users without access to `current_exe` (such as Linux without `procfs` mounted) can supply the `CARGO` env var themselves for external commands to use.

My concern here is: what if maybe we intentionally switch cargo binaries and didn't intend for this to happen? Could this ever happen outside a test environment? This kind-of-sorta-happened by accident in the test suite, necessitating the explicit removal of `CARGO_ENV` from the subprocess environment, because the actual cargo executing the test suite propagated its own path into the test subprocess!

/cc @alexcrichton as the originator of the idea of `CARGO_ENV`
@stale
Copy link

stale bot commented Sep 19, 2018

As there hasn't been any activity here in over 6 months I've marked this as stale and if no further activity happens for 7 days I will close it.

I'm a bot so this may be in error! If this issue should remain open, could someone (the author, a team member, or any interested party) please comment to that effect?

The team would be especially grateful if such a comment included details such as:

  • Is this still relevant?
  • If so, what is blocking it?
  • Is it known what could be done to help move this forward?

Thank you for contributing!

(The cargo team is currently evaluating the use of Stale bot, and using #6035 as the tracking issue to gather feedback.)

If you're reading this comment from the distant future, fear not if this was closed automatically. If you believe it's still an issue please leave a comment and a team member can reopen this issue. Opening a new issue is also acceptable!

@stale stale bot added the stale label Sep 19, 2018
@stale
Copy link

stale bot commented Oct 19, 2018

As I didn't see any updates in 30 days I'm going to close this. Please see the previous comment for more information!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-build-execution Area: anything dealing with executing the compiler C-bug Category: bug Command-build O-linux OS: Linux
Projects
None yet
Development

No branches or pull requests

4 participants