Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1443984 > unrolled thread

linux-next: build failure after merge of the luto-misc tree

Back to article view | Back to linux.kernel

Contents

  linux-next: build failure after merge of the luto-misc tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-07-15 09:10 +0200
    Re: linux-next: build failure after merge of the luto-misc tree Peter Zijlstra <peterz@infradead.org> - 2016-07-15 09:30 +0200
      Re: linux-next: build failure after merge of the luto-misc tree Peter Zijlstra <peterz@infradead.org> - 2016-07-15 09:40 +0200
        Re: linux-next: build failure after merge of the luto-misc tree Arnaldo Carvalho de Melo <acme@redhat.com> - 2016-07-15 17:10 +0200
          Re: linux-next: build failure after merge of the luto-misc tree Arnaldo Carvalho de Melo <acme@redhat.com> - 2016-07-15 17:30 +0200
            Re: linux-next: build failure after merge of the luto-misc tree Peter Zijlstra <peterz@infradead.org> - 2016-07-15 17:30 +0200
              Re: linux-next: build failure after merge of the luto-misc tree Arnaldo Carvalho de Melo <acme@redhat.com> - 2016-07-15 18:00 +0200
            Re: [PATCH/RFC] Re: linux-next: build failure after merge of the  luto-misc tree Peter Zijlstra <peterz@infradead.org> - 2016-07-15 17:50 +0200
              Re: [PATCH/RFC] Re: linux-next: build failure after merge of the  luto-misc tree Arnaldo Carvalho de Melo <acme@redhat.com> - 2016-07-15 18:30 +0200
                Re: [PATCH/RFC] Re: linux-next: build failure after merge of the  luto-misc tree "H. Peter Anvin" <hpa@zytor.com> - 2016-07-15 22:30 +0200
            [PATCH/RFC] Re: linux-next: build failure after merge of the  luto-misc tree Arnaldo Carvalho de Melo <acme@redhat.com> - 2016-07-15 17:50 +0200
              Re: [PATCH/RFC] Re: linux-next: build failure after merge of the  luto-misc tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-07-18 07:20 +0200
                Re: [PATCH/RFC] Re: linux-next: build failure after merge of the  luto-misc tree Andy Lutomirski <luto@amacapital.net> - 2016-07-18 22:10 +0200
                  Re: [PATCH/RFC] Re: linux-next: build failure after merge of the  luto-misc tree Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-07-18 22:40 +0200
                    Re: [PATCH/RFC] Re: linux-next: build failure after merge of the  luto-misc tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-07-19 00:30 +0200
                      Re: [PATCH/RFC] Re: linux-next: build failure after merge of the  luto-misc tree Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-07-19 01:50 +0200
                        Re: [PATCH/RFC] Re: linux-next: build failure after merge of the  luto-misc tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-07-19 02:30 +0200
                          Re: [PATCH/RFC] Re: linux-next: build failure after merge of the  luto-misc tree Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-07-19 02:40 +0200
                            Re: [PATCH/RFC] Re: linux-next: build failure after merge of the  luto-misc tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-07-19 05:30 +0200
                              Re: [PATCH/RFC] Re: linux-next: build failure after merge of the  luto-misc tree Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-07-19 15:00 +0200
                                Re: [PATCH/RFC] Re: linux-next: build failure after merge of the  luto-misc tree Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-07-19 19:50 +0200
                                  Re: [PATCH/RFC] Re: linux-next: build failure after merge of the  luto-misc tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-07-20 01:30 +0200
                                    Re: [PATCH/RFC] Re: linux-next: build failure after merge of the  luto-misc tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-07-20 02:00 +0200
                                      Re: [PATCH/RFC] Re: linux-next: build failure after merge of the  luto-misc tree Andy Lutomirski <luto@amacapital.net> - 2016-07-20 05:00 +0200
                                        Re: [PATCH/RFC] Re: linux-next: build failure after merge of the  luto-misc tree Arnaldo Carvalho de Melo <acme@redhat.com> - 2016-07-20 05:10 +0200
                                          Re: [PATCH/RFC] Re: linux-next: build failure after merge of the  luto-misc tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-07-20 05:20 +0200
                                      Re: [PATCH/RFC] Re: linux-next: build failure after merge of the  luto-misc tree Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-07-20 05:00 +0200
                                        Re: [PATCH/RFC] Re: linux-next: build failure after merge of the  luto-misc tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-07-21 01:40 +0200
                                          Re: [PATCH/RFC] Re: linux-next: build failure after merge of the  luto-misc tree Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-07-21 15:20 +0200
                                            Re: [PATCH/RFC] Re: linux-next: build failure after merge of the  luto-misc tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-07-22 01:30 +0200
                                              Re: [PATCH/RFC] Re: linux-next: build failure after merge of the  luto-misc tree Josh Poimboeuf <jpoimboe@redhat.com> - 2016-07-22 05:50 +0200
                                                Re: [PATCH/RFC] Re: linux-next: build failure after merge of the  luto-misc tree Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-07-22 16:40 +0200
                                                  Re: [PATCH/RFC] Re: linux-next: build failure after merge of the  luto-misc tree Josh Poimboeuf <jpoimboe@redhat.com> - 2016-07-22 21:20 +0200
                                                    Re: [PATCH/RFC] Re: linux-next: build failure after merge of the  luto-misc tree Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-07-22 21:40 +0200
                                                      Re: [PATCH/RFC] Re: linux-next: build failure after merge of the  luto-misc tree Josh Poimboeuf <jpoimboe@redhat.com> - 2016-07-22 21:50 +0200
                                                        Re: [PATCH/RFC] Re: linux-next: build failure after merge of the  luto-misc tree Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-07-22 22:00 +0200
                                                          Re: [PATCH/RFC] Re: linux-next: build failure after merge of the  luto-misc tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-07-23 07:10 +0200
                                                            Re: [PATCH/RFC] Re: linux-next: build failure after merge of the  luto-misc tree Andy Lutomirski <luto@amacapital.net> - 2016-07-24 20:50 +0200
                                                            Re: [PATCH/RFC] Re: linux-next: build failure after merge of the  luto-misc tree Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-07-25 15:00 +0200
                                                            [tip:perf/core] x86: Make the vdso2c compiler use the host  architecture headers tip-bot for Stephen Rothwell <tipbot@zytor.com> - 2016-07-25 20:20 +0200
                                                    [tip:perf/core] tools build: Fix objtool build with ARCH=x86_64 tip-bot for Josh Poimboeuf <tipbot@zytor.com> - 2016-07-25 20:20 +0200
                                                [tip:perf/core] objtool: Always use host headers tip-bot for Arnaldo Carvalho de Melo <tipbot@zytor.com> - 2016-07-25 20:20 +0200
      [tip:perf/core] tools: Simplify BITS_PER_LONG define tip-bot for Peter Zijlstra <tipbot@zytor.com> - 2016-07-16 22:50 +0200

