Re: [PATCH 1/5] try generic compiler name "cc" before falling back to "gcc".

[Masahiro Yamada]

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