Philipp Oppermann

I finally had some time to take a closer look at @Freax13's proposal at . I think it looks quite promising: - It avoids the `dereferenceable` problem by using only...

(I also tried to [remove the two `as usize` casts](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=2ef2393299e42c208c18a5b31ab3c46c) and instead cast pointers directly. This fixes the "integer-to-pointer cast" warnings in miri, but leads to a stacked-borrows error: ```...

Thanks for the explanation! > The problem with casting a reference to a pointer directly is that under stacked borrows the provenance of new pointer is the same the old...

You could try setting the [`XBUILD_SYSROOT_PATH` environment variable](https://github.com/rust-osdev/cargo-xbuild#environment-variables). I agree that it might make sense to consider the `CARGO_TARGET_DIR` environment variable too for placing the sysroot. However, there are some...

Sorry for the late reply! I'm not sure if `cargo-xbuild` is at fault here. I've never seen this error, but it seems like `rustc -vV` is the command that fails....

Sure, I'm happy to merge PRs for additional subcommands. When forking xargo I tried to minimize functionality as much as possible (e.g. remove configurability, support for building std, support for...

Interesting idea. We could extend rustup to support `rustup target add path/to/your/target.json`, which rebuilds the sysroot for that target and adds it to its global sysroot. On `rustup update`, rustup...

@james-darkfox You mean automatically compiling the target if it is not part of the sysroot already?

Sounds reasonable. Maybe open a thread on https://internals.rust-lang.org/ or an issue at https://github.com/rust-lang-nursery/rustup.rs to hear what the rust/rustup devs think about your idea?

> If they have an issue with the added complexity, it might be better to just have an xargo/xbuild that does only the libcore-etc without trying to do cargo's job....