From: Alexander Sverdlin <alexander.sverdlin@nokia.com>
To: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
<linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH] tools: Remove conflicting BITS_PER_LONG define
Date: Mon, 24 Sep 2018 10:33:20 +0200 [thread overview]
Message-ID: <b9a95224-ece8-a23b-e759-48d3f89b3067@nokia.com> (raw)
In-Reply-To: <20180919130318.GB3717@redhat.com>
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.
next prev parent reply other threads:[~2018-09-24 8:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-12 17:02 Alexander Sverdlin
2018-09-12 19:01 ` Arnaldo Carvalho de Melo
2018-09-12 19:21 ` Arnaldo Carvalho de Melo
2018-09-19 12:28 ` Alexander Sverdlin
2018-09-19 13:03 ` Arnaldo Carvalho de Melo
2018-09-19 15:25 ` Alexander Sverdlin
2018-09-24 8:33 ` Alexander Sverdlin [this message]
2018-09-19 12:16 ` Alexander Sverdlin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b9a95224-ece8-a23b-e759-48d3f89b3067@nokia.com \
--to=alexander.sverdlin@nokia.com \
--cc=acme@kernel.org \
--cc=acme@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome