kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-10-26 19:14:18 +00:00
Code Issues Releases Packages Activity
linux/scripts/min-tool-version.sh

43 lines
577 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
Documentation: raise minimum supported version of binutils to 2.25 Binutils 2.23 was released in 2012. Almost 10 years old. We already require GCC 5.1, released in 2015. Bump the binutils version to 2.25, which was released some months before GCC 5.1. With this applied, some subsystems can start to clean up code. Examples: arch/arm/Kconfig.assembler arch/mips/vdso/Kconfig arch/powerpc/Makefile arch/x86/Kconfig.assembler Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2022-10-13 03:18:41 +09: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: 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/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
scripts/min-tool-version.sh: raise minimum clang version to 15.0.0 for s390 Before version 15.0.0 llvm's integrated assembler may silently generate corrupted code on s390. See e.g. commit e9953b729b78 ("s390/boot: workaround llvm IAS bug") for further details. While there have been workarounds applied for all known existing locations, there is nothing that prevents that new code with problematic patterns will be added. Therefore raise the minimum clang version to 15.0.0. Note that llvm commit e547b04d5b2c ("[SystemZ] Bugfix for symbolic displacements."), which is included in 15.0.0, fixes the broken code generation. Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Acked-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20221031123456.3872220-1-hca@linux.ibm.com Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2022-10-31 13:34:56 +01: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
Documentation: Raise the minimum supported version of LLVM to 11.0.0 LLVM versions prior to 11.0.0 have a harder time with dead code elimination, which can cause issues with commonly used expressions such as BUILD_BUG_ON and the bitmask functions/macros in bitfield.h (see the first two issues links below). Whenever there is an issue within LLVM that has been resolved in a later release, the only course of action is to gate the problematic configuration or source code on the toolchain verson or raise the minimum supported version of LLVM for building the kernel, as LLVM has a limited support lifetime compared to GCC. GCC major releases will typically see a few point releases across a two year period on average whereas LLVM major releases are only supported until the next major release and will only see one or two point releases within that timeframe. For example, GCC 8.1 was released in May 2018 and GCC 8.5 was released in May 2021, whereas LLVM 12.0.0 was released in April 2021 and its only point release, 12.0.1, was released in July 2021, giving a minimal window for fixes to be backported. To resolve these build errors around improper dead code elimination, raise the minimum supported version of LLVM for building the kernel to 11.0.0. Doing so is a more proper solution than mucking around with core kernel macros that have always worked with GCC or disabling drivers for using these macros in a proper manner. This type of issue may continue to crop up and require patching, which creates more debt for bumping the minimum supported version in the future. This should have a minimal impact to distributions. Using a script to pull several different Docker images and check the output of 'clang --version': archlinux:latest: clang version 13.0.0 debian:oldoldstable-slim: clang version 3.8.1-24 (tags/RELEASE_381/final) debian:oldstable-slim: clang version 7.0.1-8+deb10u2 (tags/RELEASE_701/final) debian:stable-slim: Debian clang version 11.0.1-2 debian:testing-slim: Debian clang version 11.1.0-4 debian:unstable-slim: Debian clang version 11.1.0-4 fedora:34: clang version 12.0.1 (Fedora 12.0.1-1.fc34) fedora:latest: clang version 13.0.0 (Fedora 13.0.0-3.fc35) fedora:rawhide: clang version 13.0.0 (Fedora 13.0.0-5.fc36) opensuse/leap:15.2: clang version 9.0.1 opensuse/leap:latest: clang version 11.0.1 opensuse/tumbleweed:latest: clang version 13.0.0 ubuntu:bionic: clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final) ubuntu:latest: clang version 10.0.0-4ubuntu1 ubuntu:hirsute: Ubuntu clang version 12.0.0-3ubuntu1~21.04.2 ubuntu:rolling: Ubuntu clang version 13.0.0-2 ubuntu:devel: Ubuntu clang version 13.0.0-9 In every case, the distribution's version of clang is either older than the current minimum supported version of LLVM 10.0.1 or equal to or greater than the proposed 11.0.0 so nothing should change. Another benefit of this change is LLVM=1 works better with arm64 and x86_64 since commit f12b034afeb3 ("scripts/Makefile.clang: default to LLVM_IAS=1") enabled the integrated assembler by default, which only works well with clang 11+ (clang-10 required it to be disabled to successfully build a kernel). Link: https://github.com/ClangBuiltLinux/linux/issues/1293 Link: https://github.com/ClangBuiltLinux/linux/issues/1506 Link: https://github.com/ClangBuiltLinux/linux/issues/1511 Link: https://github.com/llvm/llvm-project/commit/fa496ce3c6774097080c8a9cb808da56f383b938 Link: https://groups.google.com/g/clang-built-linux/c/mPQb9_ZWW0s/m/W7o6S-QTBAAJ Link: https://github.com/ClangBuiltLinux/misc-scripts Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Miguel Ojeda <ojeda@kernel.org> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-11-29 09:57:58 -07: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
rust: upgrade to Rust 1.73.0 commit e08ff622c91af997cb89bc47e90a1a383e938bd0 upstream. This is the next upgrade to the Rust toolchain, from 1.72.1 to 1.73.0 (i.e. the latest) [1]. See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4da06e ("rust: upgrade to Rust 1.68.2"). # Unstable features No unstable features (that we use) were stabilized. Therefore, the only unstable feature allowed to be used outside the `kernel` crate is still `new_uninit`, though other code to be upstreamed may increase the list. Please see [3] for details. # Required changes For the upgrade, the following changes are required: - Allow `internal_features` for `feature(compiler_builtins)` since now Rust warns about using internal compiler and standard library features (similar to how it also warns about incomplete ones) [4]. - A cleanup for a documentation link thanks to a new `rustdoc` lint. See previous commits for details. - A need to make an intra-doc link to a macro explicit, due to a change in behavior in `rustdoc`. See previous commits for details. # `alloc` upgrade and reviewing The vast majority of changes are due to our `alloc` fork being upgraded at once. There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream. Instead of taking a look at the diff of this patch, an alternative approach is reviewing a diff of the changes between upstream `alloc` and the kernel's. This allows to easily inspect the kernel additions only, especially to check if the fallible methods we already have still match the infallible ones in the new version coming from upstream. Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions. To apply these approaches, one may follow steps similar to the following to generate a pair of patches that show the differences between upstream Rust and the kernel (for the subset of `alloc` we use) before and after applying this patch: # Get the difference with respect to the old version. git -C rust checkout $(linux/scripts/min-tool-version.sh rustc) git -C linux ls-tree -r --name-only HEAD -- rust/alloc | cut -d/ -f3- | grep -Fv README.md | xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH git -C linux diff --patch-with-stat --summary -R > old.patch git -C linux restore rust/alloc # Apply this patch. git -C linux am rust-upgrade.patch # Get the difference with respect to the new version. git -C rust checkout $(linux/scripts/min-tool-version.sh rustc) git -C linux ls-tree -r --name-only HEAD -- rust/alloc | cut -d/ -f3- | grep -Fv README.md | xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH git -C linux diff --patch-with-stat --summary -R > new.patch git -C linux restore rust/alloc Now one may check the `new.patch` to take a look at the additions (first approach) or at the difference between those two patches (second approach). For the latter, a side-by-side tool is recommended. Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1730-2023-10-05 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: https://github.com/Rust-for-Linux/linux/issues/2 [3] Link: https://github.com/rust-lang/compiler-team/issues/596 [4] Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20231005210556.466856-4-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-05 23:05:55 +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: bindgen: upgrade to 0.65.1 In LLVM 16, anonymous items may return names like `(unnamed union at ..)` rather than empty names [1], which breaks Rust-enabled builds because bindgen assumed an empty name instead of detecting them via `clang_Cursor_isAnonymous` [2]: $ make rustdoc LLVM=1 CLIPPY=1 -j$(nproc) RUSTC L rust/core.o BINDGEN rust/bindings/bindings_generated.rs BINDGEN rust/bindings/bindings_helpers_generated.rs BINDGEN rust/uapi/uapi_generated.rs thread 'main' panicked at '"ftrace_branch_data_union_(anonymous_at__/_/include/linux/compiler_types_h_146_2)" is not a valid Ident', .../proc-macro2-1.0.24/src/fallback.rs:693:9 ... thread 'main' panicked at '"ftrace_branch_data_union_(anonymous_at__/_/include/linux/compiler_types_h_146_2)" is not a valid Ident', .../proc-macro2-1.0.24/src/fallback.rs:693:9 ... This was fixed in bindgen 0.62.0. Therefore, upgrade bindgen to a more recent version, 0.65.1, to support LLVM 16. Since bindgen 0.58.0 changed the `--{white,black}list-*` flags to `--{allow,block}list-*` [3], update them on our side too. In addition, bindgen 0.61.0 moved its CLI utility into a binary crate called `bindgen-cli` [4]. Thus update the installation command in the Quick Start guide. Moreover, bindgen 0.61.0 changed the default functionality to bind `size_t` to `usize` [5] and added the `--no-size_t-is-usize` flag to not bind `size_t` as `usize`. Then bindgen 0.65.0 removed the `--size_t-is-usize` flag [6]. Thus stop passing the flag to bindgen. Finally, bindgen 0.61.0 added support for the `noreturn` attribute (in its different forms) [7]. Thus remove the infinite loop in our Rust panic handler after calling `BUG()`, since bindgen now correctly generates a `BUG()` binding that returns `!` instead of `()`. Link: https://github.com/llvm/llvm-project/commit/19e984ef8f49bc3ccced15621989fa9703b2cd5b [1] Link: https://github.com/rust-lang/rust-bindgen/pull/2319 [2] Link: https://github.com/rust-lang/rust-bindgen/pull/1990 [3] Link: https://github.com/rust-lang/rust-bindgen/pull/2284 [4] Link: https://github.com/rust-lang/rust-bindgen/commit/cc78b6fdb6e829e5fb8fa1639f2182cb49333569 [5] Link: https://github.com/rust-lang/rust-bindgen/pull/2408 [6] Link: https://github.com/rust-lang/rust-bindgen/issues/2094 [7] Signed-off-by: Aakash Sen Sharma <aakashsensharma@gmail.com> Closes: https://github.com/Rust-for-Linux/linux/issues/1013 Tested-by: Ariel Miculas <amiculas@cisco.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20230612194311.24826-1-aakashsensharma@gmail.com [ Reworded commit message. Mentioned the `bindgen-cli` binary crate change, linked to it and updated the Quick Start guide. Re-added a deleted "as" word in a code comment and reflowed comment to respect the maximum length. ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2023-06-13 01:13:11 +05:30
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