Page 1 of 3  [1] 2 3  Next page →

#1443984 — linux-next: build failure after merge of the luto-misc tree

Hi Andy,

After merging the luto-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:

In file included from arch/x86/include/uapi/asm/bitsperlong.h:10:0,
                 from include/uapi/asm-generic/int-ll64.h:11,
                 from include/uapi/asm-generic/types.h:6,  
                 from arch/x86/include/uapi/asm/types.h:4,
                 from tools/include/linux/types.h:9,
                 from include/uapi/linux/elf.h:4,
                 from arch/x86/entry/vdso/vdso2c.c:66:
tools/include/asm-generic/bitsperlong.h:32:2: error: #error Inconsistent word size. Check asm/bitsperlong.h
 #error Inconsistent word size. Check asm/bitsperlong.h
  ^

Caused by commit

  6436d4c1a83c ("x86/vdso: Fail the build if the vdso image has no dynamic section")

interacting with commit

  2a00f026a15d ("tools: Fix up BITS_PER_LONG setting")

from the tip tree.

I am not sure why 6436d4c1a83c does this ... maybe it just causes
arch/x86/entry/vdso/vdso2c.c to be rebuilt?

I applied this partial revert of the latter commit:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 15 Jul 2016 16:58:25 +1000
Subject: [PATCH] tools: partial revert of 2a00f026a15d "tools: Fix up
 BITS_PER_LONG setting"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 tools/include/asm-generic/bitsperlong.h | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tools/include/asm-generic/bitsperlong.h b/tools/include/asm-generic/bitsperlong.h
