[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160715150903.GA2523@redhat.com>
Date: Fri, 15 Jul 2016 12:09:04 -0300
From: Arnaldo Carvalho de Melo <acme@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Stephen Rothwell <sfr@...b.auug.org.au>,
Andy Lutomirski <luto@...capital.net>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
linux-next@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: linux-next: build failure after merge of the luto-misc tree
Em Fri, Jul 15, 2016 at 09:31:19AM +0200, Peter Zijlstra escreveu:
> On Fri, Jul 15, 2016 at 09:22:43AM +0200, Peter Zijlstra wrote:
> > On Fri, Jul 15, 2016 at 05:06:54PM +1000, Stephen Rothwell wrote:
> > > interacting with commit
> > >
> > > 2a00f026a15d ("tools: Fix up BITS_PER_LONG setting")
> > >
> > > from the tip tree.
> >
> > Yuck.. that thing is horrid :/
> >
> > What's wrong with so?
> >
> > And if you really want to retain CONFIG_64BIT (because other headers
> > might want it, and they currently do not) then do something like:
> >
> > #ifdef __LP64__
> > #define CONFIG_64BIT
> > #else
> > #define CONFIG_32BIT
> > #endif
> >
> > All GCC versions I checked have __CHAR_BIT__ and __SIZEOF_LONG__.
> >
> > (and I checked most everything from 4.4 - 6.1)
>
> clang-3.8 also defines all three of those, and I don't consider that a
> usable compiler as it doesn't even build a kernel.
I was trying to have that file as close to the kernel as possible, but
I'll try building with your patch in my test rig, lets see if one of the
dozens of distros/releases barf at that...
- Arnaldo
Powered by blists - more mailing lists