-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade GCC to 8.3.0, glibc to 1.17.0 and crosstool-ng to 1.24.0 for dist-armv7-linux #65302
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
CT_BINUTILS_PKG_NAME="binutils" | ||
CT_BINUTILS_SRC_RELEASE=y | ||
CT_BINUTILS_PATCH_ORDER="global" | ||
CT_BINUTILS_V_2_32=y |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Binutils change default settings from time to time.
Upgrading them for other targets often resulted in errors on older distributions because they cannot understand newer features (like compressed debuginfo).
@bors: r+ Thanks so much for tracking this down @msizanoen1! We can continue to iterate on toolchain issues if they crop up, but getting working toolchains is likely the most important part of this :) |
📌 Commit e2ce082 has been approved by |
in case this works, is the release team willing to push out a possible 1.38.1, or do we have to wait for 1.39.0 or even 1.40.0? |
I think I would personally not feel comfortable backporting this to beta, and definitely not to stable -- it seems like the chance of breakage in edge case ways is too high to not let this bake. But I've not been following along too closely -- is this platform entirely broken today? i.e., presumably if beta as is is just entirely not working and this helps make it work for some cases, then it may make sense to backport as we are definitely improving things. |
The problem is that everyone either sticks to the upstream stage0 rust via rustup or using install.sh from the stage0, or to their distros rust which is bootstrapped all the way from a stage0 too. I think @cuviper , you're the fedora maintainer of the rust package, do you know wether fedora's armv7 port is affected by #62896 ? |
I'm not aware of any problems on Fedora, but we also build most of our packages with codegen-units=1 already, trading compile time for hopefully better optimization. I should try reproducing the issue directly, but if newer glibc/gcc solve it, we're probably clear already. We've been steady using our own stage0 for a while now, not needing upstream binaries, so the official builds haven't affected us. |
@stefson stage0 isn't anything magical, it's just Rust's beta release (for official binaries). Building Rust itself works because it's cross compiled from x86_64 Linux distribution. IMO in worst case backporting this to beta will make cross compilation of crates to ARMv7 not possible from host with very old cross- Binutils/GCC. At same time it can fix running Rust natively on ARMv7 Linux distributions (at least those with recent enough toolchain). |
I somewhat disagree here -- this is a sort of "fundamental" change and I could see this exposing issues that are new to us. It also seems like if we've not shipped a working stable for a while, in some sense the urgency in my eyes is also reduced. But I can definitely also see the perspective that we should backport this. Beta backports in this case I think would fall on the infra team, and maybe (though probably not) the compiler team. So nominating as such for their approval. |
@alexcrichton I forgot that crosstool-ng 1.24.0 requires unzip. I am closing and reopening this. |
@alexcrichton I pushed some change to this PR. You may need to r+ again. |
@bors: r+ |
📌 Commit e58ad8d has been approved by |
@bors: r+ |
Upgrade GCC to 8.3.0, glibc to 1.17.0 and crosstool-ng to 1.24.0 for dist-armv7-linux #62896 was caused by the usage of the GCC 5.2.0 toolchain, which was released back in 2015 and may have bugs affecting LLVM 9. This PR upgrade GCC to 8.3.0 from 5.2.0, glibc from 1.16.0 to 1.17.0 and crosstool-ng to 1.24.0 only for dist-armv7-linux. Fixes #62896 r? @alexcrichton
☀️ Test successful - checks-azure |
We discussed this at today's infrastructure meeting and decided to approve the backport! @rustbot modify labels: beta-accepted |
…crichton Upgrade GCC to 8.3.0, glibc to 1.17.0 and crosstool-ng to 1.24.0 for dist-armv7-linux rust-lang#62896 was caused by the usage of the GCC 5.2.0 toolchain, which was released back in 2015 and may have bugs affecting LLVM 9. This PR upgrade GCC to 8.3.0 from 5.2.0, glibc from 1.16.0 to 1.17.0 and crosstool-ng to 1.24.0 only for dist-armv7-linux. Fixes rust-lang#62896 r? @alexcrichton
[beta] backport rollup This includes a bunch of PRs: * Fix redundant semicolon lint interaction with proc macro attributes #64387 * Upgrade async/await to "used" keywords. #64875 * syntax: fix dropping of attribute on first param of non-method assocated fn #64894 * async/await: improve not-send errors #64895 * Silence unreachable code lint from await desugaring #64930 * Always mark rust and rust-call abi's as unwind #65020 * Account for macro invocation in `let mut $pat` diagnostic. #65123 * Ensure that associated `async fn`s have unique fresh param names #65142 * Add troubleshooting section to PGO chapter in rustc book. #65402 * Upgrade GCC to 8.3.0, glibc to 1.17.0 and crosstool-ng to 1.24.0 for dist-armv7-linux #65302 * Optimize `try_expand_impl_trait_type` #65293 * use precalculated dominators in explain_borrow #65172 * Fix ICE #64964 #64989
[beta] backport rollup This includes a bunch of PRs: * Fix redundant semicolon lint interaction with proc macro attributes #64387 * Upgrade async/await to "used" keywords. #64875 * syntax: fix dropping of attribute on first param of non-method assocated fn #64894 * async/await: improve not-send errors #64895 * Silence unreachable code lint from await desugaring #64930 * Always mark rust and rust-call abi's as unwind #65020 * Account for macro invocation in `let mut $pat` diagnostic. #65123 * Ensure that associated `async fn`s have unique fresh param names #65142 * Add troubleshooting section to PGO chapter in rustc book. #65402 * Upgrade GCC to 8.3.0, glibc to 1.17.0 and crosstool-ng to 1.24.0 for dist-armv7-linux #65302 * Optimize `try_expand_impl_trait_type` #65293 * use precalculated dominators in explain_borrow #65172 * Fix ICE #64964 #64989 * [beta] Revert "Auto merge of #62948 - matklad:failable-file-loading, r=petro… #65273 * save-analysis: Don't ICE when resolving qualified type paths in struct members #65353 * save-analysis: Nest tables when processing impl block definitions #65511 * Avoid ICE when checking `Destination` of `break` inside a closure #65518 * Avoid ICE when adjusting bad self ty #65755 * workaround msys2 bug #65762
Upgrade GCC to 8.3.0, glibc to 2.17.0 and crosstool-ng to 1.24.0 for dist-arm-linux and dist-armhf-linux Attempt to fix rust-lang#69420 in the same manner as rust-lang#65302 did for armv7l. I have tested that this eliminates the segfault while building a `hello_world` package on `arm-unknown-linux-gnueabihf`. I have not been able to test whether the bug exists for `arm-unknown-linux-gnueabi` as well, but I suspect it does, so I upgraded the toolchain for that platform as well.
#62896 was caused by the usage of the GCC 5.2.0 toolchain, which was released back in 2015 and may have bugs affecting LLVM 9.
This PR upgrade GCC to 8.3.0 from 5.2.0, glibc from 1.16.0 to 1.17.0 and crosstool-ng to 1.24.0 only for dist-armv7-linux.
Fixes #62896
r? @alexcrichton