index cfd661c6fc17..cb047bd03b69 100644
--- a/tools/include/asm-generic/bitsperlong.h
+++ b/tools/include/asm-generic/bitsperlong.h
@@ -28,7 +28,11 @@
 #define BITS_PER_LONG 32
 #endif /* CONFIG_64BIT */
 
-#if BITS_PER_LONG != __BITS_PER_LONG
+/*
+ * FIXME: The check currently breaks x86-64 build, so it's
+ * temporarily disabled. Please fix x86-64 and reenable
+ */
+#if 0 && BITS_PER_LONG != __BITS_PER_LONG
 #error Inconsistent word size. Check asm/bitsperlong.h
 #endif
 
-- 
2.8.1

-- 
Cheers,
Stephen Rothwell

[toc] | [next] | [standalone]

#1443991

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)


diff --git a/tools/include/asm-generic/bitsperlong.h b/tools/include/asm-generic/bitsperlong.h
index cfd661c6fc17..4b4c91b0f042 100644
--- a/tools/include/asm-generic/bitsperlong.h
+++ b/tools/include/asm-generic/bitsperlong.h
@@ -3,37 +3,6 @@
 
 #include <uapi/asm-generic/bitsperlong.h>
 
-/*
- * In the kernel, where this file comes from, we can rely on CONFIG_64BIT,
- * here we have to make amends with what the various compilers provides us
- * to figure out if we're on a 64-bit machine...
- */
-#ifdef __SIZEOF_LONG__
-# if __SIZEOF_LONG__ == 8
-#  define CONFIG_64BIT
-# endif
-#else
-# ifdef __WORDSIZE
-#  if __WORDSIZE == 64
-#   define CONFIG_64BIT
-#  endif
-# else
-#  error Failed to determine BITS_PER_LONG value
-# endif
-#endif
-
-#ifdef CONFIG_64BIT
-#define BITS_PER_LONG 64
-#else
-#define BITS_PER_LONG 32
-#endif /* CONFIG_64BIT */
-
-#if BITS_PER_LONG != __BITS_PER_LONG
-#error Inconsistent word size. Check asm/bitsperlong.h
-#endif
-
-#ifndef BITS_PER_LONG_LONG
-#define BITS_PER_LONG_LONG 64
-#endif
+#define BITS_PER_LONG (__CHAR_BIT__ * __SIZEOF_LONG__)
 
 #endif /* __ASM_GENERIC_BITS_PER_LONG */

[toc] | [prev] | [next] | [standalone]

#1444007

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.

[toc] | [prev] | [next] | [standalone]

#1444355

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

[toc] | [prev] | [next] | [standalone]

#1444374

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

[toc] | [prev] | [next] | [standalone]

#1444376

On Fri, Jul 15, 2016 at 12:24:36PM -0300, Arnaldo Carvalho de Melo wrote:
> Seems ok, but I'll reinstate this:
> 
> #if BITS_PER_LONG != __BITS_PER_LONG
> #error Inconsistent word size. Check asm/bitsperlong.h
> #endif

Confuses me; why do we have two?

Why not then do:

#define BITS_PER_LONG __BITS_PER_LONG

and be done with it?

[toc] | [prev] | [next] | [standalone]

#1444403

Em Fri, Jul 15, 2016 at 05:29:37PM +0200, Peter Zijlstra escreveu:
> On Fri, Jul 15, 2016 at 12:24:36PM -0300, Arnaldo Carvalho de Melo wrote:
> > Seems ok, but I'll reinstate this:
> > 
> > #if BITS_PER_LONG != __BITS_PER_LONG
> > #error Inconsistent word size. Check asm/bitsperlong.h
> > #endif
> 
> Confuses me; why do we have two?
> 
> Why not then do:
> 
> #define BITS_PER_LONG __BITS_PER_LONG
> 
> and be done with it?

