> In principle, there is no need to add the other architecture and thereby
> slow down upadtes. The builder (sbuild/pbuilder) should be able to add
> the architecture as needed.
Fancy! But you'd then be lacking the cross tools and cross packages
lists?
> In Python, C extensions actually link libpythonVER, so that shared
> library exists and for cross compiling Python extensions you need both a
> build architecture interpreter and a host architecture libpythonVER.
> This feels different from nickle as there doesn't seem to be a library
> to link to and instead the extensions are supposed to use symbols
> exported from the interpreter binary.
Ah, I kinda assumed python just exposed symbols from the interpreter
directly (like the X server does).
> So maybe, that package split is
> not actually necessary (assuming that the headers are truly
> architecture-independent).
They are just the upstream header files.
> Yes. That workaround has a name. It's called the "multiarch interpreter
> workaround".
Sounds like I've got my solution then. Good to know it's the best
available method.
> Why would you not use the native nickle?
"because I can". I just wanted to demonstrate that it *could* work
without changing the altos dependencies at all. Once I did that, I
quickly added :native to that as well as default-jdk. Using the arm64
javac under qemu was only slightly less painful than waiting for the
arm64 version of nickle.
> 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.
> The M-A:same does not actually help on cairo-5c, because it depends on
> nickle and that isn't M-A:same. You may drop it.
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?
> 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
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.
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.
> Note that you no longer build any Arch:all packages. Therefore,
> Build-Depends-Indep no longer applies.
Makes sense.
> Would you mind posting a failing build log when you drop :native from
> libcairo2-dev?
And, of course, now it works fine. I cannot reproduce this
failure. Presumably some other change has resolved the issue.
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>
> > Other than that, I think I understand the changes I've had to make. In
> > particular, the need to move cairo-5c from 'Architecture: all' to
> > 'Architecture: any'.
>
> 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 you make it so architecture could be passed through 'Architecture:
all' dependencies, then I would be happy to switch back. Until then,
I'll leave it as 'any'.
Here's the complete list of changes I've needed to get 'altos' cross
building:
1. cairo-5c changes as above
2. asciidoctor: https://salsa.debian.org/ruby-team/asciidoctor/-/merge_requests/4
3. freetts: https://salsa.debian.org/debian/freetts/-/merge_requests/1
4. libjfreechart-java: https://salsa.debian.org/java-team/libjfreechart-java/-/merge_requests/1
5. ttf-bitstream-vera: https://salsa.debian.org/debian/ttf-bitstream-vera/-/commit/aaa9015de93fbed2668a983c7046bc3be990302d
6. picolibc: https://salsa.debian.org/electronics-team/toolchains/picolibc/-/commit/d4ecc48186ce7980ce431dbf763eac8e1344f532
7. altos: https://git.gag.com/?p=fw/altos;a=commitdiff;h=838f3eb97a81d27fbc615aaa862a78eb2eb23f26;hp=4104f9bd9653c5932e9aeac2b2523c4fcbcebc2e
The asciidoctor and libjfreechart-java changes are pending; all of the
others are upstream.
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.
Thanks again for all of your help here; this was what I needed to start
to understand how the multi-arch system enables cross building.
--
-keith
Attachment:
signature.asc
Description: PGP signature