On Mon, Nov 17, 2025 at 8:00 AM Max Krummenacher max.oss.09@gmail.com wrote:

Hi

Our CI found a regression when cross-compiling perf from the 6.1.159-rc1 sources in a yocto setup for a arm64 based machine.

In file included from .../tools/include/linux/bitmap.h:6, from util/pmu.h:5, from builtin-list.c:14: .../tools/include/asm-generic/bitsperlong.h:14:2: error: #error Inconsistent word size. Check asm/bitsperlong.h 14 | #error Inconsistent word size. Check asm/bitsperlong.h | ^~~~~

I could reproduce this as follows in a simpler setup:

git clone -b linux-6.1.y https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git cd linux-stable-rc/ export ARCH=arm64 export CROSS_COMPILE=aarch64-none-linux-gnu- make defconfig make -j$(nproc) cd tools/perf make

Reverting commit 4d99bf5f8f74 ("tools bitmap: Add missing asm-generic/bitsperlong.h include") fixed the build in my setup however I think that the issue the commit addresses would then reappear, so I don't know what would be a good way forward.

Hi,

To my knowledge the build issue fixed by 4d99bf5f8f74 ("tools bitmap: Add missing asm-generic/bitsperlong.h include") only showed up in Google's build infrastructure. Doing the revert should be fine, but when you move forward to a newer kernel the issue will reappear. Tbh, I think there is a lot of cruft in areas like this. The perf tool is using linux/types.h to have code that's interchangeable with the kernel, but we could just use stdint.h and be more C compatible. The version of something like types.h that perf uses matches the kernel version and not the UAPI version. The use of IS_ERR (and err pointers) is just copying bad kernel code into user land, we should just use errno, etc.

Why this issue appears in 6.1 and not 6.6, that's also confusing to me.

Looking at the error in the code: ``` #ifdef __SIZEOF_LONG__ #define BITS_PER_LONG (__CHAR_BIT__ * __SIZEOF_LONG__) #else #define BITS_PER_LONG __WORDSIZE #endif

#if BITS_PER_LONG != __BITS_PER_LONG #error Inconsistent word size. Check asm/bitsperlong.h #endif ```

It would be interesting to see where __BITS_PER_LONG is coming from. You can make the build verbose with V=1 and then run the CC command with -E to gather details. My suspicion is that we've gotten a muddle of your system's header files and those in perf, due to the include order, etc. and the resultant combination is why the test fails. It could be in 6.6 we added an extra header file in the perf tree and the include order picks that up first there. It may be possible to suggest that such an addition to tools/include is backported to 6.1.

A final note, the perf tool is backward compatible with old kernels and so it should be fine to just have the latest perf and run it on an old kernel.

Thanks, Ian

Regards Max

P.S. Checking out Linux 6.6.117-rc1 builds perf. make NO_LIBELF=1 NO_JEVENTS=1 NO_LIBTRACEEVENT=1