Well, I just kept existing kernel practice, it uses __BITS_PER_LONG in
uapi files and BITS_PER_LONG elsewhere, since we copy stuff from the
kernel and check when it drifts using diff, I kept it like that so that
automation could point us when the tools/ copy drifted from the original
file.

- Arnaldo

[toc] | [prev] | [next] | [standalone]

#1444392 — Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

On Fri, Jul 15, 2016 at 12:43:26PM -0300, Arnaldo Carvalho de Melo wrote:
> Ok, same results, it works, queuing this one, ack?

Sure. Although I'm still somewhat puzzled by the duplicated effort of
__BITS_PER_LONG and BITS_PER_LONG.

> commit a08cc3e6f7bb965672a3ff60f98d0dbbc5334ee7
> Author: Peter Zijlstra <peterz@infradead.org>
> Date:   Fri Jul 15 12:38:18 2016 -0300
> 
>     tools: Simplify BITS_PER_LONG define
>     
>     Do it using (__CHAR_BIT__ * __SIZEOF_LONG__), simpler, works everywhere,
>     reduces the complexity by ditching CONFIG_64BIT, that was being
>     synthesized from yet another set of defines, which proved fragile,
>     breaking the build on linux-next for no obvious reasons.

If you ever do need to introduce CONFIG_64BIT, __LP64__ seems like the
right symbol to use for it.

[toc] | [prev] | [next] | [standalone]

#1444431 — Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

Em Fri, Jul 15, 2016 at 05:49:30PM +0200, Peter Zijlstra escreveu:
> On Fri, Jul 15, 2016 at 12:43:26PM -0300, Arnaldo Carvalho de Melo wrote:
> > Ok, same results, it works, queuing this one, ack?
> 
> Sure. Although I'm still somewhat puzzled by the duplicated effort of
> __BITS_PER_LONG and BITS_PER_LONG.

Well, I also can't think of something to justify that, would have to dig
deeper to figure out why that duplication was introduced.

Thanks, will queue this one up and be done with it. For the moment. :-)

- Arnaldo
 
> > commit a08cc3e6f7bb965672a3ff60f98d0dbbc5334ee7
> > Author: Peter Zijlstra <peterz@infradead.org>
> > Date:   Fri Jul 15 12:38:18 2016 -0300
> > 
> >     tools: Simplify BITS_PER_LONG define
> >     
> >     Do it using (__CHAR_BIT__ * __SIZEOF_LONG__), simpler, works everywhere,
> >     reduces the complexity by ditching CONFIG_64BIT, that was being
> >     synthesized from yet another set of defines, which proved fragile,
> >     breaking the build on linux-next for no obvious reasons.
> 
> If you ever do need to introduce CONFIG_64BIT, __LP64__ seems like the
> right symbol to use for it.

[toc] | [prev] | [next] | [standalone]

#1444556 — Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

On 07/15/16 09:28, Arnaldo Carvalho de Melo wrote:
> Em Fri, Jul 15, 2016 at 05:49:30PM +0200, Peter Zijlstra escreveu:
>> On Fri, Jul 15, 2016 at 12:43:26PM -0300, Arnaldo Carvalho de Melo wrote:
>>> Ok, same results, it works, queuing this one, ack?
>>
>> Sure. Although I'm still somewhat puzzled by the duplicated effort of
>> __BITS_PER_LONG and BITS_PER_LONG.
> 
> Well, I also can't think of something to justify that, would have to dig
> deeper to figure out why that duplication was introduced.
> 
> Thanks, will queue this one up and be done with it. For the moment. :-)
> 

I'm wondering if there are issues related to compat.

	-hpa

[toc] | [prev] | [next] | [standalone]

#1444398 — [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

