Re: Unsuccessful cross build of qemu on Debian 12
Hi Josch,
Thanks for the response. I'll see if I can give some sensible answers of
my own. :)
[Re: Unsuccessful cross build of qemu on Debian 12] On 24.05.23 (Thu 23:47) Johannes Schauer Marin Rodrigues wrote:
> Hi,
>
> Quoting Joe MacDonald (2024-05-23 19:00:21)
> > I asked the buildd team about this issue and they pointed me here, I'm hoping
> > someone can help me resolve this problem.
> >
> > I'm having trouble with my sbuild setup only when I'm building qemu and
> > packages with similar dependencies for a foreign architecture.
> >
> > The details are: I have my sbuild / schroot set up according to the cross
> > build instructions at
> > https://wiki.debian.org/CrossCompiling#Building_with_sbuild and I'm able to
> > cross build (amd64 build for arm64 host) stuff like vim, nano, bucketloads.
> > But when I try qemu using the same instructions it fails at the resolver
> > step.
> >
> > I captured success and failure logs with typescript and pastebin'd them.
> >
> > - Successful nano amd64-arm64: https://pastebin.com/vfZWvb65
> >
> > - Successful qemu amd64-amd64 build: https://pastebin.com/kL1N3i8Z
> >
> > - Unsuccessful qemu amd64-arm64 build: https://pastebin.com/hRzrCYHy
> >
> src:qemu lists a Build-Depends on python3-sphinx-rtd-theme. But
> python3-sphinx-rtd-theme is Architecture:all. Build-Depends are resolved using
> the host architecture version of the packages. On the other hand Arch:all
> packages are always implicitly treated as being of the native architecture,
> which corresponds to the build architecture when cross-building. So when you
> build src:qemu for arm64 on amd64, then your host architecture is arm64 and
> your build architecture is amd64. The Arch:all package python3-sphinx-rtd-theme
> will always be implicitly treated as if it was Architecture:amd64. But src:qemu
> needs python3-sphinx-rtd-theme as the host architecture, or arm64. Since
> python3-sphinx-rtd-theme is not Multi-Arch:foreign, it cannot satisfy this
> dependency. There are multiple ways forward as far as this specific dependency
> is concerned:
>
> 1. maybe this sphinx-related dependency is only used to build Arch:all
> documentation packages? If yes, it could be moved to Build-Depends-Indep
> and is thus not interfering with cross building anymore as we only need to
> build Arch:any packages
Based on the incomplete log I provided (due to pastebin size limitations)
I think it's this and I could try that on my side to see what kind of
trouble that gives.
> 2. maybe python3-sphinx-rtd-theme can be made Multi-Arch:foreign? Seems
> unlikely though as looking at its deps this might be the
> multi-arch-interpreter problem
>
> 3. maybe you need the build architecture version of the package, in which case
> you have to mark the build dependency on python3-sphinx-rtd-theme with
> :native
>
> > I'm say sbuild because that's the first thing I tried and probably the
> > solution I'd prefer, but both 'sbuild --host arm64 qemu' and 'dget ... ;
> > pdebuild -- --host-arch arm64' fail in the same way, so I didn't think it was
> > sbuild/schroot specific and more of a general build thing.
>
> Yes, this is not specific to sbuild but a result of how the current metadata is
> as it is. You will experience the same problem without sbuild or pbuilder.
But if I was building for arm64 on an arm64 platform, that should still
work, correct? Even if I was choosing to build it with sbuild, the way I
did with the pure-x86_64 sbuild log? Or am I missing something else in
the explanation here?
> > I'm confident it's not a qemu-specific thing, though, since the exact same
> > resolver issue happens with building other packages. I tried a few by
> > looking at rdepends of python3-venv (the failure qemu shows) and all the ones
> > I tried failed.
>
> But your failing build log above contains nothing related to venv?
Ugh, I'm sorry about that. I also tried this with the Backports version:
http://deb.debian.org/debian/pool/main/q/qemu/qemu_8.2.1+ds-1~bpo12+1.dsc
and that one has a much longer list of unresolvable dependencies but they
seem to spawn from python3-venv and python3-sphinx-rtd-theme, which is why
I mentioned venv above. I forgot that these logs I created were for the
most plain-Jane Debian 12 I could get.
> Also, you can see how qemu currently fails to cross build from source
> due to unsatisfied cross build dependencies here:
>
> http://crossqa.debian.net/src/qemu
>
> Last time it built was quite a while ago. It is likely, that making it
> cross-build will involve much more problems than just
> python3-sphinx-rtd-theme.
Thanks for the link. You're correct, that has been a long time. I'm
curious about the unsatisfied dependency there, python3-setuptools-whl,
but maybe that's just something else I'd bump into after addressing the
sphinx thing.
> What is your motivation? What makes you want to cross-build qemu?
I need to build qemu binaries for arm64 hardware but I don't have arm64
hardware to do the building. Being able to do the build-native
architecture is definitely desirable but it's, unfortunately, not an
option for me.
One other approach I tried that I didn't mention previously, is using
sbuild-qemu. I followed the instructions here:
https://anarc.at/blog/2022-04-27-sbuild-qemu/
after I'd seen it discussed in the mailing list archives here. That's
definitely my least desirable approach since now I'm running an aarch64
qemu to do native compiling, but if it's all I have I'll go with it.
Unfortunately that also didn't work for me, it failed due to missing gcc
implementations.
--------------------------------------------------------------------------
The following packages have unmet dependencies:
sbuild-build-depends-main-dummy : Depends: gcc-alpha-linux-gnu but it is not installable
Depends: gcc-powerpc64-linux-gnu but it is not installable
Depends: gcc-sparc64-linux-gnu but it is not installable
Depends: gcc-hppa-linux-gnu but it is not installable
E: Unable to correct problems, you have held broken packages.
--------------------------------------------------------------------------
Since I don't actually care about any of those architectures, I suppose I
could always just disable them in the qemu configuration. Is that maybe
my best course of action now, do you think?
--
-Joe MacDonald.
:wq
Reply to: