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

[Alex Bennée]

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?
>> 
>> Thanks,
>> 
>> --
>> Alex Bennée
>> Virtualisation Tech Lead @ Linaro


-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro