Messages in this thread | | | Subject | Re: [PATCH] tools: Remove conflicting BITS_PER_LONG define | From | Alexander Sverdlin <> | Date | Mon, 24 Sep 2018 10:33:20 +0200 |
| |
Hello Arnaldo,
>>>> Em Wed, Sep 12, 2018 at 07:02:32PM +0200, Alexander Sverdlin escreveu: >>>>> CC .../tools/objtool/builtin-check.o >>>>> ... >>>>> In file included from .../tools/arch/x86/include/uapi/asm/bitsperlong.h:11:0, >>>>> from .../tools/include/asm-generic/bitops/__ffs.h:6, >>>>> from .../tools/include/asm-generic/bitops.h:16, >>>>> from .../tools/include/linux/bitops.h:35, >>>>> from .../tools/include/linux/hashtable.h:13, >>>>> from elf.h:24, >>>>> from check.h:22, >>>>> from builtin-check.c:30: >>>>> .../tools/include/asm-generic/bitsperlong.h:8:0: error: "BITS_PER_LONG" redefined [-Werror] >>>>> #define BITS_PER_LONG (__CHAR_BIT__ * __SIZEOF_LONG__)
[...]
finally I more or less know what happens here. In the actual Linux we have two files defining the same define:
>> # 1 ".../tools/include/linux/bitops.h" 1
#ifndef BITS_PER_LONG # define BITS_PER_LONG __WORDSIZE #endif
>> # 6 ".../tools/include/asm-generic/bitsperlong.h" 2
#ifdef __SIZEOF_LONG__ #define BITS_PER_LONG (__CHAR_BIT__ * __SIZEOF_LONG__) #else #define BITS_PER_LONG __WORDSIZE #endif
So the two defines only work together if bitsperlong.h is included first. In objtool both files are included and for most people bitsperlong.h is indeed included first.
> I'll try and get one for building a x86_64 tools/perf, > tools/lib/{api,bpf,traceevent} to see if I manage to reproduce the > problem you're reporting.
One way to reproduce the reverted include order is to take a HOST compiler built against old Linux headers, namely 2.6.30 and older. This is because of the changes in asm/types.h.
It would be possible to put a guard into bitsperlong.h (#ifndef BITS_PER_LONG), but it just doesn't look correct to me that we have two files defining the same thing once quite simple, in the second case even more tricky.
-- Best regards, Alexander Sverdlin.
| |