From: Alistair Francis <alistair23@gmail.com>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: "Brian Cain" <bcain@quicinc.com>,
"Daniel P.Berrangé" <berrange@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>,
"Michael Tokarev" <mjt@tls.msk.ru>,
"Erik Skultety" <eskultet@redhat.com>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Alistair Francis" <alistair.francis@wdc.com>,
"Bin Meng" <bin.meng@windriver.com>,
"Matheus Bernardino (QUIC)" <quic_mathbern@quicinc.com>,
"Marco Liebel (QUIC)" <quic_mliebel@quicinc.com>
Subject: Re: How do you represent a host gcc and a cross gcc in lcitool?
Date: Mon, 3 Jul 2023 13:26:35 +1000 [thread overview]
Message-ID: <CAKmqyKNHvP4MJOPP8i-Lj5Bu3-DNi00SngEe5X+c8_vA0EGLaQ@mail.gmail.com> (raw)
In-Reply-To: <87fs6ifp5e.fsf@linaro.org>
On Fri, Jun 23, 2023 at 8:29 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>
>
> Alistair Francis <alistair23@gmail.com> writes:
>
> > On Thu, Jun 1, 2023 at 4:58 AM Alex Bennée <alex.bennee@linaro.org> wrote:
> >>
> >>
> >> Brian Cain <bcain@quicinc.com> writes:
> >>
> >> >> -----Original Message-----
> >> >> From: Alex Bennée <alex.bennee@linaro.org>
> >> >> Sent: Wednesday, May 31, 2023 6:24 AM
> >> >> To: Daniel P.Berrangé <berrange@redhat.com>
> >> >> Cc: qemu-devel <qemu-devel@nongnu.org>; Michael Tokarev
> >> >> <mjt@tls.msk.ru>; Erik Skultety <eskultet@redhat.com>; Brian Cain
> >> >> <bcain@quicinc.com>; Palmer Dabbelt <palmer@dabbelt.com>; Alistair Francis
> >> >> <alistair.francis@wdc.com>; Bin Meng <bin.meng@windriver.com>
> >> >> Subject: How do you represent a host gcc and a cross gcc in lcitool?
> >> >>
> >> >> WARNING: This email originated from outside of Qualcomm. Please be wary of
> >> >> any links or attachments, and do not enable macros.
> >> >>
> >> >> Hi,
> >> >>
> >> >> While trying to convert the debian-riscv64-cross docker container to an
> >> >> lcitool based one I ran into a problem building QEMU. The configure step
> >> >> fails because despite cross compiling we still need a host compiler to
> >> >> build the hexagon codegen tooling.
> >> >
> >> > I thought we'd fixed this container definition so that we only
> >> > downloaded the hexagon toolchain instead? Do we really need a host
> >> > compiler for that container build?
> >> >
> >> > Or am I misunderstanding and you're referring to features required to
> >> > support idef parser? Does "hexagon codegen" refer to hexagon's TCG
> >> > generation or hexagon code itself (required by tests/tcg)?
> >>
> >> I think so:
> >>
> >> #
> >> # Step 1
> >> # We use a C program to create semantics_generated.pyinc
> >> #
> >> gen_semantics = executable(
> >> 'gen_semantics',
> >> 'gen_semantics.c',
> >> native: true, build_by_default: false)
> >>
> >> semantics_generated = custom_target(
> >> 'semantics_generated.pyinc',
> >> output: 'semantics_generated.pyinc',
> >> command: [gen_semantics, '@OUTPUT@'],
> >> )
> >> hexagon_ss.add(semantics_generated)
> >>
> >>
> >> >
> >> >> After scratching my head for a while I discovered we did have host GCC's
> >> >> in our cross images despite there being no explicit request for them in
> >> >> the docker description. It turned out that the gcovr requirement pulled
> >> >> in lcov which itself had a dependency on gcc. However this is a bug:
> >> >>
> >> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987818
> >> >>
> >> >> which has been fixed in bookworm (and of course sid which is the only
> >> >> way we can get a riscv64 build of QEMU at the moment). Hence my hacky
> >> >> attempts to get gcc via side effect of another package failed.
> >> >>
> >> >> Hence the question in $SUBJECT. I tried to add a mapping to lcitool for
> >> >> a pseudo hostgcc package:
> >> >>
> >> >> + hostgcc:
> >> >> + default: gcc
> >> >> + pkg:
> >> >> + MacOS:
> >> >> + cross-policy-default: skip
> >> >>
> >> >> however this didn't work. Do we need a new mechanism for this or am I
> >> >> missing a way to do this?
> >> >>
> >> >> RiscV guys,
> >> >>
> >> >> It's clear that relying on Debian Sid for the QEMU cross build for RiscV
> >> >> is pretty flakey. Are you guys aware of any other distros that better
> >> >> support cross compiling to a riscv64 target or is Debian still the best
> >> >> bet? Could you be persuaded to build a binary docker image with the
> >> >> cross compilers and libraries required for a decent cross build as an
> >> >> alternative?
> >
> > It's probably not very helpful, but I find Arch based distros to be
> > the best bet for this.
>
> I've never tried arch under docker, isn't it just as much of a moving
> target?
I haven't really tried Arch under Docker. I agree that it is a fast
moving target. I guess it's up for debate if it's too much churn or
not
Would a working Arch image be helpful with lcitool?
>
> > Are you still looking for a Docker image? I could try and get
> > something working
>
> Yes, although I have converted debian-riscv64-cross to lcitool and had
> it working sid has since broken. Are there any pushes to have riscv as a
> first class distro citizen soon or is stuff still in the early ports
> stage?
There are pushes. I thought RISC-V was progressing towards first class
distro support, but it seems to have stalled recently.
I actually thought you could cross compile with Debian bullseye, yet
alone bookworm, has someone tried? Otherwise I can give it a crack
Alistair
>
> --
> Alex Bennée
> Virtualisation Tech Lead @ Linaro
next prev parent reply other threads:[~2023-07-03 3:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-31 11:23 How do you represent a host gcc and a cross gcc in lcitool? Alex Bennée
2023-05-31 11:52 ` Daniel P. Berrangé
[not found] ` <SN6PR02MB4205D202EFB6D6A256ECB93FB8489@SN6PR02MB4205.namprd02.prod.outlook.com>
[not found] ` <87jzwoba78.fsf@linaro.org>
2023-06-23 2:27 ` Alistair Francis
2023-06-23 10:25 ` Alex Bennée
2023-07-03 3:26 ` Alistair Francis [this message]
2023-07-03 7:31 ` Alex Bennée
2023-07-03 8:22 ` Erik Skultety
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKmqyKNHvP4MJOPP8i-Lj5Bu3-DNi00SngEe5X+c8_vA0EGLaQ@mail.gmail.com \
--to=alistair23@gmail.com \
--cc=alex.bennee@linaro.org \
--cc=alistair.francis@wdc.com \
--cc=bcain@quicinc.com \
--cc=berrange@redhat.com \
--cc=bin.meng@windriver.com \
--cc=eskultet@redhat.com \
--cc=mjt@tls.msk.ru \
--cc=palmer@dabbelt.com \
--cc=qemu-devel@nongnu.org \
--cc=quic_mathbern@quicinc.com \
--cc=quic_mliebel@quicinc.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.
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 NNTP newsgroup(s).