[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <380c88ef-eb19-e73e-0ec9-805b8b90e957@landley.net>
Date: Thu, 23 Feb 2023 07:50:14 -0600
From: Rob Landley <rob@...dley.net>
To: Masahiro Yamada <masahiroy@...nel.org>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Nathan Chancellor <nathan@...nel.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Nicolas Schier <nicolas@...sle.eu>, Tom Rix <trix@...hat.com>,
linux-kbuild@...r.kernel.org, llvm@...ts.linux.dev
Subject: Re: [PATCH 1/5] try generic compiler name "cc" before falling back to
"gcc".
On 2/22/23 23:31, Masahiro Yamada wrote:
> On Wed, Feb 22, 2023 at 5:41 AM Rob Landley <rob@...dley.net> wrote:
>>
>> Distros like debian install the generic "cc" name for both gcc and clang,
>> and the plumbing already does CC_VERSION_TEXT to include Makefile.clang.
>>
>> Previously: https://lkml.iu.edu/hypermail/linux/kernel/2202.0/01505.html
>> Signed-off-by: Rob Landley <rob@...dley.net>
>> ---
>> Makefile | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/Makefile b/Makefile
>> index 3f6628780eb2..0ac57ae3b45f 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -456,7 +456,7 @@ endif
>> HOSTCC = $(LLVM_PREFIX)clang$(LLVM_SUFFIX)
>> HOSTCXX = $(LLVM_PREFIX)clang++$(LLVM_SUFFIX)
>> else
>> -HOSTCC = gcc
>> +HOSTCC := $(shell cc --version >/dev/null 2>&1 && echo cc || echo gcc)
>
> 'cc' only makes sense for the host compiler,
It was the generic posix name for "C compiler" until posix decided to put an
expiration date in the command name, which seems as widely honored as the
tar->pax switch or the removal of cpio.
The name "gcc" was like "gmake" and "gawk". (On macos homebrew there's "gsed".)
> which is configured by 'update-alternative'.
Hexagon only has llvm support, not gcc, so I had to add an llvm cross compiler
to my cross compiler set, prefixed hexagon-unknown-linux-musl-*, but the linux
kernel wants to call it as hexagon-unknown-linux-musl-gcc.
The kernel builds find with a "gcc" symlink to clang, but there _is_ a generic
name, which is widely installed.
> I tried it before, but LLVM folks preferred
> using $(LLVM) to choose clang/gcc.
So if we want generic behavior without having to specify, we should create a
"gcc" symlink to clang?
>> HOSTCXX = g++
>> endif
>> HOSTRUSTC = rustc
>> @@ -503,7 +503,8 @@ OBJDUMP = $(LLVM_PREFIX)llvm-objdump$(LLVM_SUFFIX)
>> READELF = $(LLVM_PREFIX)llvm-readelf$(LLVM_SUFFIX)
>> STRIP = $(LLVM_PREFIX)llvm-strip$(LLVM_SUFFIX)
>> else
>> -CC = $(CROSS_COMPILE)gcc
>> +CC := $(CROSS_COMPILE)$(shell $(CROSS_COMPILE)cc --version \
>> + >/dev/null 2>&1 && echo cc || echo gcc)
>
> This hunk sets up GCC/binutils.
This is the codepath that's taken when you don't explicitly specify "LLVM=1".
The test there is falling back to (appropriately prefixed) gcc when it can't
find a working (appropriately prefixed) cc.
> So, cc does not make sense. NACK.
Do you explicitly specify the "gold" linker vs the previous gnu one vs
lld.llvm.org on the kernel build command line?
Rob
Powered by blists - more mailing lists