On Mon, Apr 07, 2025 at 11:41:12AM +0200, Arnd Bergmann wrote: > From: Arnd Bergmann <arnd@xxxxxxxx> > > x86 already requires gcc-8.1 since linux-6.15-rc1, which led me to > actually go through all version checks and make this is the minimum > for all architectures. > > Most of the actual resulting changes are actually for raising the > binutils version, which eliminates version checks on x86 and arm64. > > Arnd Bergmann (4): > kbuild: require gcc-8 and binutils-2.30 > raid6: skip avx512 checks > x86: remove checks for binutils-2.30 and earlier > arm64: drop binutils version checks This is intended to supersede the patches from Uros that removed checks for binutils < 2.25, right? See: * https://lore.kernel.org/linux-crypto/20250404074135.520812-1-ubizjak@xxxxxxxxx/ * https://lore.kernel.org/linux-crypto/20250404074135.520812-2-ubizjak@xxxxxxxxx * https://lore.kernel.org/linux-crypto/20250404074135.520812-3-ubizjak@xxxxxxxxx/ If we can indeed bump up the requirement to 2.30, that would be great. Just a note though: I recently added VAES and VPCLMULQDQ instructions to BoringSSL, which increased the binutils requirement of building BoringSSL to 2.30, and this caused issues in a downstream project; e.g. see https://github.com/briansmith/ring/issues/2463. Specifically people complained about being unable to build on Amazon Linux 2 and CentOS/RHEL/Oracle Linux 7. So I just thought I'd mention that, based on past experience with this sort of thing, those are the specific cases where it seems people are most likely to be trying to use binutils < 2.30. But if those distros are not going to be supported any longer (without installing newer tools on them), or even are already unsupported due to the gcc requirement, bumping up the binutils requirement to 2.30 sounds good to me. - Eric
