Change:
# preserve existing RUSTFLAGS env.setdefault("RUSTFLAGS", "") <ins> # we need to explicitly add +xgot here so that we can successfully bootstrap # a usable stage1 compiler # FIXME: remove this if condition on the next bootstrap bump # cfg(bootstrap) if self.build_triple().startswith('mips'): env["RUSTFLAGS"] += " -Ctarget-feature=+xgot" </ins> target_features = [] if self.get_toml("crt-static", build_section) == "true": target_features += ["+crt-static"]

Discussion:
The error mesage is: Not sure yet if there is a bug behind this. Posting this here just in case. What happens is that we hit the limit of 8K GOT entries per single object file. I've tried using 1.25 instead of 1.26 as bootstrap compiler and the bootstrap build passes with offending object file having ~7K symbols needing GOT entry. I haven't been able to find exact reason for this. At first glance, while it sound counterintuitive, it seems that we have more inlining on 1.26 which pulls in more symbol references. I was able to sidestep this by increasing opt-level for bootstrap build to 3. As a stopgap, is it ok to provide and option to to build bootstrap tool in release mode ? I can send the PR.
cc -- marking a stable/stable regression. I'm not sure what could cause this (bootstrap is fairly small).
visiting for triage. Some notes, in part to self: mips64 is a tier 2 platform. We support building the tools (but not testing them) for such platforms ... and unfortunately we are doing such building via cross-compiles, so our continuous-integration system didn't catch whatever caused the build of bootstrap to start failing. Marking at P-medium for now. I think we would be happy to look at any PR you provide that gives a way to sidestep the issue you are facing as long as it does not change the default behavior....
suggests that you should use if you see "relocation truncated to fit" errors.
Add -mxgot with cc command ?It seems not usefull ... export RUSTFLAGS=-Clink-arg=-mxgot ? It seems not pass to linker .... <mock-chrootsh-4.4# ls -l lrwxrwxrwx 1 root root 3 Jul 20 00:44 /usr/bin/cc -gcc <mock-chrootsh-4.4# cat /usr/bin/cc #!/bin/bash exec -mxgot -Wa,-xgot $@ <mock-chrootsh-4.4# Output mock's
I haven't tested it but I think you should use RUSTFLAGS="-C llvm-args=-mxgot". Edit: Also note that bootstrap tool build sets its own RUSTFLAGS .

