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

43 lines
582 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 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 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.78.0 This is the next upgrade to the Rust toolchain, from 1.77.1 to 1.78.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"). It is much smaller than previous upgrades, since the `alloc` fork was dropped in commit 9d0441bab775 ("rust: alloc: remove our fork of the `alloc` crate") [3]. # Unstable features There have been no changes to the set of unstable features used in our own code. Therefore, the only unstable features allowed to be used outside the `kernel` crate is still `new_uninit`. However, since we finally dropped our `alloc` fork [3], all the unstable features used by `alloc` (~30 language ones, ~60 library ones) are not a concern anymore. This reduces the maintenance burden, increases the chances of new compiler versions working without changes and gets us closer to the goal of supporting several compiler versions. It also means that, ignoring non-language/library features, we are currently left with just the few language features needed to implement the kernel `Arc`, the `new_uninit` library feature, the `compiler_builtins` marker and the few `no_*` `cfg`s we pass when compiling `core`/`alloc`. Please see [4] for details. # Required changes ## LLVM's data layout Rust 1.77.0 (i.e. the previous upgrade) introduced a check for matching LLVM data layouts [5]. Then, Rust 1.78.0 upgraded LLVM's bundled major version from 17 to 18 [6], which changed the data layout in x86 [7]. Thus update the data layout in our custom target specification for x86 so that the compiler does not complain about the mismatch: error: data-layout for target `target-5559158138856098584`, `e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128`, differs from LLVM target's `x86_64-linux-gnu` default layout, `e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128` In the future, the goal is to drop the custom target specifications. Meanwhile, if we want to support other LLVM versions used in `rustc` (e.g. for LTO), we will need to add some extra logic (e.g. conditional on LLVM's version, or extracting the data layout from an existing built-in target specification). ## `unused_imports` Rust's `unused_imports` lint covers both unused and redundant imports. Now, in 1.78.0, the lint detects more cases of redundant imports [8]. Thus one of the previous patches cleaned them up. ## Clippy's `new_without_default` Clippy now suggests to implement `Default` even when `new()` is `const`, since `Default::default()` may call `const` functions even if it is not `const` itself [9]. Thus one of the previous patches implemented it. # Other changes in Rust Rust 1.78.0 introduced `feature(asm_goto)` [10] [11]. This feature was discussed in the past [12]. Rust 1.78.0 introduced `feature(const_refs_to_static)` [13] to allow referencing statics in constants and extended `feature(const_mut_refs)` to allow raw mutable pointers in constants. Together, this should cover the kernel's `VTABLE` use case. In fact, the implementation [14] in upstream Rust added a test case for it [15]. Rust 1.78.0 with debug assertions enabled (i.e. `-Cdebug-assertions=y`, kernel's `CONFIG_RUST_DEBUG_ASSERTIONS=y`) now always checks all unsafe preconditions, though without a way to opt-out for particular cases [16]. It would be ideal to have a way to selectively disable certain checks per-call site for this one (i.e. not just per check but for particular instances of a check), even if the vast majority of the checks remain in place [17]. Rust 1.78.0 also improved a couple issues we reported when giving feedback for the new `--check-cfg` feature [18] [19]. # `alloc` upgrade and reviewing As mentioned above, compiler upgrades will not update `alloc` anymore, since we dropped our `alloc` fork [3]. Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1780-2024-05-02 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: https://lore.kernel.org/rust-for-linux/20240328013603.206764-1-wedsonaf@gmail.com/ [3] Link: https://github.com/Rust-for-Linux/linux/issues/2 [4] Link: https://github.com/rust-lang/rust/pull/120062 [5] Link: https://github.com/rust-lang/rust/pull/120055 [6] Link: https://reviews.llvm.org/D86310 [7] Link: https://github.com/rust-lang/rust/pull/117772 [8] Link: https://github.com/rust-lang/rust-clippy/pull/10903 [9] Link: https://github.com/rust-lang/rust/pull/119365 [10] Link: https://github.com/rust-lang/rust/issues/119364 [11] Link: https://lore.kernel.org/rust-for-linux/ZWipTZysC2YL7qsq@Boquns-Mac-mini.home/ [12] Link: https://github.com/rust-lang/rust/issues/119618 [13] Link: https://github.com/rust-lang/rust/pull/120932 [14] Link: https://github.com/rust-lang/rust/pull/120932/files#diff-e6fc1622c46054cd46b1d225c5386c5554564b3b0fa8a03c2dc2d8627a1079d9 [15] Link: https://github.com/rust-lang/rust/issues/120969 [16] Link: https://github.com/Rust-for-Linux/linux/issues/354 [17] Link: https://github.com/rust-lang/rust/pull/121202 [18] Link: https://github.com/rust-lang/rust/pull/121237 [19] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20240401212303.537355-4-ojeda@kernel.org [ Added a few more details and links I mentioned in the list. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-04-01 23:23:03 +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