[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#37593: [core-updates] Linux-Libre fails to build on aarch64-linux
From: |
Marius Bakke |
Subject: |
bug#37593: [core-updates] Linux-Libre fails to build on aarch64-linux |
Date: |
Sun, 06 Oct 2019 18:13:12 +0200 |
User-agent: |
Notmuch/0.29.1 (https://notmuchmail.org) Emacs/26.2 (x86_64-pc-linux-gnu) |
Gábor Boskovits <address@hidden> writes:
> Hello Marius,
>
> Marius Bakke <address@hidden> ezt írta (időpont: 2019. okt. 5., Szo,
> 14:40):
>
>> Pierre Langlois <address@hidden> 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!
signature.asc
Description: PGP signature