linux-linaro ll-20121221.1 does not build for arm64

[John Rigby]

Build fails for arm64:

git reset ll-20121221.1
export CROSS_COMPILE=arm-linux-gnueabi-
export ARCH=arm64
make defconfig
make init/main.o
  CC init/main.o
In file included from /home/jcrigby/work/git-trees/linaro-raring/linaro-raring/arch/arm64/include/asm/processor.h:30:0,
                 from /home/jcrigby/work/git-trees/linaro-raring/linaro-raring/arch/arm64/include/asm/spinlock.h:20,
                 from include/asm-generic/bitops/atomic.h:8,
                 from /home/jcrigby/work/git-trees/linaro-raring/linaro-raring/arch/arm64/include/asm/bitops.h:48,
                 from include/linux/bitops.h:22,
                 from include/linux/kernel.h:10,
                 from include/linux/sched.h:15,
                 from /home/jcrigby/work/git-trees/linaro-raring/linaro-raring/arch/arm64/include/asm/compat.h:25,
                 from /home/jcrigby/work/git-trees/linaro-raring/linaro-raring/arch/arm64/include/asm/stat.h:23,
                 from include/linux/stat.h:5,
                 from include/linux/module.h:10,
                 from init/main.c:13:
include/linux/string.h:23:15: warning: conflicting types for built-in function ‘strncpy’ [enabled by default]
include/linux/string.h:32:15: warning: conflicting types for built-in function ‘strncat’ [enabled by default]
include/linux/string.h:41:12: warning: conflicting types for built-in function ‘strncmp’ [enabled by default]
include/linux/string.h:50:12: warning: conflicting types for built-in function ‘strncasecmp’ [enabled by default]
include/linux/string.h:77:24: warning: conflicting types for built-in function ‘strlen’ [enabled by default]
include/linux/string.h:89:24: warning: conflicting types for built-in function ‘strspn’ [enabled by default]
include/linux/string.h:92:24: warning: conflicting types for built-in function ‘strcspn’ [enabled by default]
include/linux/string.h:96:15: warning: conflicting types for built-in function ‘memset’ [enabled by default]
include/linux/string.h:99:15: warning: conflicting types for built-in function ‘memcpy’ [enabled by default]
include/linux/string.h:102:15: warning: conflicting types for built-in function ‘memmove’ [enabled by default]
include/linux/string.h:108:12: warning: conflicting types for built-in function ‘memcmp’ [enabled by default]
include/linux/string.h:111:15: warning: conflicting types for built-in function ‘memchr’ [enabled by default]
In file included from include/linux/sched.h:15:0,
                 from /home/jcrigby/work/git-trees/linaro-raring/linaro-raring/arch/arm64/include/asm/compat.h:25,
                 from /home/jcrigby/work/git-trees/linaro-raring/linaro-raring/arch/arm64/include/asm/stat.h:23,
                 from include/linux/stat.h:5,
                 from include/linux/module.h:10,
                 from init/main.c:13:
include/linux/kernel.h:326:5: warning: conflicting types for built-in function ‘snprintf’ [enabled by default]
include/linux/kernel.h:328:5: warning: conflicting types for built-in function ‘vsnprintf’ [enabled by default]
In file included from include/linux/stat.h:5:0,
                 from include/linux/module.h:10,
                 from init/main.c:13:
/home/jcrigby/work/git-trees/linaro-raring/linaro-raring/arch/arm64/include/asm/stat.h:29:8: error: redefinition of ‘struct stat64’
In file included from /home/jcrigby/work/git-trees/linaro-raring/linaro-raring/arch/arm64/include/uapi/asm/stat.h:16:0,
                 from /home/jcrigby/work/git-trees/linaro-raring/linaro-raring/arch/arm64/include/asm/stat.h:19,
                 from include/linux/stat.h:5,
                 from include/linux/module.h:10,
                 from init/main.c:13:
/home/jcrigby/work/git-trees/linaro-raring/linaro-raring/include/uapi/asm-generic/stat.h:48:8: note: originally defined here
make[1]: *** [init/main.o] Error 1
make: *** [init/main.o] Error 2

[John Rigby (jcrigby)]

git bisect point to:
http://git.linaro.org/gitweb?p=kernel/linux-linaro-tracking.git;a=commit;h=05a789f13dad6247198edc55423be09236411b76

reverting requires a bit of conflict resolution but fixes the build error patch attached.

[Ryan Harkin (ryanharkin)]

This is also related to this bug:
https://bugs.launchpad.net/bugs/1088375

And a relevant email conversation between Bero and Catalin:

