Re: Cross compiling with interpreter extension library
Hi Keith,
On Wed, Sep 03, 2025 at 11:57:16AM -0700, Keith Packard wrote:
> I'll keep things separate for now, mostly in case I break something, but
> also because having another arch slows down updates.
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.
> 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.
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. So maybe, that package split is
not actually necessary (assuming that the headers are truly
architecture-independent).
> 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.
Yes. That workaround has a name. It's called the "multiarch interpreter
workaround". We do that for many packages. In Brest, I was sitting down
with Tollef and Guillem and we're looking into changing the semantics
of Arch:all to actually allow passing the architecture constraint, but
please don't hold your breath.
> 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.
Why would you not use the native nickle?
> What do python modules which contain binary code do?
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).
Python installs a build architecture interpreter and a host architecture
development package. It has a sysconfigdata.py module containing
architecture-dependent parameters. During a cross build, we extend the
module search path to point prefer a sysconfigdata.py relevant for the
host architecture. Then, we just build the Python extension using those
parameters (e.g. a host architecture compiler is referenced there, but
also host architecture library search paths).
> 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.
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.
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.
Note that you no longer build any Arch:all packages. Therefore,
Build-Depends-Indep no longer applies.
Your annotation of libcairo2-dev with :native looks suspicious to me.
libcairo-5c0 links libcairo2. Therefore, the package must Build-Depends:
libcairo2-dev without :native. Otherwise, it won't build. It may be that
you need both libcairo2-dev and libcairo2-dev:native. Missing
libcairo2-dev though would be an RC bug from my point of view.
> 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'.
Would you mind posting a failing build log when you drop :native from
libcairo2-dev?
> 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.
Helmut
Reply to: