Alistair Francis <alistai...@gmail.com> writes:
> On Fri, Jun 23, 2023 at 8:29 PM Alex Bennée <alex.ben...@linaro.org> wrote: >> >> >> Alistair Francis <alistai...@gmail.com> writes: >> >> > 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. >> >> 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 No. There is a riscv64 compiler and libc in bullseye onwards which we use for building tests. However to do a full cross compile you need a multi-arch setup. As riscv64 is still in ports the only way to achieve this is to use sid. -- Alex Bennée Virtualisation Tech Lead @ Linaro
