kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-08 18:57:22 +00:00
Code Issues Releases Packages Activity
linux/scripts/min-tool-version.sh

47 lines
641 B
Raw Normal View History

kbuild: collect minimum tool versions into scripts/min-tool-version.sh The kernel build uses various tools, many of which are provided by the same software suite, for example, LLVM and Binutils. When you raise the minimum version of Clang/LLVM, you need to update clang_min_version in scripts/cc-version.sh and also lld_min_version in scripts/ld-version.sh. Kbuild can handle CC=clang and LD=ld.lld independently, but it does not make much sense to maintain their versions separately. Let's create a central place of minimum tool versions so you do not need to touch multiple files. scripts/min-tool-version.sh prints the minimum version of the given tool. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
2021-03-16 01:12:55 +09:00
kbuild: require gcc-8 and binutils-2.30 Commit a3e8fe814ad1 ("x86/build: Raise the minimum GCC version to 8.1") raised the minimum compiler version as enforced by Kbuild to gcc-8.1 and clang-15 for x86. This is actually the same gcc version that has been discussed as the minimum for all architectures several times in the past, with little objection. A previous concern was the kernel for SLE15-SP7 needing to be built with gcc-7. As this ended up still using linux-6.4 and there is no plan for an SP8, this is no longer a problem. Change it for all architectures and adjust the documentation accordingly. A few version checks can be removed in the process. The binutils version 2.30 is the lowest version used in combination with gcc-8 on common distros, so use that as the corresponding minimum. Link: https://lore.kernel.org/lkml/20240925150059.3955569-32-ardb+git@google.com/ Link: https://lore.kernel.org/lkml/871q7yxrgv.wl-tiwai@suse.de/ Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-03-28 18:21:44 +01:00
kbuild: collect minimum tool versions into scripts/min-tool-version.sh The kernel build uses various tools, many of which are provided by the same software suite, for example, LLVM and Binutils. When you raise the minimum version of Clang/LLVM, you need to update clang_min_version in scripts/cc-version.sh and also lld_min_version in scripts/ld-version.sh. Kbuild can handle CC=clang and LD=ld.lld independently, but it does not make much sense to maintain their versions separately. Let's create a central place of minimum tool versions so you do not need to touch multiple files. scripts/min-tool-version.sh prints the minimum version of the given tool. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
2021-03-16 01:12:55 +09:00
parisc: Raise minimal GCC version to 12.0.0 Raise the minimum gcc version for parisc64 to 12.0.0 (for __int128 type) and keep 5.1.0 as minimum for 32-bit parisc target. Fixes: 8664645ade97 ("parisc: Raise minimal GCC version") Signed-off-by: Helge Deller <deller@gmx.de>
2023-07-03 16:02:04 +02:00
parisc: Raise minimal GCC version 64-bit targets need the __int128 type, which for pa-risc means raising the minimum gcc version to 11. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Helge Deller <deller@gmx.de> Tested-by: Mark Rutland <mark.rutland@arm.com> Link: https://lkml.kernel.org/r/20230602143912.GI620383%40hirez.programming.kicks-ass.net
2023-06-02 16:33:54 +02:00
kbuild: require gcc-8 and binutils-2.30 Commit a3e8fe814ad1 ("x86/build: Raise the minimum GCC version to 8.1") raised the minimum compiler version as enforced by Kbuild to gcc-8.1 and clang-15 for x86. This is actually the same gcc version that has been discussed as the minimum for all architectures several times in the past, with little objection. A previous concern was the kernel for SLE15-SP7 needing to be built with gcc-7. As this ended up still using linux-6.4 and there is no plan for an SP8, this is no longer a problem. Change it for all architectures and adjust the documentation accordingly. A few version checks can be removed in the process. The binutils version 2.30 is the lowest version used in combination with gcc-8 on common distros, so use that as the corresponding minimum. Link: https://lore.kernel.org/lkml/20240925150059.3955569-32-ardb+git@google.com/ Link: https://lore.kernel.org/lkml/871q7yxrgv.wl-tiwai@suse.de/ Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-03-28 18:21:44 +01:00
parisc: Raise minimal GCC version 64-bit targets need the __int128 type, which for pa-risc means raising the minimum gcc version to 11. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Helge Deller <deller@gmx.de> Tested-by: Mark Rutland <mark.rutland@arm.com> Link: https://lkml.kernel.org/r/20230602143912.GI620383%40hirez.programming.kicks-ass.net
2023-06-02 16:33:54 +02:00
kbuild: collect minimum tool versions into scripts/min-tool-version.sh The kernel build uses various tools, many of which are provided by the same software suite, for example, LLVM and Binutils. When you raise the minimum version of Clang/LLVM, you need to update clang_min_version in scripts/cc-version.sh and also lld_min_version in scripts/ld-version.sh. Kbuild can handle CC=clang and LD=ld.lld independently, but it does not make much sense to maintain their versions separately. Let's create a central place of minimum tool versions so you do not need to touch multiple files. scripts/min-tool-version.sh prints the minimum version of the given tool. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
2021-03-16 01:12:55 +09:00
kbuild: Bump minimum version of LLVM for building the kernel to 15.0.0 s390 and x86 have required LLVM 15 since 30d17fac6aae ("scripts/min-tool-version.sh: raise minimum clang version to 15.0.0 for s390") 7861640aac52 ("x86/build: Raise the minimum LLVM version to 15.0.0") respectively but most other architectures allow LLVM 13.0.1 or newer. In accordance with the recent minimum supported version of GCC bump that happened in 118c40b7b503 ("kbuild: require gcc-8 and binutils-2.30") do the same for LLVM to 15.0.0. Of the supported releases of Arch Linux, Debian, Fedora, and OpenSUSE surveyed in evaluating this bump, this only leaves behind Debian Bookworm (14.0.6) and Ubuntu Jammy (14.0.0). Debian Trixie has 19.1.7 and Ubuntu Noble has 18.1.3 (so there are viable upgrade paths) or users can use apt.llvm.org, which provides even newer packages for those distributions. Reviewed-by: Kees Cook <kees@kernel.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Nicolas Schier <nsc@kernel.org> Link: https://lore.kernel.org/r/20250821-bump-min-llvm-ver-15-v2-1-635f3294e5f0@kernel.org Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2025-08-21 14:15:38 -07:00
scripts/min-tool-version.sh: Raise minimum clang version to 18.0.0 for loongarch The existing mainline clang development version encounters difficulties compiling the LoongArch kernel module. It is anticipated that this issue will be resolved in the upcoming 18.0.0 release. To prevent user confusion arising from broken builds, it is advisable to raise the minimum required clang version for LoongArch to 18.0.0. Suggested-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Nick Desaulniers <ndesaulniers@google.com> Link: https://github.com/ClangBuiltLinux/linux/issues/1941 Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: WANG Rui <wangrui@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2024-01-17 12:43:00 +08:00
scripts/min-tool-version.sh: Raise minimum clang version to 13.0.0 for s390 clang versions prior to the current development version of 13.0.0 cannot compile s390 after commit 3abbdfde5a65 ("s390/bitops: use register pair instead of register asm") and the s390 maintainers do not intend to work around this in the kernel. Codify this in scripts/min-tool-version.sh similar to arm64 with GCC 5.1.0 so that there are no reports of broken builds. [hca@linux.ibm.com: breaking compatibility with older clang compilers is intended to finally make use of a feature which allows the compiler to allocate even/odd register pairs. This is possible since a very long time with gcc, but only since llvm-project commit d058262b1471 ("[SystemZ] Support i128 inline asm operands.") with clang. Using that feature allows to get rid of error prone register asm statements, of which the above named kernel commit is only the first of a larger not yet complete series.] Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Nick Desaulniers <ndesaulniers@google.com> Acked-by: Masahiro Yamada <masahiroy@kernel.org> Link: https://lore.kernel.org/r/20210617193139.856957-1-nathan@kernel.org Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-06-17 12:31:40 -07:00
kbuild: Bump minimum version of LLVM for building the kernel to 17.0.1 The current minimum version of LLVM for building the kernel is 15.0.0. However, there are two deficiencies compared to GCC that were fixed in LLVM 17 that are starting to become more noticeable. The first was a bug in LLVM's scope checker [1], where all labels in a function were validated as potential targets of an asm goto statement, even if they were not listed in the asm goto statement as targets. This becomes particularly problematic when the cleanup attribute is used, as asm goto(... : label_a); ... label_a: ... int var __free(foo); asm goto(... : label_b); ... label_b: ... will trigger an error since the scope checker will complain that the cleanup variable would be skipped when jumping from the first asm goto to label_b (which obviously cannot happen). This issue was the catalyst for commit e2ffa15b9baa ("kbuild: Disable CC_HAS_ASM_GOTO_OUTPUT on clang < 17"). Unfortunately, this issue is reproducible with regular asm goto in addition to asm goto with outputs, so that change was not entirely sufficient to avoid the issue altogether. As asm goto has effectively been required since commit a0a12c3ed057 ("asm goto: eradicate CC_HAS_ASM_GOTO") and the usage of the cleanup attribute continues to grow across the tree, raising the minimum to a version that avoids this issue altogether is a better long term solution than attempting to workaround it at every spot where it happens. The second issue is an incompatibility with GCC 8.1+ around variables marked with const being valid constant expressions for _Static_assert and other macros [2]. With GCC 8.1 being the minimum supported version since commit 118c40b7b503 ("kbuild: require gcc-8 and binutils-2.30"), this incompatibility becomes more of a maintenance burden since only clang-15 and clang-16 are affected by it. Looking at the clang version of various major distributions through Docker images, no one should be left behind as a result of this bump, as the old ones cannot clear the current minimum of 15.0.0. archlinux:latest clang version 22.1.3 debian:oldoldstable-slim Debian clang version 11.0.1-2 debian:oldstable-slim Debian clang version 14.0.6 debian:stable-slim Debian clang version 19.1.7 (3+b1) debian:testing-slim Debian clang version 21.1.8 (3+b1) debian:unstable-slim Debian clang version 21.1.8 (7+b1) fedora:42 clang version 20.1.8 (Fedora 20.1.8-4.fc42) fedora:latest clang version 21.1.8 (Fedora 21.1.8-4.fc43) fedora:44 clang version 22.1.1 (Fedora 22.1.1-2.fc44) fedora:rawhide clang version 22.1.3 (Fedora 22.1.3-1.fc45) opensuse/leap:latest clang version 17.0.6 opensuse/tumbleweed:latest clang version 21.1.8 ubuntu:jammy Ubuntu clang version 14.0.0-1ubuntu1.1 ubuntu:noble Ubuntu clang version 18.1.3 (1ubuntu1) ubuntu:questing Ubuntu clang version 20.1.8 (0ubuntu4) ubuntu:resolute Ubuntu clang version 21.1.8 (6ubuntu1) 17.0.1 is chosen as the minimum instead of 17.0.0 to ensure that the particular version of LLVM 17 has the two aforementioned bugs fixed, as the second was fixed during the 17.0.0 release candidate phase and it was not until LLVM 18 that LLVM adopted the scheme of x.0.0 being a prerelease version and x.1.0 is a release version [3] to help with scenarios such as this. Link: https://github.com/llvm/llvm-project/commit/f023f5cdb2e6c19026f04a15b5a935c041835d14 [1] Link: https://github.com/llvm/llvm-project/commit/0b2d5b967d98375793897295d651f58f6fbd3034 [2] Link: https://github.com/llvm/llvm-project/commit/4532617ae420056bf32f6403dde07fb99d276a49 [3] Acked-by: Nicolas Schier <nsc@kernel.org> Link: https://patch.msgid.link/20260517-bump-minimum-supported-llvm-version-to-17-v2-1-b3b8cda46bdd@kernel.org Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-05-17 13:05:04 -10:00
scripts/min-tool-version.sh: Raise minimum clang version to 13.0.0 for s390 clang versions prior to the current development version of 13.0.0 cannot compile s390 after commit 3abbdfde5a65 ("s390/bitops: use register pair instead of register asm") and the s390 maintainers do not intend to work around this in the kernel. Codify this in scripts/min-tool-version.sh similar to arm64 with GCC 5.1.0 so that there are no reports of broken builds. [hca@linux.ibm.com: breaking compatibility with older clang compilers is intended to finally make use of a feature which allows the compiler to allocate even/odd register pairs. This is possible since a very long time with gcc, but only since llvm-project commit d058262b1471 ("[SystemZ] Support i128 inline asm operands.") with clang. Using that feature allows to get rid of error prone register asm statements, of which the above named kernel commit is only the first of a larger not yet complete series.] Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Nick Desaulniers <ndesaulniers@google.com> Acked-by: Masahiro Yamada <masahiroy@kernel.org> Link: https://lore.kernel.org/r/20210617193139.856957-1-nathan@kernel.org Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-06-17 12:31:40 -07:00
kbuild: collect minimum tool versions into scripts/min-tool-version.sh The kernel build uses various tools, many of which are provided by the same software suite, for example, LLVM and Binutils. When you raise the minimum version of Clang/LLVM, you need to update clang_min_version in scripts/cc-version.sh and also lld_min_version in scripts/ld-version.sh. Kbuild can handle CC=clang and LD=ld.lld independently, but it does not make much sense to maintain their versions separately. Let's create a central place of minimum tool versions so you do not need to touch multiple files. scripts/min-tool-version.sh prints the minimum version of the given tool. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
2021-03-16 01:12:55 +09:00
scripts: add `rust_is_available.sh` This script tests whether the Rust toolchain requirements are in place to enable Rust support. It uses `min-tool-version.sh` to fetch the version numbers. The build system will call it to set `CONFIG_RUST_IS_AVAILABLE` in a later patch. It also has an option (`-v`) to explain what is missing, which is useful to set up the development environment. This is used via the `make rustavailable` target added in a later patch. Reviewed-by: Kees Cook <keescook@chromium.org> Co-developed-by: Alex Gaynor <alex.gaynor@gmail.com> Signed-off-by: Alex Gaynor <alex.gaynor@gmail.com> Co-developed-by: Wedson Almeida Filho <wedsonaf@google.com> Signed-off-by: Wedson Almeida Filho <wedsonaf@google.com> Co-developed-by: Finn Behrens <me@kloenk.de> Signed-off-by: Finn Behrens <me@kloenk.de> Co-developed-by: Miguel Cano <macanroj@gmail.com> Signed-off-by: Miguel Cano <macanroj@gmail.com> Co-developed-by: Tiago Lam <tiagolam@gmail.com> Signed-off-by: Tiago Lam <tiagolam@gmail.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-08-04 12:25:53 +02:00
s390: Enable Rust support Enable building Rust code on s390 by wiring the architecture into the kernel Rust infrastructure. Add s390 to the Rust arch support documentation, provide the s390 Rust target and required compiler flags, and set the bindgen target for arch/s390. Adjust the Rust target generation and minimum rustc version gating so the s390 setup is handled explicitly. The Rust toolchain uses the "s390x" triple naming for the 64 bit target. Rust support is currently incompatible with CONFIG_EXPOLINE, which relies on compiler support for the -mindirect-branch= and -mfunction_return= options. Therefore, select HAVE_RUST only when EXPOLINE is disabled. Acked-by: Miguel Ojeda <ojeda@kernel.org> Acked-by: Gary Guo <gary@garyguo.net> Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Jan Polensky <japo@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-06-01 19:46:25 +02:00
scripts: add `rust_is_available.sh` This script tests whether the Rust toolchain requirements are in place to enable Rust support. It uses `min-tool-version.sh` to fetch the version numbers. The build system will call it to set `CONFIG_RUST_IS_AVAILABLE` in a later patch. It also has an option (`-v`) to explain what is missing, which is useful to set up the development environment. This is used via the `make rustavailable` target added in a later patch. Reviewed-by: Kees Cook <keescook@chromium.org> Co-developed-by: Alex Gaynor <alex.gaynor@gmail.com> Signed-off-by: Alex Gaynor <alex.gaynor@gmail.com> Co-developed-by: Wedson Almeida Filho <wedsonaf@google.com> Signed-off-by: Wedson Almeida Filho <wedsonaf@google.com> Co-developed-by: Finn Behrens <me@kloenk.de> Signed-off-by: Finn Behrens <me@kloenk.de> Co-developed-by: Miguel Cano <macanroj@gmail.com> Signed-off-by: Miguel Cano <macanroj@gmail.com> Co-developed-by: Tiago Lam <tiagolam@gmail.com> Signed-off-by: Tiago Lam <tiagolam@gmail.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-08-04 12:25:53 +02:00
rust: bump `bindgen` minimum supported version to 0.71.1 (Debian Trixie) As proposed in the past in e.g. LPC 2025 and the Maintainers Summit [1], we are going to follow Debian Stable's `bindgen` versions as our minimum supported version. Debian Trixie was released with `bindgen` 0.71.1, which it still uses to this day [2]. Debian Trixie's release happened on 2025-08-09 [3], which means that a fair amount of time has passed since its release for kernel developers to upgrade. Thus bump the minimum to the new version. Then, in later commits, clean up most of the workarounds and other bits that this upgrade of the minimum allows us. Ubuntu 25.10 also has a recent enough `bindgen` [4] (even the already unsupported Ubuntu 25.04 had it), and they also provide versioned packages with `bindgen` 0.71.1 back to Ubuntu 24.04 LTS [5]. Link: https://lwn.net/Articles/1050174/ [1] Link: https://packages.debian.org/trixie/bindgen [2] Link: https://www.debian.org/releases/trixie/ [3] Link: https://packages.ubuntu.com/search?suite=all&searchon=names&keywords=bindgen [4] Link: https://launchpad.net/ubuntu/+source/rust-bindgen-0.71 [5] Acked-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-18-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-06 01:52:53 +02:00
scripts: add `rust_is_available.sh` This script tests whether the Rust toolchain requirements are in place to enable Rust support. It uses `min-tool-version.sh` to fetch the version numbers. The build system will call it to set `CONFIG_RUST_IS_AVAILABLE` in a later patch. It also has an option (`-v`) to explain what is missing, which is useful to set up the development environment. This is used via the `make rustavailable` target added in a later patch. Reviewed-by: Kees Cook <keescook@chromium.org> Co-developed-by: Alex Gaynor <alex.gaynor@gmail.com> Signed-off-by: Alex Gaynor <alex.gaynor@gmail.com> Co-developed-by: Wedson Almeida Filho <wedsonaf@google.com> Signed-off-by: Wedson Almeida Filho <wedsonaf@google.com> Co-developed-by: Finn Behrens <me@kloenk.de> Signed-off-by: Finn Behrens <me@kloenk.de> Co-developed-by: Miguel Cano <macanroj@gmail.com> Signed-off-by: Miguel Cano <macanroj@gmail.com> Co-developed-by: Tiago Lam <tiagolam@gmail.com> Signed-off-by: Tiago Lam <tiagolam@gmail.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-08-04 12:25:53 +02:00
kbuild: collect minimum tool versions into scripts/min-tool-version.sh The kernel build uses various tools, many of which are provided by the same software suite, for example, LLVM and Binutils. When you raise the minimum version of Clang/LLVM, you need to update clang_min_version in scripts/cc-version.sh and also lld_min_version in scripts/ld-version.sh. Kbuild can handle CC=clang and LD=ld.lld independently, but it does not make much sense to maintain their versions separately. Let's create a central place of minimum tool versions so you do not need to touch multiple files. scripts/min-tool-version.sh prints the minimum version of the given tool. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
2021-03-16 01:12:55 +09:00