Subject: Re: bug#37593: [core-updates] Linux-Libre fails to build on aarch64-linux

From: Marius Bakke <[email-masked]>
Date: Sat, 05 Oct 2019 14:38:55 +0200

Pierre Langlois <[email-masked]> writes:

> Hi Marius,
>
> Marius Bakke writes:
>
>> Berlin fails to build "linux-libre" for AArch64 on the 'core-updates'
>> branch.  Here is a recent attempt:
>>
>> https://ci.guix.gnu.org/build/1758844/details
>>
>> Log file for the latest build:
>>
>> https://ci.guix.gnu.org/log/aq2rnrmjsgnyk8vmsm7aa3mgdj39dcwh-linux-libre-5.2.17.drv
>>
>> This seems to be the salient bit:
>>
>> CC [M]  arch/arm64/lib/xor-neon.o
>> In file included from /gnu/store/nr1aw4i32h7rmxwmq7d2da0mwcwg551j-glibc-2.29/include/stdint.h:34:0,
>>                  from /gnu/store/yckkivhynk4hjcr0iry9vbcyc0lqqnxj-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/nr1aw4i32h7rmxwmq7d2da0mwcwg551j-glibc-2.29/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/nr1aw4i32h7rmxwmq7d2da0mwcwg551j-glibc-2.29/include/stdint.h:37:0,
>>                  from /gnu/store/yckkivhynk4hjcr0iry9vbcyc0lqqnxj-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/nr1aw4i32h7rmxwmq7d2da0mwcwg551j-glibc-2.29/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:1073: arch/arm64/lib] Error 2
>> make: *** Waiting for unfinished jobs....
>>
>> Not sure what's going on here.  Ideas?
>
> Ha, that looks familiar, the same issue happened back in July:
> https://lists.gnu.org/archive/html/guix-devel/2019-07/msg00175.html
>
> I don't think we worked out what was the problem exactly though :-/

So I was able to build it with this patch:

From 43d2ab5a046e5da378f062cb2885c1345278d378 Mon Sep 17 00:00:00 2001
From: Marius Bakke <[email-masked]>
Date: Fri, 4 Oct 2019 21:36:42 +0200
Subject: [PATCH] gnu: linux-libre: Hide glibc from CPATH during build.

Fixes <https://bugs.gnu.org/37593>.

* gnu/packages/linux.scm (make-linux-libre*)[arguments]: Drop "libc" from CPATH.
---
 gnu/packages/linux.scm | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index dda95c29ac..525b18d1e2 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -663,6 +663,7 @@ for ARCH and optionally VARIANT, or #f if there is no such configuration."
      `(#:modules ((guix build gnu-build-system)
                   (guix build utils)
                   (srfi srfi-1)
+                  (srfi srfi-26)
                   (ice-9 match))
        #:phases
        (modify-phases %standard-phases
@@ -679,6 +680,18 @@ for ARCH and optionally VARIANT, or #f if there is no such configuration."
              ,@(if (%current-target-system)
                    '((unsetenv "CROSS_CPATH"))
                    '())
+
+             ;; On AArch64 (at least), we need to remove glibc headers from CPATH
+             ;; (they are still available as "system headers"), so that the kernel
+             ;; can override uint64_t.  See <https://bugs.gnu.org/37593>.
+             (setenv "CPATH"
+                     (string-join
+                      (remove (cut string-prefix? (assoc-ref inputs "libc") <>)
+                              (string-split (getenv "CPATH") #\:))
+                      ":"))
+             (format #t "environment variable `CPATH' changed to `~a'~%"
+                     (getenv "CPATH"))
+
              ;; Avoid introducing timestamps
              (setenv "KCONFIG_NOTIMESTAMP" "1")
              (setenv "KBUILD_BUILD_TIMESTAMP" (getenv "SOURCE_DATE_EPOCH"))
-- 
2.23.0

It's not very pretty though.  Thoughts?