Gentoo Archives: gentoo-dev

From: Adrian Ratiu <adrian.ratiu@×××××××××.com>
To: James Beddek <telans@××××××.de>, gentoo-dev@l.g.o
Cc: Manoj Gupta <manojgupta@××××××××.org>
Subject: Re: [gentoo-dev] [PATCH v2] kernel-2.eclass: Respect portage CC & AR variables
Date: Thu, 16 Dec 2021 19:25:36
Message-Id: 87pmpw1hf7.fsf@iwork.i-did-not-set--mail-host-address--so-tickle-me
In Reply to: Re: [gentoo-dev] [PATCH v2] kernel-2.eclass: Respect portage CC & AR variables by James Beddek
1 Hi James, thank you very much for your feedback!
2
3 On Wed, 15 Dec 2021, James Beddek <telans@××××××.de> wrote:
4 > On Thursday, 16 December 2021 3:58:26 AM NZDT Adrian Ratiu
5 > wrote:
6 >> Starting with kernel>=v5.7 the build system can override the
7 >> tools vars by setting LLVM=1 [1], but older kernels still use
8 >> the default GNU tools, so to be able to use a full LLVM/Clang
9 >> build, CC should be set together with AR to the portage set
10 >> values. Doing this avoids situations like building the kernel
11 >> with clang (using the set HOSTCC) but using gcc/gnu-ar for
12 >> headers. [1] a0d1c951ef08 kbuild: support LLVM=1 to switch
13 >> the default tools to Clang/LLVM Co-authored-by: Manoj Gupta
14 >> <manojgupta@××××××××.org> Signed-off-by: Adrian Ratiu
15 >> <adrian.ratiu@×××××××××.com> ---
16 >> eclass/kernel-2.eclass | 2 +- 1 file changed, 1 insertion(+),
17 >> 1 deletion(-)
18 >> diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
19 >> index adc1425bc2e..caeec86ff59 100644 ---
20 >> a/eclass/kernel-2.eclass +++ b/eclass/kernel-2.eclass @@ -692,7
21 >> +692,7 @@ env_setup_xmakeopts() {
22 >> elif type -p ${CHOST}-ar >/dev/null; then
23 >> xmakeopts="${xmakeopts} CROSS_COMPILE=${CHOST}-" fi
24 >> - xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC)" +
25 >> xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC) CC=$(tc-getCC)
26 >> AR=$(tc-getAR)" export xmakeopts
27 >> }
28 >
29 > What's the reason for not using $LLVM here? To preserve building
30 > with clang for kernels < 5.7 ?
31
32 That is correct - if Gentoo were to support only kernels >= 5.7
33 then we could try to use $LLVM directly, but older long-term
34 releases are still supported, the upstream kernel will backport
35 patches to v4.14 until Jan 2024 and we would really like to build
36 these with Clang too.
37
38 >
39 > I might be missing the point, but wouldn't something along the
40 > lines of "LLVM=$(! [[ $(tc-getCC) =~ clang ]]; echo $?)" work to
41 > preserve the correct compiler tools?
42
43 In theory Manoj's argument is correct: this is about respecting CC
44 and the tools configuration in general so we should try to avoid
45 hardcoding for clang if possible, but...
46
47 In practice I'm not aware of people building the kernel with
48 something other than GNU or LLVM variants. At least these are the
49 only two which receive "first class" support by the upstream
50 kernel community.
51
52 In addition, hardcoding $LLVM does not fix the problem of older
53 kernels.
54
55 I thought about backporting $LLVM support to long-term releases
56 but I don't think it would be acceptable for inclusion in older
57 kernels which should receive only bug fixes.
58
59 This is why I think the best solution is to just set the variables
60 in this eclass to the values set by portage.
61
62 Thanks,
63 Adrian
64
65 >
66 > Cheers