Re: cross-building with salsa-ci
On Mon, Jun 21, 2021 at 05:25:55PM +0200, IOhannes m zmölnig (Debian GNU|Linux) wrote:
> so today i've just started to hack a bit, adding an ad-hoc job for
> cross-compilation and i got a result. [1716689] hooray!
>
> the job is based on the normal salsa-ci "build" job, which calls
> 'dpkg-buildpackage' directly.
>
> the script itself is a total mess so far (heck, that was just a
> proof-of-concept!), and can be found at:
> [https://salsa.debian.org/umlaeute/pd-mrpeach/-/blob/master/debian/salsa-ci.yml]
>
> minor things i noticed:
> - i used ${CROSSBUILD_ARCH} as the variable that holds the target
> architecture. should i use DEB_HOST_ARCH instead? (of course i'm always
> confused by host/build/target); but more importantly, is setting
> DEB_HOST_ARCH as a global environment variable (for the crossbuild job) a
> good idea in general, or do i get things backwards here?
Please do not use CROSSBUILD_ARCH. For a precise definition of what
build/host/target mean, please refer to man dpkg-architecture. Please do
not just set DEB_HOST_ARCH, because the DEB_* variables should be set in
sync. When setting DEB_HOST_ARCH, you also have to set a couple of other
including DEB_HOST_GNU_TYPE.
I recommend changing the central salsa-ci.yml and renaming the "ARCH"
variable to "BUILD_ARCH". "ARCH" can be kept as a compatibility thingy,
but should be faded out eventually as it is ambiguous. The semantics
should be: When "BUILD_ARCH" is defined, its value is used. When unset,
the value of "ARCH" is used. When unset, it defaults to "amd64" (like it
does already).
Once renamed, you introduce a new variable "HOST_ARCH". It roughly
becomes what you used "CROSSBUILD_ARCH" for. "HOST_ARCH" should default
to "BUILD_ARCH".
> - in order for dpkg-shlibdeps to work correctly, i had to manually install
> `libc:${CROSSBUILD_ARCH}` (see [1716620]).
> do you think this is an issue with build-dependencies of my package (afaict,
> no package explicitly b-depends on libc), a problem with "no-recommends"
> when installing crossbuild-essential, an issue with `equivs` (that is used
> to install the build-dependencies of the source package in the standard
> salsa-ci jobs) or something else?
This is #815172. We're working on a fix, but it'll take a little longer.
For the time being, please additionally install libc-dev:${HOST_ARCH}
and libstdc++-dev:${HOST_ARCH}.
> i'm currently in the brainstorming phase, so any input is welcome.
I assume that a native build and cross build will originate from the
same script. A few remarks:
* You can always run "dpkg --add-architecture ${HOST_ARCH}". For native
builds, this automatically becomes a no-op.
* Whenever you need a cross vs native difference, test "${BUILD_ARCH}"
!= "${HOST_ARCH}".
* You you include nocheck in DEB_BUILD_PROFILES. This is the right
thing to do for cross builds. When you do, you must also include
nocheck in DEB_BUILD_OPTIONS.
* You likely want to key the .ccache path on both BUILD_ARCH and
HOST_ARCH.
* If you export CONFIG_SITE like that, you should install the package
cross-config. Whether doing so is good, is an open question. sbuild
does, pbuilder does not. The cross-config cache files contain a lot
of stuff that is unnecessary, some stuff that is wrong, and a good
chunk of correct assignments. It is practically unmaintained. Unless
you use autotools, you do not care.
Hope this helps.
For moving forward, I strongly suggest going in two steps:
* Rename ARCH to BUILD_ARCH.
* Add cross build support (HOST_ARCH) to the existing .build_script.
The renaming will be a little painful and require some effort, but it'll
help in the long run.
Helmut
Reply to: