mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
To: "yamada.masahiro@socionext.com" <yamada.masahiro@socionext.com>
Cc: "keescook@chromium.org" <keescook@chromium.org>,
	"linux-kbuild@vger.kernel.org" <linux-kbuild@vger.kernel.org>,
	"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-snps-arc@lists.infradead.org" 
	<linux-snps-arc@lists.infradead.org>
Subject: Re: defconfig fails if CROSS_COMPILE is set while cross-gcc is not avaialble
Date: Wed, 12 Sep 2018 13:43:09 +0000	[thread overview]
Message-ID: <2c5d00f99db07df1a8cc5168d62d5764544fb83e.camel@synopsys.com> (raw)
In-Reply-To: <CAK7LNAR0ghuhDXUqJ=nX0dtbtoOvFff9Eeu-hHWLkTONG09GAQ@mail.gmail.com>

Hi Masahiro,

On Wed, 2018-09-12 at 21:53 +0900, Masahiro Yamada wrote:
> Hi Alexey.
> 
> 2018-09-12 21:08 GMT+09:00 Alexey Brodkin <Alexey.Brodkin@synopsys.com>:
> > Hello Masahiro-san,
> > 
> > Starting from kernel v4.17 it is no longer possible to install kernel headers
> > for ARC architecture if there's no cross-toolchain in PATH.
> 
> 
> Really?
> 
> I can do 'make ARCH=arc headers_install'
> with the latest Linus' tree.

Indeed "headers_install" works that way but is it OK to install headers
without previous configuration. In my experiment I don't see any differences
though for example OpenEmbedded on configuration step of "linux-libc-headers"
do "ARCH=xxx make allnoconfig", see 
https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc#L57

That might be some legacy but I'm not really sure,
worth asking OE people.

For the record in Buildroot no configuration happens for Linux headers,
see https://git.buildroot.org/buildroot/tree/package/linux-headers/linux-headers.mk#n106

> I see the following warnings, but possible to install kernel headers.
> 
> ./scripts/gcc-version.sh: line 26: arc-linux-gcc: command not found
> ./scripts/gcc-version.sh: line 27: arc-linux-gcc: command not found

Right... that happens because we're doing 2 hackish things:
1. Checking if current toolchain is configured for ARCompact (ARCv1) ISA
   or ARCv2. That's because we use toolchain's libgcc and so we want to warn
   a user if wrong toolchain is used early instead of leaving him to deal with
   final linkage failure.
   See: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arc/Makefile#n23

2. Asking CC for a path to libgcc
   See: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arc/Makefile#n82

[snip]

> I am trying to fix even those warnings
> by eliminating unneeded compiler invocation.  It is WIP.

And if (1) is not super important (in fact we used to live without it for years)
(2) requires implementation of libgcc in kernel sources (which BTW will make (1)
obsolete immediately). We do have it on our todo list though...

[snip]

> > That doesn't happen for ARM and other arches simply because for ARC
> > we define CROSS_COMPILE if it is not set by user, see:
> > 
https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_arch_arc_Makefile-23n9&d=DwIBaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=zJsa5MrAtDiYEWr5PZNS1aGk21ETa-qXzLPIddwvoQI&s=BU0ltPPoRLn3np_ba4HRHfH9i141uZjoS8jsJrg8SNc&e=
> 
> I do not think it is a good practice
> to forcibly set CROSS_COMPILE that users may not have.

Maybe so. Still some arches or random platforms do that.

> arch/m68k/Makefile uses cc-cross-prefix helper
> to set the first found compiler.

Well I'm not really sure we need to mess with CROSS_COMPILE in kernel.
I.e. there might be tons of variations depending on who toolchain was built
etc. So I'd better get rid of CROSS_COMPILE setup in our Makefile.

> > Still if CROSS_COMPILE is set before execution of "make defconfig"
> > then the same problem happens for others.
> > 
> > I was able to find a series of commits which cause this problem,
> > here they are:
> > ----------------------------->8--------------------------
> > 59f53855babf - gcc-plugins: test plugin support in Kconfig and clean up Makefile
> > 469cb7376c06 - kconfig: add CC_IS_CLANG and CLANG_VERSION
> > a4353898980c - kconfig: add CC_IS_GCC and GCC_VERSION
> > ----------------------------->8--------------------------
> > 
> > What happen is "$(CC)" is passed as an argument and in its turn CC is
> > "$(CROSS_COMPILE)gcc", see:
> > 
https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_Makefile-23n385&d=DwIBaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=zJsa5MrAtDiYEWr5PZNS1aGk21ETa-qXzLPIddwvoQI&s=S7zeHBpIp1P94XbyoMsaSnJWRqDGn69yGyeob-jzMJ4&e=
> > 
> > 
> > So if I substitute "CC" with "HOSTCC" in a couple of places (see below)
> > the problem goes away. But I'm not really sure if what I do is correct.
> > I.e. when we're interested in CC for target and when only host CC is of
> > our interest.
> 
> I think the log of commit 316d55d55f49eca44
> is a good source to know the background of this change.
> 
> Now Kconfig requires the target compiler.
> So, it does not make sense to
> do defconfig with non-existing compiler.

Agree, so I'll check with OpenEmbedded people if there's a reason to do "make allnoconfig"
if it's just a legacy code we'll fix it there.

Thanks a lot for all the input, much appreciated!

-Alexey

  reply	other threads:[~2018-09-12 13:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-12 12:08 Alexey Brodkin
2018-09-12 12:53 ` Masahiro Yamada
2018-09-12 13:43   ` Alexey Brodkin [this message]
2018-09-12 14:59     ` Masahiro Yamada

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2c5d00f99db07df1a8cc5168d62d5764544fb83e.camel@synopsys.com \
    --to=alexey.brodkin@synopsys.com \
    --cc=keescook@chromium.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-snps-arc@lists.infradead.org \
    --cc=yamada.masahiro@socionext.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®