Re: Help needed fixing linux-libre-5.2 on aarch64

[Pierre Langlois]

Hi Mark!

Mark H Weaver writes:

> The 'kernel-updates' includes a preliminary commit to update linux-libre
> to version 5.2.  Berlin has built it successfully on all supported
> architectures except for aarch64, where it fails:
>
>   https://ci.guix.gnu.org/build/1448778/details
>
> I would be grateful if someone with access to aarch64 hardware could
> debug this and propose a fix.  Until then, I'm reluctant to push this
> update to 'master'.
>
> See below for the relevant excerpt from the build log.
>
>      Thanks,
>        Mark
>
>
> --8<---------------cut here---------------start------------->8---
>   CC [M]  arch/arm64/lib/xor-neon.o
> In file included from 
> /gnu/store/im7irb1qnmvwypz53dxv5i75wy94dcz5-glibc-2.28/include/stdint.h:34:0,
>                  from 
> /gnu/store/7ykq1909hf7jgkvqcxdz7r0dglnbx005-gcc-7.4.0-lib/lib/gcc/aarch64-unknown-linux-gnu/7.4.0/include/arm_neon.h:33,
>                  from ./arch/arm64/include/asm/neon-intrinsics.h:33,
>                  from arch/arm64/lib/xor-neon.c:11:
> /gnu/store/im7irb1qnmvwypz53dxv5i75wy94dcz5-glibc-2.28/include/bits/stdint-intn.h:27:19:
>  error: conflicting types for 'int64_t'
>  typedef __int64_t int64_t;
>                    ^~~~~~~
> In file included from ./include/linux/list.h:5:0,
>                  from ./include/linux/module.h:9,
>                  from arch/arm64/lib/xor-neon.c:10:
> ./include/linux/types.h:114:15: note: previous declaration of 'int64_t' was 
> here
>  typedef s64   int64_t;
>                ^~~~~~~
> In file included from 
> /gnu/store/im7irb1qnmvwypz53dxv5i75wy94dcz5-glibc-2.28/include/stdint.h:37:0,
>                  from 
> /gnu/store/7ykq1909hf7jgkvqcxdz7r0dglnbx005-gcc-7.4.0-lib/lib/gcc/aarch64-unknown-linux-gnu/7.4.0/include/arm_neon.h:33,
>                  from ./arch/arm64/include/asm/neon-intrinsics.h:33,
>                  from arch/arm64/lib/xor-neon.c:11:
> /gnu/store/im7irb1qnmvwypz53dxv5i75wy94dcz5-glibc-2.28/include/bits/stdint-uintn.h:27:20:
>  error: conflicting types for 'uint64_t'
>  typedef __uint64_t uint64_t;
>                     ^~~~~~~~
> In file included from ./include/linux/list.h:5:0,
>                  from ./include/linux/module.h:9,
>                  from arch/arm64/lib/xor-neon.c:10:
> ./include/linux/types.h:112:15: note: previous declaration of 'uint64_t' was 
> here
>  typedef u64   uint64_t;
>                ^~~~~~~~
> make[1]: *** [scripts/Makefile.build:285: arch/arm64/lib/xor-neon.o] Error 1
> make: *** [Makefile:1071: arch/arm64/lib] Error 2
> --8<---------------cut here---------------end--------------->8---

I have access to some hardware at the moment so I thought I'd give this
a shot and yeah, I can reproduce it! I have access to a softiron board
(that's the same as what's on berlin.guixsd.org right?) running Ubuntu
with guix installed on top.

The strange thing is, the failure only happens with building using guix,
I can build linux on the board from source just fine:

```
# From a local checkout of linux (not linux-libre)
~/linux ((v5.2))$ guix environment -C linux-libre
~/linux [env]$ make defconfig
~/linux [env]$ make -j8
# OK
```

Whereas with `guix build linux-libre` I can see the error. And it still
happens if I keep the build around with `guix build -K linux-libre`:

```
/tmp/guix-build-linux-libre-5.2.drv-0/linux-5.2$ source ../environment-variables
/tmp/guix-build-linux-libre-5.2.drv-0/linux-5.2$ make -j8
  CALL    scripts/atomic/check-atomics.sh
  CALL    scripts/checksyscalls.sh
  CHK     include/generated/compile.h
./scripts/mkcompile_h: line 47: hostname: command not found
  CC [M]  arch/arm64/lib/xor-neon.o
In file included from 
/gnu/store/im7irb1qnmvwypz53dxv5i75wy94dcz5-glibc-2.28/include/stdint.h:34:0,
                 from 
/gnu/store/7ykq1909hf7jgkvqcxdz7r0dglnbx005-gcc-7.4.0-lib/lib/gcc/aarch64-unknown-linux-gnu
/7.4.0/include/arm_neon.h:33,
                 from ./arch/arm64/include/asm/neon-intrinsics.h:33,
                 from arch/arm64/lib/xor-neon.c:11:
/gnu/store/im7irb1qnmvwypz53dxv5i75wy94dcz5-glibc-2.28/include/bits/stdint-intn.h:27:19:
 error: conflicting types
 for 'int64_t'
 typedef __int64_t int64_t;
                   ^~~~~~~
In file included from ./include/linux/list.h:5:0,
                 from ./include/linux/module.h:9,
                 from arch/arm64/lib/xor-neon.c:10:
./include/linux/types.h:114:15: note: previous declaration of 'int64_t' was here
 typedef s64   int64_t;
               ^~~~~~~
In file included from 
/gnu/store/im7irb1qnmvwypz53dxv5i75wy94dcz5-glibc-2.28/include/stdint.h:37:0,
                 from 
/gnu/store/7ykq1909hf7jgkvqcxdz7r0dglnbx005-gcc-7.4.0-lib/lib/gcc/aarch64-unknown-linux-gnu
/7.4.0/include/arm_neon.h:33,
                 from ./arch/arm64/include/asm/neon-intrinsics.h:33,
                 from arch/arm64/lib/xor-neon.c:11:
/gnu/store/im7irb1qnmvwypz53dxv5i75wy94dcz5-glibc-2.28/include/bits/stdint-uintn.h:27:20:
 error: conflicting type
s for 'uint64_t'
 typedef __uint64_t uint64_t;
                    ^~~~~~~~
In file included from ./include/linux/list.h:5:0,
                 from ./include/linux/module.h:9,
                 from arch/arm64/lib/xor-neon.c:10:
./include/linux/types.h:112:15: note: previous declaration of 'uint64_t' was 
here
 typedef u64   uint64_t;
               ^~~~~~~~
make[1]: *** [scripts/Makefile.build:285: arch/arm64/lib/xor-neon.o] Error 1
make: *** [Makefile:1071: arch/arm64/lib] Error 2
make: *** Waiting for unfinished jobs....
```

So I tried to compare the environments and saw we had a
'work-around-gcc-7-include-path-issue phase:

```
(add-before 'configure 'work-around-gcc-7-include-path-issue
  (lambda _
    (unsetenv "C_INCLUDE_PATH")
    (unsetenv "CPLUS_INCLUDE_PATH")
    #t))
```

And if I remove it then the error goes away! The build hasn't finished
yet for me, but it's gone past the offending xor-neon.c file so we
/should/ be good.

I'm not really sure why though, do you know why this phase was required
at the time? I haven't tested that linux-libre still builds on x86 with
this phase removed yet, trying it now.

Hope this helps!

Thanks,
Pierre