> I am wondering why you are creating a separate base here. In principle,
> pbuilder/cowbuilder should be able to deal with a single base per
> release and install a suitable toolchain. There should be no technical
> need for a separate base.
Thanks. I had started with a pure foreign-arch cowbuilder install (as
that's what's easy to generate), switched to using sbuild and then moved
back to cowbuilder when I figured out how to do cross-builds with that.
I'll keep things separate for now, mostly in case I break something, but
also because having another arch slows down updates.
> There is a possible benefit in having the toolchain pre-installed as it
> can save time downloading and unpacking it repeatedly. However, the base
> as you are constructing it does not install the cross toolchain. If you
> want to do that, you probably also want to add:
>
> --debootstrapopts --include=crossbuild-essential-arm64,libc6-dev:arm64,libstdc++-dev:arm64
Ooo, that's helpful. I'll add that.
> > All of my package building is done using this command:
> > $ GIT_PBUILDER_OPTIONS="--host-arch=arm64 --basepath=/var/cache/pbuilder/base-cross.cow" gbp buildpackage
>
> This is what we figured out in Brest. Did you file a bug with gbp asking
> for a better way to forward the host architecture? If not, could you do
> so? (Please X-Debbugs-Cc this list)
There is already https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721444
for the --basepath option; it looks like I can use --git-dist=cross to
have it pass --basepath base-cross.cow to cowbuilder. I have to agree
with the bug report, Mònica -- this is not exactly intuitive. Or I can
just make base.cow include the arm64 architecture.
I've filed another bug asking for something like a --git-host-arch
parameter: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1113869
> Quite possibly, it may be necessary to split the nickle package into
> several binary packages in order to make it usable for cross
> compilation. My musings may also be entirely wrong. It's a guess.
It sounds like the headers should at least be split off into a -dev
package. Nickle doesn't provide any libraries; extensions needing to add
to the core interpreter do that using a shared library (built against
the headers shipped with the nickle package) which is dlopen'd by the
interpreter itself. I think this is how python works, so I'm cautiously
optimistic that we can make nickle usable here in a similar fashion.
> > • picolibc-arm-none-eabi. The embedded C library used to create
> This one very likely needs to become Multi-Arch: foreign.
Already done -- version 1.8.10-3.
> > The cairo-5c package
>
> This is Arch:all and implicitly Multi-Arch: no. It'll not be able to
> satisfy any cross Build-Depends as is.
My local version has added 'Multi-Arch: foreign', but now that I think
about it that won't work -- it won't pass through the architecture
dependency from nickle so we end up with the native version of
libcairo-5c0. Of course.
> You have wandered into the infamous "Multi-Arch interpreter problem"
> now. If your interest is in actually running nickle programs during
> build and you expect that nickle does not behave differently (produce
> different artifacts) depending on the interpreter architecture, please
> go straight for nickle:native, cairo-5c:native and have things work.
Nickle has tests to ensure it is architecture independent because
undefined behavior is unacceptable in language design. Switching to
:native works great.
> If you want to insist on running the host nickle interpreter, you shall
> notice that cairo-5c is not satisfiable. Arch:all is implicitly treated
> as if it were dpkg's architecture, so it cannot ever pass through the
> arm64 architecture constraint to its own dependencies. You may work
> around this by changing cairo-5c to Architecture: any.
Using 'Architecture: any' and 'Multi-Arch: same' fixes this, at the cost
of creating architecture-specific versions of the cairo-5c package,
which doesn't contain any architecture-specific bits at all.
I'm now successfully building altos using the arm64 version of nickle
and cairo-5c. Which is a whole lot slower than using the native version.
What do python modules which contain binary code do?
> ttf-bitstream-vera is #732119. Until that is fixed, you may work around
> it by keeping :native, but maybe someone should just NMU it instead.
Uh, I maintain that package and have now uploaded a new version with
that bug fixed. Thanks for the reference.
> That bug is actually marked as affecting cairo-5c, so you might have
> seen it already.
In theory, as I maintain both, I should have already seen and fixed
it. I appear to be a bit behind in my debian package tasks...
> Do you actually run nickle during an arch-only build or is it only
> needed for building the indep package or for testing? Consider moving it
> to Build-Depends-Indep or annotating it <!nocheck> as appropriate.
It's only used for testing. Moving these to Build-Depends-Indep works
just fine.
I *think* cairo-5c is ready to upload now; the changes I've made are
available at
https://salsa.debian.org/keithp/cairo-5c/-/commit/ed987517bf56dc42de2329a4257a430aeb231079
Unless you've got additional suggestions, I'll merge that once
ttf-bitstream-vera has updated in unstable.
> I hope that my musings get you quite a bit further. Looking forward to
> your next steps.
You've been tremendously helpful. I've got everything cross building
nicely.
I remain confused about why I need libcairo2-dev:native. Looking at the
cairo package doesn't provide any obvious reasons; it looks like every
other library I'm using with 'Architecture: any' and 'Multi-Arch: same'.
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'.
--
-keith
Attachment:
signature.asc
Description: PGP signature