From 4b5b6223c5b77b9c0db1f3ff28c79800841c9643 Mon Sep 17 00:00:00 2001 From: Fenrir Date: Fri, 7 Jul 2017 12:21:12 -0600 Subject: [PATCH] ctru-rs: workaround for xargo/sysroot issue Both our implementation of std and ctru-rs depend on the libc crate (or rather, ctru-rs depends on ctru-sys which depends on libc). This means that libc ends up both in the sysroot assembled by Xargo, as well as being built as a regular dependency for ctru-rs. However, it seems that when cargo/rustc tries to link the libc crate to ctru-rs, it first searches in the sysroot and links in the copy that it finds there, rather than the one specified in ctru-rs's Cargo.toml. rust-lang's rustbuild system does some trickery with crate metadata to avoid this sort of name collision between the sysroot and user deps, but xargo does not (yet) do something similar. And since rustc now enforces that linking to any crate from the sysroot is an unstable operation, the result is a rather cryptic compiler error. Fortunately we can work around this by simply tagging ctru-rs with #![feature(rustc_private)], but it shouldn't be regarded as a long-term fix --- ctru-rs/src/lib.rs | 3 +++ 1 file changed, 3 insertions(+) diff --git a/ctru-rs/src/lib.rs b/ctru-rs/src/lib.rs index 10132a0..355c59f 100644 --- a/ctru-rs/src/lib.rs +++ b/ctru-rs/src/lib.rs @@ -1,6 +1,9 @@ #![crate_type = "rlib"] #![crate_name = "ctru"] +// Temporary workaround for a Xargo(?) issue +#![feature(rustc_private)] + #[macro_use] extern crate bitflags; extern crate widestring;