[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a1ctLcHuLZfBJ7wXHRmidpQZ4EZdML1nqPJVGYVTgHmaw@mail.gmail.com>
Date: Thu, 8 Jul 2021 09:27:38 +0200
From: Arnd Bergmann <arnd@...nel.org>
To: Christoph Hellwig <hch@...radead.org>
Cc: Nick Desaulniers <ndesaulniers@...gle.com>,
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 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. 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
/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.
Arnd
Powered by blists - more mailing lists