Messages in this thread | | | From | Masahiro Yamada <> | Date | Wed, 6 Jun 2018 12:31:10 +0900 | Subject | Re: building in 32bit chroot on x86_64 host broken |
| |
Hi Linus,
2018-06-06 11:19 GMT+09:00 Linus Torvalds <torvalds@linux-foundation.org>: > On Tue, Jun 5, 2018 at 6:54 PM Linus Torvalds > <torvalds@linux-foundation.org> wrote: >> >> But once you *have* that particular Kconfig, I do think that "make >> oldconfig" should just work. And it apparently used to. >> >> So I think this is a behavioral regression. > > That doesn't necessarily mean that he fix should be to revert.
If this is a regression, I am OK with the revert, and it is the only quick solution.
> Maybe the fix is to simply change how we generate the ARCH variable. > > Right now, in the Makefile, it is > > ARCH ?= $(SUBARCH) > > so basically "if the user didn't specify ARCH, we pick it from SUBARCH". > > But that doesn't make much sense for "make oldconfig" does it? > > So maybe we could make the rule be that if the user didn't specify > ARCH explicitly, we take it from SUBARCH, _except_ if we are doing > "make oldconfig", in which case we take it from the .config file. > > That makes a certain amount of sense, wouldn't you agree? Doing > "oldconfig" and silently changing ARCH under the user seems pretty > user-hostile. > > In fact, I think it would _always_ make sense to take ARCH from the > config file, _unless_ we're actively generating a new config file > entirely (ie "make *config", not counting "oldconfig"). > > Hmm? > > Linus
This is a big hammer.
It is difficult to make a quick answer.
In fact, I saw a patch series a few years ago.
https://lkml.org/lkml/2014/9/1/70
It was not accepted. (I was not a maintainer at that time)
I do not remember the details, but I thought it was a double-edged sword.
-- Best Regards Masahiro Yamada
| |