[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <28026f53-714a-b76d-00da-562c7612e265@mageia.org>
Date: Tue, 5 Jun 2018 22:35:43 +0259
From: Thomas Backlund <tmb@...eia.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
Ulf Magnusson <ulfalizer@...il.com>
CC: Masahiro Yamada <yamada.masahiro@...ionext.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: building in 32bit chroot on x86_64 host broken
Den 2018-06-05 kl. 22:13, skrev Linus Torvalds:
> On Tue, Jun 5, 2018 at 11:50 AM Thomas Backlund <tmb@...eia.org> wrote:
>>> but why do you care?
>> Because without it running the build in the 32bit chroot will get the
>> initial reported issue:
> Ahh. I can re-create that now.
>
> Yes, doing
>
> make ARCH=i386 allnoconfig
>
> followed by
>
> make oldconfig
>
> is broken. And doing a trivial "git bisect run" to pinpoint where
> CONFIG_64BIT goes away gives us
>
> f467c5640c29ad258c3cd8186a776c82fc3b8057 is the first bad commit
>
> which does that
>
> "kconfig: only write '# CONFIG_FOO is not set' for visible symbols"
>
> and it turns out that CONFIG_64BIT is not a visible symbol on x86-32,
> because that question is disabled when ARCH != "x86".
>
> bool "64-bit kernel" if ARCH = "x86"
>
> And the problem with that, is that *next* time around this config file
> is used, because we don't have that
>
> # CONFIG_64BIT is not set
>
> line, we don't turn it into
>
> CONFIG_64BIT=n
>
> and then the "depends on" in X86_64
>
> config X86_64
> def_bool y
> depends on 64BIT
>
> no longer hides it.
>
> Hmm. Ulf, Masahiro, comments?
>
> Should we just revert that commit?
>
> Thomas, can you verify that a
>
> git revert f467c5640c29ad258c3cd8186a776c82fc3b8057
>
> fixes the problem for you?
>
> Linus
Yep, that fixes it so it works both in the 32bit chroot and on the
64bit host
--
Thomas
Powered by blists - more mailing lists