danalbert added a comment. In D95166#2529412 <https://reviews.llvm.org/D95166#2529412>, @dmajor wrote:
> It does feel kind of awkward to me that _this_ is the patch that ends up > breaking the builds, versus something at the cmake level that says "you are > explicitly unsupported". If you're using our CMake toolchain file you're automatically migrated to LLD unless you pass `-DANDROID_LD=deprecated` starting with NDK r22. If you're not using our toolchain file there unfortunately was no way for us to have any kind of input to that process. r22 is fairly new, but this patch isn't expected to be in a stable NDK until several months from now. It takes us quite a while to move from a patch being submitted to clang to being shipped in a stable NDK, so that's why we're doing this now. We do try pretty hard to adhere to a deprecation window so people have time to adapt, but we're now working on Clang features that are beyond the end of the window (features we'd have preferred to land last summer, but didn't specifically to avoid breaking binutils compatibility). Clang is the //last// place that migration changes land, so using TOT clang but an older NDK means you started getting incompatible features before you got any of the warnings from the tools. > Also it's unfortunate that this landed just hours before 12.0.0 branched. Had > it landed slightly later, release users could have six months to plan for the > change. You say that the next NDK compiler is based on ToT, in that case > would it make sense to revert this on the 12.x branch, and add a warning to > the 12.0.0 release notes that lld will be assumed in 13? Would have waited if I'd known :( No objection to reverting in the 12.x release branch. We don't ship from the release branches anyway so reverting in 12.x keeps your next release the way you want it keeps ours the way we want it. Feel free to do that, or I can do it tomorrow. FWIW, we gave //much// more than six months notice that Android was dropping support for binutils: https://github.com/android/ndk/wiki/Changelog-r19-beta1. We did even communicate it specifically to Firefox, I believe: https://github.com/android/ndk/issues/1063. In D95166#2529432 <https://reviews.llvm.org/D95166#2529432>, @glandium wrote: > If clang _really_ wants to assume lld as the linker for android, then it > should make using -fuse-ld=somethingelse an error and invoke ld.lld rather > than ld, if it doesn't already do that. The other patch I linked <https://reviews.llvm.org/D76452> does the second part of that and would make it possible to continue working with gold/bfd (even if Android has no intention to support that workflow). I'll rebase that and restore the review to try again. I'd also much prefer to be able to do this in a way that doesn't so forcibly break compatibility but that wasn't an option without that patch. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D95166/new/ https://reviews.llvm.org/D95166 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
