From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?G=C3=A1bor?= Boskovits Subject: bug#37593: [core-updates] Linux-Libre fails to build on aarch64-linux Date: Sat, 5 Oct 2019 18:01:14 +0200 Message-ID: References: <877e5m98nv.fsf@devup.no> <87a7ain6j7.fsf@gmx.com> <87tv8n74f4.fsf@devup.no> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000051363a05942beeb1" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:47788) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iGmVV-0000Or-JK for bug-guix@gnu.org; Sat, 05 Oct 2019 12:02:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iGmVP-0004BU-Go for bug-guix@gnu.org; Sat, 05 Oct 2019 12:02:05 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:36234) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iGmVP-0004BQ-Cn for bug-guix@gnu.org; Sat, 05 Oct 2019 12:02:03 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iGmVO-0001eW-Kw for bug-guix@gnu.org; Sat, 05 Oct 2019 12:02:03 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87tv8n74f4.fsf@devup.no> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Marius Bakke Cc: 37593@debbugs.gnu.org --00000000000051363a05942beeb1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Marius, Marius Bakke ezt =C3=ADrta (id=C5=91pont: 2019. okt. = 5., Szo, 14:40): > Pierre Langlois 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:3= 4: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/stdin= t-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:3= 7: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/stdin= t-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? Best regards, g_bor --=20 OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21 --00000000000051363a05942beeb1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Marius,

Marius Bakke <mbakke@fastmail.com> ezt =C3=AD= rta (id=C5=91pont: 2019. okt. 5., Szo, 14:40):
Pierre Langlois <pierre.langlois@gmx.com> writ= es:

> Hi Marius,
>
> Marius Bakke writes:
>
>> Berlin fails to build "linux-libre" for AArch64 on the &= #39;core-updates'
>> branch.=C2=A0 Here is a recent attempt:
>>
>> https://ci.guix.gnu.org/build/1758844/details<= /a>
>>
>> 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]=C2=A0 arch/arm64/lib/xor-neon.o
>> In file included from /gnu/store/nr1aw4i32h7rmxwmq7d2da0mwcwg551j-= glibc-2.29/include/stdint.h:34:0,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 from= /gnu/store/yckkivhynk4hjcr0iry9vbcyc0lqqnxj-gcc-7.4.0-lib/lib/gcc/aarch64-= unknown-linux-gnu/7.4.0/include/arm_neon.h:33,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 from= ./arch/arm64/include/asm/neon-intrinsics.h:33,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 from= arch/arm64/lib/xor-neon.c:11:
>> /gnu/store/nr1aw4i32h7rmxwmq7d2da0mwcwg551j-glibc-2.29/include/bit= s/stdint-intn.h:27:19: error: conflicting types for 'int64_t'
>>=C2=A0 typedef __int64_t int64_t;
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 ^~~~~~~
>> In file included from ./include/linux/list.h:5:0,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 from= ./include/linux/module.h:9,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 from= arch/arm64/lib/xor-neon.c:10:
>> ./include/linux/types.h:114:15: note: previous declaration of '= ;int64_t' was here
>>=C2=A0 typedef s64=C2=A0 =C2=A0int64_t;
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^~~~~~~
>> In file included from /gnu/store/nr1aw4i32h7rmxwmq7d2da0mwcwg551j-= glibc-2.29/include/stdint.h:37:0,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 from= /gnu/store/yckkivhynk4hjcr0iry9vbcyc0lqqnxj-gcc-7.4.0-lib/lib/gcc/aarch64-= unknown-linux-gnu/7.4.0/include/arm_neon.h:33,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 from= ./arch/arm64/include/asm/neon-intrinsics.h:33,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 from= arch/arm64/lib/xor-neon.c:11:
>> /gnu/store/nr1aw4i32h7rmxwmq7d2da0mwcwg551j-glibc-2.29/include/bit= s/stdint-uintn.h:27:20: error: conflicting types for 'uint64_t'
>>=C2=A0 typedef __uint64_t uint64_t;
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0^~~~~~~~
>> In file included from ./include/linux/list.h:5:0,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 from= ./include/linux/module.h:9,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 from= arch/arm64/lib/xor-neon.c:10:
>> ./include/linux/types.h:112:15: note: previous declaration of '= ;uint64_t' was here
>>=C2=A0 typedef u64=C2=A0 =C2=A0uint64_t;
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^~~~~~~~ >> 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.=C2=A0 Ideas?
>
> Ha, that looks familiar, the same issue happened back in July:
> https://lists.gnu.org/archiv= e/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.=C2=A0 Thoughts?

<= /div>
I believe that we encountered similar CPATH related problems earl= ier, 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 mech= anism to deal with it. Wdyt?


<= /div>
Best regards,
g_bor
--
OpenPGP Key Fingerprint: 7988= :3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
--00000000000051363a05942beeb1--