Em Fri, Jul 15, 2016 at 12:09:03PM -0300, Arnaldo Carvalho de Melo escreveu:
> 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...
Seems ok, but I'll reinstate this:
#if BITS_PER_LONG != __BITS_PER_LONG
#error Inconsistent word size. Check asm/bitsperlong.h
#endif
And now I'm rerunning these tests, that without the above check
produces:
# dm
alpine:3.4: Ok
android-ndk:r12b: Ok
centos:5: perf: Ok, objtool: FAIL # But this one predates this patch, I'll fix it
centos:6: Ok
centos:7: Ok
debian:7: Ok
debian:8: Ok
debian:experimental: Ok
fedora:21: Ok
fedora:22: Ok
fedora:23: Ok
fedora:24: Ok
fedora:rawhide: Ok
opensuse:13.2: Ok
opensuse:42.1: Ok
ubuntu:14.04.4: Ok
ubuntu:15.10: Ok
ubuntu:16.04: Ok
#
- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
