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

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

[Alex Bennée]

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.

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

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

[Daniel P. Berrangé]

On Wed, May 31, 2023 at 12:23:34PM +0100, Alex Bennée wrote:
> 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.
> 
> 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?

The last case we had this was with glib2 and in that case we
modified mappings.yml so that it has both 'glib2' and 'glib2-native'

I guess we want the same for gcc in this case.


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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

[Alistair Francis]

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.

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
>

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

[Alex Bennée]

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

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

[Alistair Francis]

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

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

[Alex Bennée]

Alistair Francis <alistair23@gmail.com> writes:

> 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

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

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

[Erik Skultety]

[...]
> > >> >> 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?

Not sure from which angle to look at ^this question, so I just add a NB and if
I missed the point just ignore it - we currently don't support Arch as a target
in lcitool, but if this is kind of a dealbreaker for cross-arch QEMU CI,I don't
see a reason why we shouldn't add it. There'd be quite a few steps involved to
introduce it properly, especially wrt/ VM installation, hence we'd need an
issue to track all subgoals, but FWIW it's not needed to address all of the
problems at once if all that is sufficient for you is a working Dockerfile.

Regards,
Erik