On 19 December 2012 10:48, Catalin Marinas <email address hidden> wrote:
> On Wed, Dec 19, 2012 at 12:01:47AM +0000, Bernhard Rosenkränzer wrote:
>> On 18 December 2012 13:27, Catalin Marinas <email address hidden> wrote:
>> > Is this really needed for arm64? perf seems to define its own
>> > BITS_PER_LONG in tools/perf/util/include/linux/bitops.h.
>>
>> The reason why I added the header back is that something other than
>> compat-android.h tried to #include <asm/bitsperlong.h> and produced an error
>> because the file didn't exist. (I don't remember where exactly it was, but I
>> think somewhere in libtraceevent).
>
> kernel/trace/trace_probe.h is the only non-arch code that includes
> asm/bitsperlong.h. I used to have an asm/bitsperlong.h file which
> defined __BITS_PER_LOG to 64 and included asm-generic/bitsperlong.h.
> This file disappeared with the UAPI changes but I haven't noticed any
> issues since no code that I build included it.
>
> Anyway, a better fix would be to just add generic-y = bitsperlong.h in
> arch/arm64/include/asm/Kbuild when needed.
>
>> grep shows that has since been fixed, so it's probably safe to remove the
>> header again (and just include perf/util/include/linux/bitops.h from
>> compat-android.h).
>
> In the perf case, since it's a user space tool, you should rather use
> the uapi/bitsperlong.h header with the __BITS_PER_LONG definition which
> is always 64, unconditionally. Or just use the perf definition.
> BITS_PER_LONG is an in-kernel definition, not meant to be exported to
> user.

[Bernhard Rosenkraenzer (berolinux)]

I've sent a patch that fixes all cases earlier...

Attaching it again, this replaces all the other perf/Android patches (revert them and apply this one instead).

[Zach Pfeffer (pfefferz)]

From Andrea, ETA: will have the patch (the one attached to the bug) in linux-linaro tomorrow.

[John Rigby (jcrigby)]

I have updated the jenkins job to temporarily use an alternate repo/branch with the old perf patches reverted and the new one applied. The kernel now builds on jenkins. Waiting ppa build results.

[Andrey Konovalov (andrey-konovalov)]

Removed the previous Android perf patches, applied the one attached to this bug, and pushed the result to linux-linaro branch, the ll-20130110.0 tag. No success in build-testing it locally (no proper toolchain so far), will try setting up a jenkins job tomorrow.

[Andrey Konovalov (andrey-konovalov)]

The "make init/main.o" test from the bug description passed ok.

[Andrey Konovalov (andrey-konovalov)]

make vmlinux passed ok, make modules failed with:

CC [M] drivers/gator/gator_main.o
In file included from /home/ynk/git.linaro.org/linux-linaro/drivers/gator/gator_main.c:170:0:
/home/ynk/git.linaro.org/linux-linaro/drivers/gator/gator_trace_power.c:12:28: fatal error: asm/mach-types.h: No such file or directory
compilation terminated.

[Bernhard Rosenkraenzer (berolinux)]

If we disable gator, we run into yet another perf related problem -- not one related to perf code itself though, so no more modification of that monstrosity ;)

The problem is that we're building a 64 bit kernel with a 32 bit userland, but perf expects to be built for the target. Building a 64bit perf without a 64 bit libc can't possibly work though - so the claims that it can't find libc are valid.

The correct fix must be changing ARCH=/CROSS_COMPILE= -- looking at the Makefiles now.

[Bernhard Rosenkraenzer (berolinux)]

The fix for the Gator build is attached.

The fix for the remaining perf issue is committed on device/linaro/common (shouldn't try to build a 64bit perf without a 64bit libc...)

[Tixy (Jon Medhurst) (tixy)]

I don't think we expect Gator to work on arm64, and it is disabled in
the config fragment:
http://git.linaro.org/gitweb?p=kernel/configs.git;a=commit;h=ce22cb982059cfb7e3bc772ef9a7f6c547e478d8

As the failing build is not using this, but using the defconfig instead,
I'll produce a patch to fix that...

--
Tixy

[Ryan Harkin (ryanharkin)]

I'm concerned that adding perf has broken a lot of unrelated stuff.

I think the right thing to do here, rather than modifying other components, is to remove perf and get the kernel building again; then look at adding perf in a way that doesn't break other components.

There are a few combos that need to keep working: arm/arm64 and ubuntu/android. Any changes need to work on them all.

Modifying gator on linux-linaro is not a wise thing to do, as it is an upstream project that we pull. So, to make life easier, Tixy will disable gator from building on arm64; he's doing that now and will give Andrey a patch to pull. That way, we don't need to modify gator to carry on and we don't need to apply the gator patch above.

I hope that helps rather than hinders.