Change:
[[package]] name = "compiler_builtins" <del> version = "0.1.24" </del> <ins> version = "0.1.25" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "b9975aefa63997ef75ca9cf013ff1bb81487aaa0b622c21053afd3b92979a7af" </del> <ins> checksum = "438ac08ddc5efe81452f984a9e33ba425b00b31d1f48e6acd9e2210aa28cc52e" </ins> dependencies = [ "cc", "rustc-std-workspace-core",

Discussion:
Hello, I'm in the process of upgrading Rust to 1.41.0 on Alpine Linux and it appears that a TEXTREL has been introduced in 1.41.0: The full build log is located here if it's of interest:
This apparently breaks Android builds, since that forbids text relocations
+1 I am one of the unfortunate winner of a release-blocking CI build failure for Android now that we've upgraded to 1.41.0. We've disabled android-x86 builds for now :(
I a minimal repro to my repository here: , in the hope that it can help debugging this (and because I was curious to dig into this myself :-) ). You can clone the repo, then In the container you can run . I bisected it using rustup and nightly releases, 2012-12-09 is good, 2019-12-10 is bad: When using nightly-2019-12-10:
Conveniently, no rollups! Auto merge of - tmandry:bump-compiler-builtins, r=alexcrichton Auto merge of - mark-i-m:fix-rustc-guide-2, r=ehuss Auto merge of - lqd:placeholder_loans, r=matthewjasper Auto merge of - estebank:issue-, r=eddyb Auto merge of - cjgillot:corrida, r=Mark-Simulacrum Auto merge of - GuillaumeGomez:move-clean-types, r=kinnison I would personally suspect . Can you try checking this via Specifically, comparing and ?
While rustup-toolchain-install-master compiles ( ): I see that upgrades compiler-builtins. I had a look at the commits in compiler-builtins which touch , and I think we can likely narrow it down to At this point I'm too much out of my depth, this needs people more knowledgeable than me . I hope I could help debugging this, and will continue watching the issue as I'm learning a great deal just by investigating this. Besides the actual fix, there are two additional things I'd love to understand: 1) why doesn't detect this?

It looks like the obj file is not marked in any way has having a TEXTREL, but maybe the inline asm from that commit defines rustprobestack in such a way that relocating it needs touching the .text section (wild guess) 2) how would we go at testing this? Where in the rust project would I add a test for this? And given that scanelf can't detect this, maybe a good way to "integration test" this would be to build a minimal rust static lib, and try to link it into a shared object with like I'm doing in the repro code. Do I understand correctly that "all code produced by rustc should be relocatable" is a guaranteed property (thus worth testing), or am I completely mistaken?
Meanwhile, I can confirm that we got the right commit ():
triage: P-high. Assigning to self. Leaving nominated because I'd like to discuss this at today's meeting.
cc who did the rollup of compiler-builtins, do we know which of the following PRs may have caused the problem rust-lang/compiler-builtins (seems pretty clearly ok) rust-lang/compiler-builtins (remapping ? seems ok) rust-lang/compiler-builtins (modernize test crate, seems ok) rust-lang/compiler-builtins (atomic intrinsics? seems ok) rust-lang/compiler-builtins (atomic intrinsics? seems ok) rust-lang/compiler-builtins (gitmodules? probably ok) rust-lang/compiler-builtins (bcmp? seems ok) rust-lang/compiler-builtins (eliminate __fltused on uefi targets?) rust-lang/compiler-builtins (FFI unsafe warnings for i128/u128) rust-lang/compiler-builtins rust-lang/compiler-builtins hypothesizes , do you know that this could be the cause,
It could be. Likely the difference is in the attributes of the probestack function (before that change it was a rust function, afterward it was defined in raw assembly). could you try adding the line around ? If that fixes it, it may break it in other environments (e.g. when generating code for a shared vs static library). We'd probably need to thread some new cfg flags through, but I'm not sure if that's actually possible. The other way is going back to defining the assembly in a naked function, but , prevented me from doing this the first time.

cc
cc (though they're on vacation this week I believe) on the inline assembly options as potentially relevant for RFC and if they have thoughts on how to fix it for this case
I would agree with the conclusion that is the most likely candidate here for a cause of the regression. That being said I have no idea what TEXTREL is, what's happening there to cause it, or how we might fix this.
Looking at the objdump output, you can see the difference between the 2019-12-09 and 2019-12-10 nightlies: The textrel happens because the has global visibility and can therefore (in theory) be overridden at runtime, e.g. with LDPRELOAD. This means that the dynamic linker will need to patch the .text section at load time to fix up the call instruction. As suggested, adding should fix the problem since the linker will then resolve references to the symbol within the shared library itself.
That's probably the correct fix then, I'm just not 100% sure it will work on all targets . If it fails we should see it in CI, though.
Will this be released in a 1.41.1, or should distros just apply this downstream? We'd very much like Rust 1.41.0 without TEXTRELs on x86.
Also, thanks for the quick fix of course :)
I would not currently wait for a 1.41.1 release. I hope that it will make it into 1.42 though.
Alright, thanks for the info.
Thanks for fixing this! I verified that this solves the issue on our end, and opened a PR with a simple regression test. The test fails on i686-unknown-linux-gnu when I revert compiler-builtins to 0.1.24.
I'm not sure this is the right place to bring it up, but without this fix it is impossible to deploy a rust static library to platforms that enforce properly-relocatable code (x86 android). It didn't make the cut for 1.41.1, is there any chance for 1.42? Can we help to make this happen? Thanks!
is beta nominated, it will be backported soon and included in 1.42 release.
Fantastic, thanks. Do you think it would be worth it to also include the regression test () in the release?

CCing the reviewers
awesome, I am waiting for a release with this fix. Any idea when 1.42 is planned?
Stable releases usually occur every 6 weeks, so it should land in ~2 weeks.
I've nominated the regression test as well!