On Thu, Jun 1, 2023 at 4:58 AM Alex Bennée <alex.ben...@linaro.org> wrote: > > > Brian Cain <bc...@quicinc.com> writes: > > >> -----Original Message----- > >> From: Alex Bennée <alex.ben...@linaro.org> > >> Sent: Wednesday, May 31, 2023 6:24 AM > >> To: Daniel P.Berrangé <berra...@redhat.com> > >> Cc: qemu-devel <qemu-devel@nongnu.org>; Michael Tokarev > >> <m...@tls.msk.ru>; Erik Skultety <eskul...@redhat.com>; Brian Cain > >> <bc...@quicinc.com>; Palmer Dabbelt <pal...@dabbelt.com>; Alistair Francis > >> <alistair.fran...@wdc.com>; Bin Meng <bin.m...@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. Are you still looking for a Docker image? I could try and get something working Alistair > >> > >> Thanks, > >> > >> -- > >> Alex Bennée > >> Virtualisation Tech Lead @ Linaro > > > -- > Alex Bennée > Virtualisation Tech Lead @ Linaro >
