Adjust libstd to make non-Rust dependencies optional
nagisa opened this issue · 8 comments
Cross-compiling C dependencies is a major pain. The only such dependency libstd has currently to the best of my knowledge is backtrace-sys. I would much rather have an easy time building libstd without an ability to produce backtraces than having to fiddle getting full toolchain set-up for a thing as obscure as, say, netbsd.
FWIW, here's the libstd feature config that Miri uses to avoid any C dependencies. Since rust-lang/backtrace-rs#297 landed, that avoids any C dependency, and we have CI on the Miri side to ensure this remains the case.
Another problem is that libstd by default is built as rlib and dylib, and building a dylib also usually requires a target toolchain. However, std-aware cargo might already work around this, I am not sure. (Miri works around this by only doing a check-build of libstd.)
However, std-aware cargo might already work around this, I am not sure.
There is a hack in Cargo to force it to skip the dylib. You even commented on it. 😜 Ideally there would be first-class support for that, but that is off-topic.
Ah lol, my memory is getting worse it seems. ;)
But good to hear that that will not be a problem! That solution is not accessible to Miri, but we have our own solution, so that's okay.
At this point, std now uses gimli rather than libbacktrace.
Triage: Given that the only C dependency has been replaced with a Rust dependency, can this be closed or is the underlying issue still worth solving?
I'd say the underlying issue has been solved -- even working backtraces requires no non-Rust dependency.
linux-musl still requires a C compiler (and I think fortanix-sgx does, too). I'm not sure if there needs to be 100% coverage for all targets, but I'm not sure where to draw the line.
linux-musl still requires a C compiler (and I think fortanix-sgx does, too). I'm not sure if there needs to be 100% coverage for all targets, but I'm not sure where to draw the line.
I'm working on refactoring libunwind and the c/c++ part will not link into libunwind.rlib ( by kind = "static-nobundle" or kind = "static", modifiers = "-bundle" from linking modifiers rfc), It will copy to self-contained directory by rustbuild. If we handle #46 properly , the linker will use libunwind.a either from old self-contained directory or provided by system, and unwind crate don't need c/c++ compiler to compile. rust-lang/rust#85600