On Thu, Feb 23, 2023 at 10:36 PM Rob Landley <rob@xxxxxxxxxxx> wrote: > > On 2/22/23 23:31, Masahiro Yamada wrote: > > On Wed, Feb 22, 2023 at 5:41 AM Rob Landley <rob@xxxxxxxxxxx> 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@xxxxxxxxxxx> > >> --- > >> 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. In the discussion in the past [1], we decided to go with LLVM=1 switch rather than 'cc'. We do not need both. [1]: https://lkml.org/lkml/2020/3/28/494 > > > 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? If you mean "without LLVM=1 or HOSTCC=clang specified", I think the answer is yes. > > >> 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. Unless LLVM=1 is specified, the toolchain defaults to GCC/binutils, there is no need for such additional complexity. > > > 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? gold is unsupported. See 75959d44f9dc8e44410667009724e4e238515502 Yes, to override only LD, LD=ld.lld should be given in the command line. > > Rob -- Best Regards Masahiro Yamada
