[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: