Re: How do you represent a host gcc and a cross gcc in lcitool?

["Alex Bennée" <alex.bennee@linaro.org>]

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?

> 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?

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro