Workspace binary artifacts are added to target/debug/deps on Windows #7919

Activity

1. lopopolo

   added

   C-bugCategory: bugCategory: bug

   on Feb 22, 2020
2. ehuss commented on Feb 22, 2020

   

   ehuss

   on Feb 22, 2020

   Contributor

   More actions

   This may be difficult to change or fix. Unfortunately Windows uses PATH for both shared libs (the reason Cargo sets it) and executable paths. Cargo puts the binary in both locations on all platforms, it's just on Windows it does not have a disambiguating hash (due to embedded PDB paths).

   However, I suspect executing build scripts probably shouldn't be relying on any local dynamic libraries. One could maybe scan all the crates on crates.io to see if that is the case, but usually the packages that do strange things aren't on crates.io.

   Can you say more about your use case? It seems very unusual to both create a binary that shadows a system one, and wanting to execute the original system binary from a build script.
3. lopopolo commented on Feb 22, 2020

   

   lopopolo

   on Feb 22, 2020

   Author

   More actions

   The project in question is Artichoke, a Rust implementation of The Ruby programming language. Artichoke uses system Ruby to bootstrap building the standard library.

   Artichoke produces a ruby binary to be compatible with MRI (the reference implementation) which also produces a ruby binary. Artichoke’s binary does not have feature parity with MRI. It has no notion of a load path and can not require sources from the host filesystem.

   Artichoke vendors a copy of the Ruby repository. These sources contain Ruby source files that implement the standard library. There is no reason to reimplement these for Artichoke.

   One of the build scripts in the Artichoke workspace invokes Ruby scripts with the system Ruby, setting the load path to the vendored copy of the standard lib and requires packages one at a time. The invoked Ruby script inspects the loaded constants and source file paths and hands this back to the build script. The build script renders a template for each standard library package that produces a Rust module which loads the standard library package into an Artichoke interpreter.

   👍React with 👍1Reacted by Marijn Schouten
4. ehuss

   added

   A-environment-variablesArea: environment variablesArea: environment variables

   A-build-scriptsArea: build.rs scriptsArea: build.rs scripts

   on Feb 25, 2020
5. epage

   added

   S-triageStatus: This issue is waiting on initial triage.Status: This issue is waiting on initial triage.

   O-windowsOS: WindowsOS: Windows

   on Nov 3, 2023
6. epage

   added

   S-needs-designStatus: Needs someone to work further on the design for the feature or fix. NOT YET accepted.Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.

   and removed

   S-triageStatus: This issue is waiting on initial triage.Status: This issue is waiting on initial triage.

   on Nov 6, 2025
7. epage commented on Nov 6, 2025

   

   epage

   on Nov 6, 2025

   Contributor

   More actions

   This may be resolved by #15010 because every build unit is isolated to its own directory.
8. epage

   marked Local packages can shadow system binaries due to order of PATH #13897 as a duplicate of this issue on Nov 11, 2025
9. epage commented on Nov 11, 2025

   

   epage

   on Nov 11, 2025

   Contributor

   More actions

   As #13897 points out, this doesn't just affect build scripts but the compilation process. However, that first requires you to have a rustc or related binary being built. That either means it's your project or the unstable artifact dependencies are being used.