Em Fri, Jul 15, 2016 at 12:24:36PM -0300, Arnaldo Carvalho de Melo escreveu:
> 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:
> > > > 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

Ok, same results, it works, queuing this one, ack? Stephen, does it work
for you?

commit a08cc3e6f7bb965672a3ff60f98d0dbbc5334ee7
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Fri Jul 15 12:38:18 2016 -0300

    tools: Simplify BITS_PER_LONG define
    
    Do it using (__CHAR_BIT__ * __SIZEOF_LONG__), simpler, works everywhere,
    reduces the complexity by ditching CONFIG_64BIT, that was being
    synthesized from yet another set of defines, which proved fragile,
    breaking the build on linux-next for no obvious reasons.
    
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Andy Lutomirski <luto@amacapital.net>,
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/20160715072243.GP30154@twins.programming.kicks-ass.net
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

diff --git a/tools/include/asm-generic/bitsperlong.h b/tools/include/asm-generic/bitsperlong.h
index cfd661c6fc17..4c7a9ab42424 100644
--- a/tools/include/asm-generic/bitsperlong.h
+++ b/tools/include/asm-generic/bitsperlong.h
@@ -3,30 +3,7 @@
 
 #include <uapi/asm-generic/bitsperlong.h>
 
-/*
- * In the kernel, where this file comes from, we can rely on CONFIG_64BIT,
- * here we have to make amends with what the various compilers provides us
- * to figure out if we're on a 64-bit machine...
- */
-#ifdef __SIZEOF_LONG__
-# if __SIZEOF_LONG__ == 8
-#  define CONFIG_64BIT
-# endif
-#else
-# ifdef __WORDSIZE
-#  if __WORDSIZE == 64
-#   define CONFIG_64BIT
-#  endif
-# else
-#  error Failed to determine BITS_PER_LONG value
-# endif
-#endif
-
-#ifdef CONFIG_64BIT
-#define BITS_PER_LONG 64
-#else
-#define BITS_PER_LONG 32
-#endif /* CONFIG_64BIT */
+#define BITS_PER_LONG (__CHAR_BIT__ * __SIZEOF_LONG__)
 
 #if BITS_PER_LONG != __BITS_PER_LONG
 #error Inconsistent word size. Check asm/bitsperlong.h

[toc] | [prev] | [next] | [standalone]

#1445213 — Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

Hi Arnaldo,

On Fri, 15 Jul 2016 12:43:26 -0300 Arnaldo Carvalho de Melo <acme@redhat.com> wrote:
>
> Ok, same results, it works, queuing this one, ack? Stephen, does it work
> for you?

Sorry, no.  See my other email.

I am cross building (if that makes a difference).

-- 
Cheers,
Stephen Rothwell

[toc] | [prev] | [next] | [standalone]

#1445805 — Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

On Sun, Jul 17, 2016 at 10:18 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Arnaldo,
>
> On Fri, 15 Jul 2016 12:43:26 -0300 Arnaldo Carvalho de Melo <acme@redhat.com> wrote:
>>
>> Ok, same results, it works, queuing this one, ack? Stephen, does it work
>> for you?
>
> Sorry, no.  See my other email.
>
> I am cross building (if that makes a difference).

I wonder if something's wrong with the way that hostprogs-y works if
the program includes kernel headers.

It's plausible that something like this:

https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vdso&id=424eb7848324efbfcffaf58b142db1a455a9628b

coupled with a change to make vdso2c or, more generally, hostprogs-y
use USERINCLUDE would help.

--Andy

[toc] | [prev] | [next] | [standalone]

#1445833 — Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

Em Mon, Jul 18, 2016 at 01:04:34PM -0700, Andy Lutomirski escreveu:
> On Sun, Jul 17, 2016 at 10:18 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > On Fri, 15 Jul 2016 12:43:26 -0300 Arnaldo Carvalho de Melo <acme@redhat.com> wrote:

> >> Ok, same results, it works, queuing this one, ack? Stephen, does it work
> >> for you?

> > Sorry, no.  See my other email.
> >
> > I am cross building (if that makes a difference).

