Re: Cross compiling with interpreter extension library
Hi Keith,
On Thu, Sep 04, 2025 at 09:54:53AM -0700, Keith Packard wrote:
> Fancy! But you'd then be lacking the cross tools and cross packages
> lists?
No. Those tools do install them. I don't have separate build
environments for cross building. I use my native build environment and
sbuild does what's needed by itself (adding the architecture, installing
the required dependencies).
You wouldn't be the first one to call this too simple. That's a feedback
I get rather often.
> > With the exception of gobject-introspection, we generally assume that
> > qemu-user is unavailable during cross builds and when it is there, the
> > binfmt integration is disabled (so you need to actively wrap host
> > executables in qemu).
>
> Hrm. Is this a policy that I should be respecting? Or just a
> conservative goal to avoid leaning too hard on this crutch? I'm
> completely fine using qemu-user as needed during builds until the
> packages are fixed to refer to the :native version of each binary tool
> they run at build time.
I don't think we have policy about this, but if your package requires
qemu-binfmt, I consider it failing to cross build and may send you a
patch. At least in the cross bootstrap (not applicable to your
packages), we really want to avoid qemu because it tends to be buggy or
unavailable for new architectures. So yes, please do avoid any use of
qemu during cross builds if you can and if you cannot, do use explicit
qemu invocations (not binfmt).
> I think that makes sense -- cairo-5c relies on nickle, and that installs
> a binary in /usr/bin so you cannot install multiple architectures of
> cairo-5c at the same time because you cannot install multiple
> architectures of nickle at the same time?
Confirmed.
> > If nickle is only used for testing, it should remain in Build-Depends,
> > but gain <!nocheck>. Please do verify that your package still builds
> > when enabling the nocheck build profile and option.
>
> No, the nickle package contains the header files needed to build
> libcairo-5c0. That means we need a bare nickle dependency so that we get
> the package matching the host arch. ttf-bitstream-vera is only needed
I'm not sure whether we've been talking about cairo-5c or altos here.
For cairo-5c, I agree that nickle is a non-optional dependency.
> for tests, so that gets a <!nocheck> annotation. And, with the host arch
> version of nickle installed, I can also enable testing while cross
> building with --no-auto-cross.
Hmm. That sounds a bit like we'd the following if you agree.
Build-Depends: nickle:any, nickle <!nocheck>
> How could we let the build systems know that testing was possible even
> in a cross building environment? For now, my script for running gbp adds
> --no-auto-cross.
Testing almost universally requires running host code. The general
assumption is that you cannot run any host code during a cross build.
Therefore, both sbuild and pbuilder activate the nocheck build profile
when you ask for a cross build. Still, whether to run tests remains a
decision of the builder. Your passing of --no-auto-cross and that way
inhibiting the nocheck profile is the intended way to do this.
Plausibly, we might want to cross build packages for i386 while still be
able to test them (without qemu) to work around address space limits of
compilers. So our current practice merely is that the disabling of tests
during cross builds is a default that you may opt out of.
> Here's the current cairo-5c Build-Depends contents:
>
> Build-Depends: debhelper-compat (= 12), debhelper (>= 12), libcairo2-dev, librsvg2-dev,
> nickle (>= 2.73), libx11-dev (>= 2:1.4.99.901), libfreetype6-dev,
> ttf-bitstream-vera <!nocheck>
Sounds reasonable except that I'd prefer a :any or :native on nickle
here. It probably works both ways, because we're not actually running
/usr/bin/nickle unless testing and what is really required for a nocheck
build (cross or native) is the headers.
> > I don't think we actually need to do that if we only ever want to use
> > the build architecture nickle during build. Then, we can leave cairo-5c
> > as Arch:all and simply have B-D: nickle:native, cairo-5c:native.
>
> Yes, if the only goal were to get my packages building, then that would
> work. But, I think it puts the archive in an inconsistent state --
> you would be able to install cairo-5c and nickle:arm64 at the same time.
> You'd get libcairo-5c0:amd64 which would not work with nickle:arm64.
If cairo-5c is Arch:all and amd64 is your native architecture, you
cannot install cairo-5c and nickle:arm64 at the same time. Arch:all
packages are implicitly treated native, so cairo-5c's depenency on
nickle has an implicit amd64 constraint (as it correctly is not
annotated :any).
On the flip side, Arch:all means that cairo-5c cannot satisfy foreign
architecture dependencies while the Arch:any variant can.
> Here's the complete list of changes I've needed to get 'altos' cross
> building:
>
> 1. cairo-5c changes as above
Works on crossqa.debian.net.
> 2. asciidoctor: https://salsa.debian.org/ruby-team/asciidoctor/-/merge_requests/4
Sounds reasonable.
> 3. freetts: https://salsa.debian.org/debian/freetts/-/merge_requests/1
Sounds reasonable.
> 4. libjfreechart-java: https://salsa.debian.org/java-team/libjfreechart-java/-/merge_requests/1
Sounds reasonable.
> 5. ttf-bitstream-vera: https://salsa.debian.org/debian/ttf-bitstream-vera/-/commit/aaa9015de93fbed2668a983c7046bc3be990302d
That was reported as a bug, yes.
> 6. picolibc: https://salsa.debian.org/electronics-team/toolchains/picolibc/-/commit/d4ecc48186ce7980ce431dbf763eac8e1344f532
We agreed on this earlier.
> 7. altos: https://git.gag.com/?p=fw/altos;a=commitdiff;h=838f3eb97a81d27fbc615aaa862a78eb2eb23f26;hp=4104f9bd9653c5932e9aeac2b2523c4fcbcebc2e
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?
http://crossqa.debian.net/src/altos indicates that ruby-asciidoctor-pdf
still is a problem. This is a bit difficult. ruby-asciidoctor-pdf is
both a command line program (which probably is M-A:foreign) and a Ruby
library (which probably is not M-A:foreign). Therefore, adding
Multi-Arch: foreign would likely be wrong. The typical way forward here
is to split ruby-asciidoctor-pdf into asciidoctor-pdf and move the CLI
to the new binary package. Then we may mark the new one Multi-Arch:
foreign.
> The changes to altos were not actually required -- they just switch to
> using :native tools instead of host arch tools so that a cross build
> runs faster.
They are required, because you must not assume qemu-binfmt and depending
on qemu-binfmt will not reliably get your binfmt support.
Helmut
Reply to: