This fixes the panic issue (not calling `panic_count::increase`) as well
as the missing debug info. The static lib contained a second copy of the
rust std, which caused these issues.
A side effect of removing this std is that the linker fix and pthread
library modules need to be "reachable" from the main module for Rust to
link them correctly. If the init methods of the modules are not called
somewhere, then a linker error will be emitted saying some symbols are
not found. The linker fix module didn't need this before because the
std included in the pthread static lib required those symbols, so they
were included. Now that the std is linked in later, Rust thinks these
symbols are unused (hence the init method).
Also moved the linker fix to be a dependency on ctru-rs. ctru-sys should
just be about interfacing with libctru.
The only real use for thread names is so that they appear in panic messages. However, names set by this API won't appear in panic messages because we aren't `std::thread` and therefore don't have access to `sys_common::thread_info` where libstd stashes its thread names. So without that functionality, there's not much of a reason to have thread names at all.
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
Andrea Ciliberti