Add this line in the .spec file: And RPMs were built successful .
With this patch, rustc can build on mips64el.
Is this needed all the time? (What's special about the bootstrap process?) If it's needed all the time, perhaps rustc should always be passing that flag to LLVM? In which case the change should be made to a more internal file, only applies when compiling rustc itself.
(By "all the time" I mean "including when compiling other rust programs not the rustc compiler to mips")
I think what's special about rustc is that it is compiled with dynamic linking. Rust defaults to static linking, and for static linking is irrelevant and ignored. But rustc is compiled with dynamic linking, IIRC, for compiler plugins. I think always passing to LLVM is okay, since it won't affect most Rust builds which use static linking.
But static linking will affected too because the use of GOT is tied to use of PIC code on Mips platform I'd rather not do this by default or at least limit its use to debug builds. In the end it is a crutch that it's used when number of GOT entries per object exceeds 8K/16K on mips64 and mips32 respectively. Because the problem right now is limited to building of the bootstrap tool and nothing else (Actually I'm not sure for tests because I've run them with optimize-tests=true) I thought of adding of new env variable like BOOTSTRAP_RUSTFLAGS that will allow the users to control RUSTFLAGS for bootstrap tool build. About what is special about bootstrap process (except that is always built in debug mode) I don't know. I didn't have time to look into it thoroughly. Will post if I find something.
Ah yes, it's PIC, not dynamic linking. On the other hand, do we build static linking with PIC?
Don't know for sure but it looks that choice of relocation-model is orthogonal to the choice of linking. I believe the -linux- targets default to PIC which should cover all cases. There are some limitation in practice tho. For example the relocation-model=static code on mips64 cannot participate in dynamic linking.

MIPS SVR4 ABI insist all userspace codes use PIC, even static linking, for GNU/MIPS, there is an extension for exec to use non-pic(since exec loaded at fixed position), which only works on N32/O32 ABI;
it worked like a charm
Hi everyone involved in the discussion, ~While certainly has its performance downsides~ The patch seems to affect only, it might be in our interest to fix bootstrap upstream instead of all carrying the same patch separately. Just confirmed yesterday with (yesterday's) that we only have two testcases failing: - This is on a Loongson 3A4000 box running Gentoo (the Gentoo CHOST is actually different but it doesn't matter). How about we just go ahead and apply the workaround to EDIT: realized the flag setting is only for building and not the main compiler
Something about 1.46.0 (current beta) is breaking this patch: ~
seems to work.
We are running into this problem now for the cargo build - . The error messages are from the hashbrown crate, although I am having trouble reproducing it on a different mips64el machine. I am thinking of just adding "+xgot" to and not having to worry about this problem in random rust crates in the future, because it is going to be a maintenance annoyance otherwise. What are the specific performance problems, and what would "the proper solution" be and who is supposed to work on it? Someone in LLVM?
GOT loads with need more instructions. That might or might not be a problem, actually, considering the mips platforms are already slow by modern standards; and I originally meant that should be turned on globally only as a last measure. It might be possible to generate code like is unconditionally on, then relax and relocate things during linking wherever it turns out to be unnecessary. But I imagine that to be enormous toolchain work and unlikely to pan out in the short- and mid-term. So I'm afraid turning on globally is the only sensible choice.
I agree with xen0n. We meet more and more packages in Debian needing xgot. And I think that is is a reasonable choice to enable xgot globally.
I might need some time to setup a local benchmark environment, as I haven't been doing much rustc development lately. Who's going to own the work?
Thanks for the explanation.

Setting this feature unconditionally is just a 1-line patch which I am happy to apply in Debian, it is trivial work and I can own that. Or did you mean you wanted to do more things like testing?
I'd prefer to benchmark rustc's performance before and after the global switch, if somehow we could successfully build rustc without the patch (might have to do the benchmark with a previous version of rustc). Or popular applications (think and such) could be benchmarked for the real-world performance impact of global . This benchmark work is not meant to block the one-liner PR, though. It's just a suggestion to help fellow developers on MIPS better understand the situation.
OK that makes sense. Currently in Debian we are successfully building rustc without the global switch, and to my knowledge we are only applying it for the rustc builder program ("bootstrap"/"x.py") and now cargo 0.47. So, I could apply the global switch to the current version of rustc in Debian so you can compare the same version 1.48.0 with (1.48.0-dfsg1-2) or without the switch (1.48.0-dfsg1-1). They will remain available on even after the next upgrade pushes them out of the main Debian archive. If you want to benchmark other programs, I guess it might be possible to disable the feature (after the global switch) with ? Although I never tried this myself.
Sure, thanks for the information! Yes that's the way to do it. I'm not quite sure if linking with built with different setting would work though; last time I investigated was long ago.
Did anyone ever investigate this? We are still patching in +xgot on Debian which makes a recently-enabled test () fail: <details<summaryfailures</summaryerror: no match found 64: .set at check:105'0 check:105'1 ?

possible intended match 69: daddu 3, $gp check:105'0 70: ld 3) check:105'0 ~~ 71: ld 3) check:105'0 ~ 72: · check:105'0 ~ 73: .set pop check:105'0 ~ </detailsAccording to this difference is exactly what is expected when +xgot is enabled, so for now I will disable this test in Debian.
Uhh... Does someone want to send in a PR? A few different solutions have been proposed by now and it's not actually clear which one is the necessary/desired one.