Hi James, thank you very much for your feedback!
On Wed, 15 Dec 2021, James Beddek <tel...@posteo.de> wrote:
On Thursday, 16 December 2021 3:58:26 AM NZDT Adrian Ratiu
wrote:
Starting with kernel>=v5.7 the build system can override the
tools vars by setting LLVM=1 [1], but older kernels still use
the default GNU tools, so to be able to use a full LLVM/Clang
build, CC should be set together with AR to the portage set
values. Doing this avoids situations like building the kernel
with clang (using the set HOSTCC) but using gcc/gnu-ar for
headers. [1] a0d1c951ef08 kbuild: support LLVM=1 to switch
the default tools to Clang/LLVM Co-authored-by: Manoj Gupta
<manojgu...@chromium.org> Signed-off-by: Adrian Ratiu
<adrian.ra...@collabora.com> ---
eclass/kernel-2.eclass | 2 +- 1 file changed, 1 insertion(+),
1 deletion(-)
diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index adc1425bc2e..caeec86ff59 100644 ---
a/eclass/kernel-2.eclass +++ b/eclass/kernel-2.eclass @@ -692,7
+692,7 @@ env_setup_xmakeopts() {
elif type -p ${CHOST}-ar >/dev/null; then
xmakeopts="${xmakeopts} CROSS_COMPILE=${CHOST}-" fi
- xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC)" +
xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC) CC=$(tc-getCC)
AR=$(tc-getAR)" export xmakeopts
}
What's the reason for not using $LLVM here? To preserve building
with clang for kernels < 5.7 ?
That is correct - if Gentoo were to support only kernels >= 5.7
then we could try to use $LLVM directly, but older long-term
releases are still supported, the upstream kernel will backport
patches to v4.14 until Jan 2024 and we would really like to build
these with Clang too.
I might be missing the point, but wouldn't something along the
lines of "LLVM=$(! [[ $(tc-getCC) =~ clang ]]; echo $?)" work to
preserve the correct compiler tools?
In theory Manoj's argument is correct: this is about respecting CC
and the tools configuration in general so we should try to avoid
hardcoding for clang if possible, but...
In practice I'm not aware of people building the kernel with
something other than GNU or LLVM variants. At least these are the
only two which receive "first class" support by the upstream
kernel community.
In addition, hardcoding $LLVM does not fix the problem of older
kernels.
I thought about backporting $LLVM support to long-term releases
but I don't think it would be acceptable for inclusion in older
kernels which should receive only bug fixes.
This is why I think the best solution is to just set the variables
in this eclass to the values set by portage.
Thanks,
Adrian
Cheers
