Gábor Boskovits <boskovits@gmail.com> writes:

> Hello Marius,
>
> Marius Bakke <mbakke@fastmail.com> ezt írta (időpont: 2019. okt. 5., Szo,
> 14:40):
>
>> Pierre Langlois <pierre.langlois@gmx.com> 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:
>>
>>
>> It's not very pretty though.  Thoughts?
>>
>
> I believe that we encountered similar CPATH related problems earlier, which
> were fixed by pathes like this, so it looks good to me. Maybe it would
> worth investigating the pattern though, and create some generic mechanism
> to deal with it. Wdyt?

I don't think we've had to remove libc from CPATH before.  We could do
that in gnu-build-system if it becomes a pattern.

A more general solution to the CPATH vs C_INCLUDE_PATH problem could be
to present GCC a union of all the inputs as C_INCLUDE_PATH, because I
suspect the main problem is having multiple entries in arbitrary order.
Not sure if that would help this particular issue though.

In any case I pushed the fix as
c5ceec4150f6a6cdc1b64781afa2d05547cf8542.  Thanks for the feedback!