Re: Cross compiling with interpreter extension library
Hi Keith,
On Fri, Sep 05, 2025 at 08:48:26AM -0700, Keith Packard wrote:
> That seems reasonable. How can I test to make sure I'm not relying on
> qemu-binfmt? All of the necessary support gets installed in the
> cowbuilder tree by default afaict, so accidentally using the wrong
> dependency won't cause a build failure.
Difficult. For a long time, binfmt used to be a system-wide thingy.
People asked for a binfmt misc namespace and rather than getting it,
what we got now is the ability to mount a binfmt_misc filesystem in a
mount namespace having an effect on binfmt_misc. So practically
speaking, you'd need a build environment that uses mount namespaces and
mounts this. I don't think we have any just yet. My last recollection of
pbuilder was that it doesn't even use a mount namespace yet.
You may build on a machine where qemu-binfmt is not installed.
You may check https://crossqa.debian.net/src/<yourpackage>
Hope one of these is good enough
> That would install the :native version when building without tests and
> the host arch version when testing is enabled? That would work, and
> allow executing nickle during the build, but that isn't actually
> required for building cairo-5c.
Yes. I'm not sure what is required then. In the nocheck case, you only
really need the headers?
> Given that we're not running the binary, is there any benefit to
> allowing the native version to be installed instead of the host arch
> version?
I guess the advantages are minor in this case. For bootstrapping it
often is an advantage to use build arch dependencies, but I don't think
that's relevant here. Given your arguments, Build-Depends: nickle sounds
just fine.
> > The default-jdk:native part is a bit odd. Would it make sense to split
> > the rather large altos binary package into some smaller parts and
> > possibly an Arch:all package?
>
> That's the only way I could get the native javac installed -- otherwise
> you get the host arch version. Maybe that should be marked 'Multi-Arch: foreign'?
It's odd, because the development kit usually is required for the host
while the javac (the java runtime environment) is required for the
build. What would not be odd is default-jre:native. That of course
misses the development kit part, but I'm not sure you need it, because
I'd expect the build to fail if it needs a jdk and gets a build one
instead of a host one. Can we look deeper if default-jre:native proves
to be insufficient?
> We fixed that at debconf by splitting it into two packages. Version
> 2.3.19-2 has already migrated to testing. Altos just needs to switch to
> depending on asciidoctor-pdf (which is upstream but unreleased).
Oh. It's way too many packages that I look at. I totally failed to
remember this one. It occasionally happens to me that I write an almost
identical patch twice (e.g. when I failed to correctly tag a bug
report).
Helmut
Reply to: