Message-ID: <CAKwvOdkaifETNvtTA3O9EToVHAK0N50wkT-bHOpQ2RmFg7qk0A@mail.gmail.com>
Date:   Thu, 8 Jul 2021 11:04:18 -0700
From:   Nick Desaulniers <ndesaulniers@...gle.com>
To:     Arnd Bergmann <arnd@...nel.org>,
        Christoph Hellwig <hch@...radead.org>
Cc:     Masahiro Yamada <masahiroy@...nel.org>,
        Miguel Ojeda <ojeda@...nel.org>,
        Fangrui Song <maskray@...gle.com>,
        Michal Marek <michal.lkml@...kovi.net>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        clang-built-linux <clang-built-linux@...glegroups.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 0/2] infer CROSS_COMPILE from ARCH for LLVM=1 LLVM_IAS=1

On Thu, Jul 8, 2021 at 12:27 AM Arnd Bergmann <arnd@...nel.org> wrote:
>
> On Thu, Jul 8, 2021 at 7:49 AM Christoph Hellwig <hch@...radead.org> wrote:
> >
> > On Wed, Jul 07, 2021 at 03:43:08PM -0700, Nick Desaulniers wrote:
> > > We get constant feedback that the command line invocation of make is too
> > > long. CROSS_COMPILE is helpful when a toolchain has a prefix of the
> > > target triple, or is an absolute path outside of $PATH, but it's mostly
> > > redundant for a given ARCH.
> > >
> > > Instead, let's infer it from ARCH, and move some flag handling into a
> > > new file included from the top level Makefile.
> >
> > Why only for LLVM?  I really hate the mess we currently have with
> > ARCH and CROSS_COMPILE.

I agree.

> > Being able to set both in .config (and maybe
> > even inferring CROSS_COMPILE where possible) would make my life so
> > much easier.
>
> I agree this would be best, but solving the problem for llvm is
> trivial with a 1:1
> mapping between ARCH= and --target= strings. Doing the same for gcc
> requires enumerating all possible target triples, and possibly deciding between
> different versions, e.g. when your path contains

Yes. There is a seldom used Kbuild macro for this: cc-cross-prefix.
It's hard coded to check for prefixed versions of gcc, but it will
handle the enumeration. Perhaps it could be used more widely, once we
know whether we're building with gcc or clang.  But as you note,
enumeration is kind of a waste of time for clang as these target
triples are known ahead of time.  I guess we could check that your
build of clang was configured with support for that target ARCH (since
you can disable backends when building clang), but I consider
disabling backends an antipattern, and I think the user will figure
out pretty quickly when they're trying to build a target that LLVM
doesn't support (whether due to configured-off or unimplemented
target).

> /usr/bin/powerpc64-linux-gnu-gcc-5.2.0
> /usr/bin/powerpc64-linux-gnu-gcc -> powerpc64-linux-gnu-gcc-5.2.0
> /usr/local/bin/ppc64le-linux-gcc-9
> ~/bin/powerpc/powerpc-linux-unknown-gcc-12.0.20210708.experimental
>
> all of these should be able to cross-build any powerpc kernel, but
> there is no obvious first choice (highest version, first in path,
> ordered list of target triples, ...). I tried coming up with a heuristic
> to pick a reasonable toolchain, but at some point gave up because
> I failed to express that in a readable bash or Makefile syntax.

Right; foremost in my mind was arm-linux-gnueabi-gcc vs
arm-linux-gnueabihf-gcc.  That's not even to mention the versioned
suffixes.

In terms of multiversion support; this series doesn't regress doing
things the hard/verbose way.  But I think for most users we can have a
simpler common case; folks can play with their $PATH or focus on more
hermetic builds if they want this new feature (CROSS_COMPILE
inference) AND support for multiple versions of the same toolchain.
-- 
Thanks,
~Nick Desaulniers

Powered by blists - more mailing lists