unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Marius Bakke <mbakke@fastmail.com>
To: "Gábor Boskovits" <boskovits@gmail.com>
Cc: 37593-done@debbugs.gnu.org
Subject: bug#37593: [core-updates] Linux-Libre fails to build on aarch64-linux
Date: Sun, 06 Oct 2019 18:13:12 +0200	[thread overview]
Message-ID: <87a7ad7syv.fsf@devup.no> (raw)
In-Reply-To: <CAE4v=pieHMTacyByAVSF1z6hM4ais-8obs1=xjrZwwnky2u-EA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3933 bytes --]

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!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

      reply	other threads:[~2019-10-06 16:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-02 20:47 bug#37593: [core-updates] Linux-Libre fails to build on aarch64-linux Marius Bakke
2019-10-02 22:09 ` Pierre Langlois
2019-10-05 12:38   ` Marius Bakke
2019-10-05 16:01     ` Gábor Boskovits
2019-10-06 16:13       ` Marius Bakke [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a7ad7syv.fsf@devup.no \
    --to=mbakke@fastmail.com \
    --cc=37593-done@debbugs.gnu.org \
    --cc=boskovits@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).