For me to try to reproduce the problem, yes, what is the environment?
Cross-compiling to what target?
 
> I wonder if something's wrong with the way that hostprogs-y works if
> the program includes kernel headers.
> 
> It's plausible that something like this:
> 
> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vdso&id=424eb7848324efbfcffaf58b142db1a455a9628b
> 
> coupled with a change to make vdso2c or, more generally, hostprogs-y
> use USERINCLUDE would help.

There are still files outside tools/ that are being accessed by it, so,
yeah, this may have affected it, I'll try to do a final sweep untangling
this.

- Arnaldo

[toc] | [prev] | [next] | [standalone]

#1445879 — Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

Hi Arnaldo,

On Mon, 18 Jul 2016 17:36:34 -0300 Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
>
> Em Mon, Jul 18, 2016 at 01:04:34PM -0700, Andy Lutomirski escreveu:
> > On Sun, Jul 17, 2016 at 10:18 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:  
> > > On Fri, 15 Jul 2016 12:43:26 -0300 Arnaldo Carvalho de Melo <acme@redhat.com> wrote:  
> 
> > >> Ok, same results, it works, queuing this one, ack? Stephen, does it work
> > >> for you?  
> 
> > > Sorry, no.  See my other email.
> > >
> > > I am cross building (if that makes a difference).  
> 
> For me to try to reproduce the problem, yes, what is the environment?
> Cross-compiling to what target?

I am using a x86_64 compiler (target) on powerpc64le (host).
Yesterday, the x86_64 allmodconfig build failed just after I merged the
tip tree (i.e. without the luto-misc tree being involved).  At that
point I have merged quite a few trees, though.  Also, I do not clean my
object tree between builds.  The compiler is v5.2.0 built from upstream
sources.

-- 
Cheers,
Stephen Rothwell

[toc] | [prev] | [next] | [standalone]

#1445929 — Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

Em Tue, Jul 19, 2016 at 08:22:35AM +1000, Stephen Rothwell escreveu:
> Hi Arnaldo,
> 
> On Mon, 18 Jul 2016 17:36:34 -0300 Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> >
> > Em Mon, Jul 18, 2016 at 01:04:34PM -0700, Andy Lutomirski escreveu:
> > > On Sun, Jul 17, 2016 at 10:18 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:  
> > > > On Fri, 15 Jul 2016 12:43:26 -0300 Arnaldo Carvalho de Melo <acme@redhat.com> wrote:  
> > 
> > > >> Ok, same results, it works, queuing this one, ack? Stephen, does it work
> > > >> for you?  
> > 
> > > > Sorry, no.  See my other email.
> > > >
> > > > I am cross building (if that makes a difference).  
> > 
> > For me to try to reproduce the problem, yes, what is the environment?
> > Cross-compiling to what target?
> 
> I am using a x86_64 compiler (target) on powerpc64le (host).
> Yesterday, the x86_64 allmodconfig build failed just after I merged the
> tip tree (i.e. without the luto-misc tree being involved).  At that
> point I have merged quite a few trees, though.  Also, I do not clean my
> object tree between builds.  The compiler is v5.2.0 built from upstream
> sources.

Ok, one of the possible reasons was for tools/{include,lib,perf,objtool}
code to be including code directly from the kernel, and that was still
the case for some headers, I fixed those and pushed to Ingo now, if he
pulls lets see if this fixes things.

- Arnaldo

[toc] | [prev] | [next] | [standalone]

#1445952 — Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

Hi Arnaldo,

On Mon, 18 Jul 2016 20:41:32 -0300 Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
>
> Ok, one of the possible reasons was for tools/{include,lib,perf,objtool}
> code to be including code directly from the kernel, and that was still
> the case for some headers, I fixed those and pushed to Ingo now, if he
> pulls lets see if this fixes things.

If you have a single patch (or few) relative to yesterday's tip tree,
please send it to me as well and I will apply it as a fix patch if Ingo
doesn't get to pulling in time.

-- 
Cheers,
Stephen Rothwell

