Quoting Vasyl Gello (2021-10-28 22:41:17) > >you'll probably get results quicker if you do a native build in a qemu virtual > >machine emulating your host architecture. > > I did that and it took 9h just to hang on tests under qemu :( Don't run tests by building with DEB_BUILD_OPTIONS=nocheck Making a large package like kodi cross-ready can easily take more time than 9 hours. During these 9 hours you can at least do other stuff. > > >Because that's the rule. In Debian, all build dependencies default to being > >resolved as the host architecture package. If it was the other way round and > >the default was the build architecture, then you would now ask the opposite > >question and ask why all build-deps come from the build architecture. It's just > >the default and in reality you need both build and host architecture packages > >to do the build. Multi-Arch allows you to mark the packages that deviate from > >the default as such > > >If the package is Multi-Arch:foreign, then that is already done. If the package > >is not M-A:foreign, then the dependency resolver has no way to know whether you > >need the build architecture or host architecture of a package. We mark packages > >with the right metadata to install build dependencies of the correct > >architecture. But without that metadata, the resolver cannot know what the > >build actually needs > > This is what I wanted to understand, thanks! I think we must write a clear FAQ for > beginners citing this. I am learning this a hard way! The current docs are: https://wiki.ubuntu.com/MultiarchSpec https://wiki.ubuntu.com/MultiarchCross Especially the table in the second link will be of interest to you as it shows which architecture is installed with which metadata combination. > > But it's likely that you should instead take a step back and ask yourself > >whether you really need that package installed in the foreign architecture. > >Does the build really need the package in host architecture to succeed? > > This is what I really want to declare in my packages. i.e separate tools which > must be host-arch from tools that must be build-arch (like zip). Yes, some tools do not expose their architecture and can always be installed in their native architecture (the build architecture). Such tools can then be marked as Multi-Arch:foreign and zip is marked as such. So zip should always be installed as the native architecture. Do you observe something different? > Also setting libcommons-lang-java:native and groocy:native fixes the resolver > issue. What I am going to do next is to try marking "helper" packages as > arch:native and rework the Kodi upstream MR to build the necessary helper > tools for host and build architecture if cross-compiling Kodi. This way I > hope to eliminate the need to use qemu on host. Why compile twice? Why do you need helper tools as the host architecture? You cannot execute that. So you need to build helper tools in the build architecture only. Or are those helper tools also shipped by some binary package? In that case, yes you need to build them twice. Thanks! cheers, josch
Attachment:
signature.asc
Description: signature