Change:
when running locally I get errors in the test : The most notable part being this: perhaps related to the linker on my system?
Compiler team pre-triage: marking as P-medium, this is probably something wacky in my local setup. We'll see if others complain about it.
I have also seen this in Fedora and RHEL builds, but I didn't worry enough to chase it down yet. This error is actually from itself: Arguments 5 and 6 from the command in your report are: -L /home/nmatsakis/versioned/rust-6/build/x8664-unknown-linux-gnu/test/run-make-fulldeps/linker-output-non-utf8/linker-output-non-utf8/zzz$'xff' That line is deliberately in the test: I have no idea why this isn't an issue in CI though...
Oh, I think I do know why. That in the Makefile is assuming shell expansion of that (with doubled to escape from itself). Fedora and RHEL use -which does expand it, but Debian and Ubuntu (used in CI) have -, which is a more limited shell. bash: dash: So I think this test hasn't really been working as desired on -using platforms at all, since the isn't really "bad" when not escaped. And it can't work even then because won't accept non-utf8 arguments in the first place, never mind reaching the linker.
Note, the and builders do use CentOS 5 as the base image, which would have this issue too, but we don't actually run tests there. It would be nice to add some diversity to the testing images, either with Fedora or perhaps the redistributable .
Any idea what to do with this test? Having to use for over two weeks isn't very practical.
We can probably just remove that test, it doesn't seem worth the pain of having it if it's causing people problems. It sounds like we don't have a test case that would work universally even on *nix platforms, right? Or that's my interpretation of at least. It's also pretty unclear to me that ICE-ing on non-utf8 output from linkers is something we need to test for. That sounds both incredibly uncommon, and also pretty easily fixable if we need to. One thought for testing this is to override the linker rustc uses with a shell script or even a rust program that runs the linker internally but just does something like or with some non-utf8 output.
This test continues to be super annoying. I'm happy to just remove it, per suggestion.
Okay I've filed to remove the test -- seems like everyone is in agreement it does not pull its weight.

Discussion:
<del> -include ../tools.mk # Make sure we don't ICE if the linker prints a non-UTF-8 error message. # ignore-windows # # This does not work in its current form on windows, possibly due to # gcc bugs or something about valid Windows paths.  See issue #29151 # for more information. # ignore-macos # # This also does not work on Apple APFS due to the filesystem requiring # valid UTF-8 paths. # The zzz it to allow humans to tab complete or glob this thing. bad_dir := $(TMPDIR)/zzz$$'xff' all: $(RUSTC) library.rs mkdir $(bad_dir) mv $(TMPDIR)/liblibrary.a $(bad_dir) $(RUSTC) -L $(bad_dir) exec.rs 2>&1 | $(CGREP) this_symbol_not_defined </del>

<del> #[link(name="library")] extern "C" { fn foo(); } fn main() { unsafe { foo(); } } </del>

<del> #![crate_type = "staticlib"] extern "C" { fn this_symbol_not_defined(); } #[no_mangle] pub extern "C" fn foo() { unsafe { this_symbol_not_defined(); } } </del>