[toc] | [prev] | [next] | [standalone]

#1445956 — Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

Em Tue, Jul 19, 2016 at 10:26:29AM +1000, Stephen Rothwell escreveu:
> On Mon, 18 Jul 2016 20:41:32 -0300 Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> > Ok, one of the possible reasons was for tools/{include,lib,perf,objtool}
> > code to be including code directly from the kernel, and that was still
> > the case for some headers, I fixed those and pushed to Ingo now, if he
> > pulls lets see if this fixes things.
 
> If you have a single patch (or few) relative to yesterday's tip tree,
> please send it to me as well and I will apply it as a fix patch if Ingo
> doesn't get to pulling in time.

[acme@jouet linux]$ git log --pretty=oneline  9fcfcdf3c7b613c0d9536f57587456411b8a4e33..ae3c14a028ed10552803b68276b6833295ba18cf 
ae3c14a028ed10552803b68276b6833295ba18cf tools: Copy linux/{hash,poison}.h and check for drift
3aa0042769313b720142c0ef8514dac389e14ebe perf tools: Remove include/linux/list.h from perf's MANIFEST
de1e17b1d0c81be472039798698b517c8a68b516 tools: Copy the bitops files accessed from the kernel and check for drift
ad430729ae00dd63f7dcadbeb638e589bc03b5a3 Remove: kernel unistd*h files from perf's MANIFEST, not used
e0643c4e9fdb2e77ab83ca596460e2c9c15728aa perf tools: Remove tools/perf/util/include/linux/const.h
7e3f36411342a54f1981fa97b43550b8406a3d69 perf tools: Remove tools/perf/util/include/asm/byteorder.h
14f0652b4fbebd0b05da36a06b17ac6d4d87a8f8 perf tools: Add missing linux/compiler.h include to perf-sys.h

Available on my repo/branch:

git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git perf/core

I don't know exactly how linux-next works, would it be possible to merge in this branch
till it gets into tip/perf/core?

- Arnaldo

[toc] | [prev] | [next] | [standalone]

#1446002 — Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

Hi Arnaldo,

On Mon, 18 Jul 2016 21:39:06 -0300 Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
>
> Em Tue, Jul 19, 2016 at 10:26:29AM +1000, Stephen Rothwell escreveu:
>  
> > If you have a single patch (or few) relative to yesterday's tip tree,
> > please send it to me as well and I will apply it as a fix patch if Ingo
> > doesn't get to pulling in time.  
> 
> [acme@jouet linux]$ git log --pretty=oneline  9fcfcdf3c7b613c0d9536f57587456411b8a4e33..ae3c14a028ed10552803b68276b6833295ba18cf 
> ae3c14a028ed10552803b68276b6833295ba18cf tools: Copy linux/{hash,poison}.h and check for drift
> 3aa0042769313b720142c0ef8514dac389e14ebe perf tools: Remove include/linux/list.h from perf's MANIFEST
> de1e17b1d0c81be472039798698b517c8a68b516 tools: Copy the bitops files accessed from the kernel and check for drift
> ad430729ae00dd63f7dcadbeb638e589bc03b5a3 Remove: kernel unistd*h files from perf's MANIFEST, not used
> e0643c4e9fdb2e77ab83ca596460e2c9c15728aa perf tools: Remove tools/perf/util/include/linux/const.h
> 7e3f36411342a54f1981fa97b43550b8406a3d69 perf tools: Remove tools/perf/util/include/asm/byteorder.h
> 14f0652b4fbebd0b05da36a06b17ac6d4d87a8f8 perf tools: Add missing linux/compiler.h include to perf-sys.h
> 
> Available on my repo/branch:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git perf/core
> 
> I don't know exactly how linux-next works, would it be possible to merge in this branch
> till it gets into tip/perf/core?

