-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Comments
Hm I sort of forget at this point what we're even using that for. Maybe we can just remove the dependence on calling |
@alexcrichton found it! #3778 (comment) Maybe we could use a method other than |
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. |
Example of the latter at #4634. |
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`
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:
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! |
As I didn't see any updates in 30 days I'm going to close this. Please see the previous comment for more information! |
This is due to this code:
Which ultimately calls this code:
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"
...The text was updated successfully, but these errors were encountered: