From: ebiederm@xmission.com (Eric W. Biederman)
To: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
masahiroy@kernel.org
Subject: Re: [GIT PULL 2/2] Kconfig updates for v4.18
Date: Mon, 18 Jun 2018 08:25:04 -0500 [thread overview]
Message-ID: <87r2l4jkgf.fsf@xmission.com> (raw)
In-Reply-To: <CAK7LNASMpvFgue9gZ=6Epq_Skt2pvTVOoT9w=SzA_uGR87KP-w@mail.gmail.com> (Masahiro Yamada's message of "Thu, 7 Jun 2018 02:18:18 +0900")
Masahiro Yamada <yamada.masahiro@socionext.com> writes:
> - drop CONFIG_CROSS_COMPILE support
aka
> commit f1089c92da791034af73478159626007cba7f092
> Author: Masahiro Yamada <yamada.masahiro@socionext.com>
> Date: Mon May 28 18:21:39 2018 +0900
>
> kbuild: remove CONFIG_CROSS_COMPILE support
>
> Kbuild provides a couple of ways to specify CROSS_COMPILE:
>
> [1] Command line
> [2] Environment
> [3] arch/*/Makefile (only some architectures)
> [4] CONFIG_CROSS_COMPILE
>
> [4] is problematic for the compiler capability tests in Kconfig.
> CONFIG_CROSS_COMPILE allows users to change the compiler prefix from
> 'make menuconfig', etc. It means, the compiler options would have
> to be all re-calculated everytime CONFIG_CROSS_COMPILE is changed.
>
> To avoid complexity and performance issues, I'd like to evaluate
> the shell commands statically, i.e. only parsing Kconfig files.
>
> I guess the majority is [1] or [2]. Currently, there are only
> 5 defconfig files that specify CONFIG_CROSS_COMPILE.
> arch/arm/configs/lpc18xx_defconfig
> arch/hexagon/configs/comet_defconfig
> arch/nds32/configs/defconfig
> arch/openrisc/configs/or1ksim_defconfig
> arch/openrisc/configs/simple_smp_defconfig
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> Reviewed-by: Kees Cook <keescook@chromium.org>
>
I just started working against 4.18-rc1 and discovered this.
This has broken my setup for building and testing changes on other
architectures. I have to put the name of the compiler prefix somewhere.
The mapping between the prefix to gcc and the linux architecture is
non-trivial. Especially with a lot of architectures in the test pool.
I am tired and frustrated this morning as this is going to keep me from
getting done what I had planned today.
This is a regression pure and simple. It breaks my workflow. Please
fix it.
Eric
next prev parent reply other threads:[~2018-06-18 13:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-06 17:18 [GIT PULL 2/2] Kconfig updates for v4.18 Masahiro Yamada
2018-06-06 18:41 ` Linus Torvalds
2018-06-18 13:25 ` Eric W. Biederman [this message]
2018-06-23 16:54 ` Randy Dunlap
2018-06-24 2:36 ` 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=87r2l4jkgf.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.