OK, I added this to linux-next today (as a temporary measure), but it
fails the same way.  To be clear, I merged the above branch (without
the rest of the tip tree) and it fails the same way. :-(

It produces these errors (from the x86_64 allmodconfig build):

In file included from /home/sfr/next/next/tools/arch/x86/include/uapi/asm/bitsperlong.h:10:0,
                 from /usr/include/asm-generic/int-ll64.h:11,
                 from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
                 from /home/sfr/next/next/tools/include/linux/types.h:9,
                 from /home/sfr/next/next/tools/include/linux/list.h:4,
                 from elf.h:23,
                 from elf.c:30:
/home/sfr/next/next/tools/include/asm-generic/bitsperlong.h:13:2: error: #error Inconsistent word size. Check asm/bitsperlong.h
 #error Inconsistent word size. Check asm/bitsperlong.h
  ^

(and more similar).

I have applied my patch from yesterday ("tools: Simplify
__BITS_PER_LONG define"), and will continue on.

-- 
Cheers,
Stephen Rothwell

[toc] | [prev] | [next] | [standalone]

#1446428 — Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

Em Tue, Jul 19, 2016 at 01:26:08PM +1000, Stephen Rothwell escreveu:
> Hi Arnaldo,
> 
> On Mon, 18 Jul 2016 21:39:06 -0300 Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> >
> > Em Tue, Jul 19, 2016 at 10:26:29AM +1000, Stephen Rothwell escreveu:
> >  
> > > If you have a single patch (or few) relative to yesterday's tip tree,
> > > please send it to me as well and I will apply it as a fix patch if Ingo
> > > doesn't get to pulling in time.  
> > 
> > [acme@jouet linux]$ git log --pretty=oneline  9fcfcdf3c7b613c0d9536f57587456411b8a4e33..ae3c14a028ed10552803b68276b6833295ba18cf 
> > ae3c14a028ed10552803b68276b6833295ba18cf tools: Copy linux/{hash,poison}.h and check for drift
> > 3aa0042769313b720142c0ef8514dac389e14ebe perf tools: Remove include/linux/list.h from perf's MANIFEST
> > de1e17b1d0c81be472039798698b517c8a68b516 tools: Copy the bitops files accessed from the kernel and check for drift
> > ad430729ae00dd63f7dcadbeb638e589bc03b5a3 Remove: kernel unistd*h files from perf's MANIFEST, not used
> > e0643c4e9fdb2e77ab83ca596460e2c9c15728aa perf tools: Remove tools/perf/util/include/linux/const.h
> > 7e3f36411342a54f1981fa97b43550b8406a3d69 perf tools: Remove tools/perf/util/include/asm/byteorder.h
> > 14f0652b4fbebd0b05da36a06b17ac6d4d87a8f8 perf tools: Add missing linux/compiler.h include to perf-sys.h
> > 
> > Available on my repo/branch:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git perf/core
> > 
> > I don't know exactly how linux-next works, would it be possible to merge in this branch
> > till it gets into tip/perf/core?
> 
> OK, I added this to linux-next today (as a temporary measure), but it
> fails the same way.  To be clear, I merged the above branch (without
> the rest of the tip tree) and it fails the same way. :-(
> 
> It produces these errors (from the x86_64 allmodconfig build):
> 
> In file included from /home/sfr/next/next/tools/arch/x86/include/uapi/asm/bitsperlong.h:10:0,
>                  from /usr/include/asm-generic/int-ll64.h:11,
>                  from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
>                  from /home/sfr/next/next/tools/include/linux/types.h:9,
>                  from /home/sfr/next/next/tools/include/linux/list.h:4,
>                  from elf.h:23,
>                  from elf.c:30:
> /home/sfr/next/next/tools/include/asm-generic/bitsperlong.h:13:2: error: #error Inconsistent word size. Check asm/bitsperlong.h
>  #error Inconsistent word size. Check asm/bitsperlong.h
>   ^
> 
> (and more similar).
> 
> I have applied my patch from yesterday ("tools: Simplify
> __BITS_PER_LONG define"), and will continue on.

Ok, I'm trying the other way around, i.e. building a ppc64 kernel on a
x86_64 machine, that is one setup I have access to easily.

- Arnaldo

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.kernel

csiph-web