Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
In-Reply-To: <67595efc-410d-7517-d788-eb3c4d2d7129@mageia.org>
References: <CA+55aFxhx_tKGm02UySguvbyfB_7oTF31QfgOHCK0YkBvmfV0g@mail.gmail.com>
 <8f46ed9a-85c0-8df4-2d1e-d268cbc9d0e9@mageia.org> <CA+55aFwJAbr8_Xs0ZX9K2iAr8bf=ZgNnKTLopQe6jPCgEBemrA@mail.gmail.com>
 <7a5458da-4222-7480-00ed-a51bed2c1e39@mageia.org> <CA+55aFyD0OMV1eoc9wh_hLcnRhHq2FwJf4EZcORmHPNxTRSX9Q@mail.gmail.com>
 <daf0fbba-6357-1748-d583-bcb5edf067ec@mageia.org> <CA+55aFwiyuA4fKztofM-fdDSc+ZH9aAR1xksL8ZWRDE-pdXruw@mail.gmail.com>
 <CAK7LNAS=PvYVrLczeJT0utq3UHNL5YtSE_w=RjJYJ3SD9ALrYA@mail.gmail.com>
 <CA+55aFzNCQZHEz9P2a4ZSyWB0RxZcTkh5TVfwTmup-Y-6b8qjw@mail.gmail.com>
 <CA+55aFwAwoDdZRP6n9xXDPkeCUm35mmGH3fXv=r1HOZq1bpiGw@mail.gmail.com>
 <CAK7LNAS4Xb_CQ31t_cqt3q0zRFZ-O2n3+qkxXfxZB_jmqvFmWQ@mail.gmail.com>
 <f1f35cdf-bd03-54bb-7196-c13131f7d0fc@mageia.org> <CA+55aFxe+LooLzpvBLwW9Ehwomp45zdJ3a-P71ipHJzdMmtDkQ@mail.gmail.com>
 <67595efc-410d-7517-d788-eb3c4d2d7129@mageia.org>
From:   Masahiro Yamada <yamada.masahiro@socionext.com>
Date:   Sat, 9 Jun 2018 21:16:09 +0900
Message-ID: <CAK7LNAQiCz7bdDCyOc7VtA5=GdzT6nFp4kX7D21LEfFeJ8mURg@mail.gmail.com>
Subject: Re: building in 32bit chroot on x86_64 host broken
To:     Thomas Backlund <tmb@mageia.org>
Cc:     Linus Torvalds <torvalds@linux-foundation.org>,
        Ulf Magnusson <ulfalizer@gmail.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

2018-06-08 4:49 GMT+09:00 Thomas Backlund <tmb@mageia.org>:
>
> Den 2018-06-07 kl. 22:40, skrev Linus Torvalds:
>>
>> On Thu, Jun 7, 2018 at 12:35 PM Thomas Backlund <tmb@mageia.org> wrote:
>>>
>>> I can work around it for now (or keep the revert in our kernel builds
>>> for now) until it gets properly fixed...
>>
>> So rather than doing the revert, it's probably better if  your
>> workaround just does
>>
>>     make ARCH=i386 oldconfig
>>
>> (or maybe even just a "export ARCH=i386" in the environment)
>>
>> That should get you to continue to otherwise do the same thing.
>>
>> And if it turns out that your flow is the *only* one affected by this,
>> and nobody else complains, maybe we can just say "yeah, slight change
>> in build rules, easy to work around" and leave it at that.
>>
>>                  Linus
>
>
> Yeah, I can live with that too :)
>
> I just wanted to point out the regression in case it was not (sort of)
> intentional...


If you want to do 'make oldconfig' without setting ARCH,
maybe the following could work.


diff --git a/Makefile b/Makefile
index 019a5a0..b491e86 100644
--- a/Makefile
+++ b/Makefile
@@ -292,7 +292,7 @@ export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE
KERNELVERSION
 # then ARCH is assigned, getting whatever value it gets normally, and
 # SUBARCH is subsequently ignored.

-SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
+SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/x86_64/x86/ \
                                  -e s/sun4u/sparc64/ \
                                  -e s/arm.*/arm/ -e s/sa110/arm/ \
                                  -e s/s390x/s390/ -e s/parisc64/parisc/ \


or


diff --git a/Makefile b/Makefile
index 019a5a0..3586967 100644
--- a/Makefile
+++ b/Makefile
@@ -292,7 +292,7 @@ export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE
KERNELVERSION
 # then ARCH is assigned, getting whatever value it gets normally, and
 # SUBARCH is subsequently ignored.

-SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
+SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ \
                                  -e s/sun4u/sparc64/ \
                                  -e s/arm.*/arm/ -e s/sa110/arm/ \
                                  -e s/s390x/s390/ -e s/parisc64/parisc/ \


-- 
Best Regards
Masahiro Yamada