On Fri, 7 Jun 2019 at 21:33, Helmut Grohne <hel...@subdivi.de> wrote:
> Package: dh-golang
> Version: 1.39
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: cross-satisfiability ftcbfs
>
> I was recently asked how to cross build Debian packages with go sources
> and figured that presently it wouldn't work at all. Effectively, all go
> packages are cross bd-uninstallable due to the way Multi-Arch works.
>
> Packages typically Build-Depend on dh-golang. Such a dependency is
> interpreted as a host architecture dependency. Now dh-golang is
> Architecture: all, which is treated as a "native" architecture (for
> dependency resolution). "native" is formally defined as the architecture
> of the installed "dpkg" package and usually matches the build
> architecture. When build and host architecture differ (aka cross
> compiling), dh-golang:$host does not have any installation candidate.
> The usual fix is to mark it Multi-Arch: foreign. But doing so would be
> wrong in its present form.
>
> For getting started with cross building go packages, I looked for very
> simple go packages. Note that go libraries actually package source code
> and thus typically are Architecture: all. Such packages are irrelevant
> for cross building. What I looked for was a go package containing an
> executable. About the simplest package I could find was "canid". Now for
> actually trying a cross build, I simply installed the relevant packages
> for the build architecture and made dpkg-checkbuilddeps shut up using
> -d. Dependency satisfiability still needs to be taken care of somehow,
> but let's defer that for now.
>
> MartÃn Ferrari kindly pointed me to the GOOS and GOARCH environment
> variables. These need to be set. For Arm architectures one also needs to
> set GOARM. The values are ... not very obvious. The attached patch takes
> care of setting them up. As far as I understand it, go might also call a
> C compiler, so I also provide a CC variable. Once all these variables
> are set, I get a successful build.
>
> Unfortunately the contents of the build are broken. Instead of
> /usr/bin/canid, I now have /usr/bin/${GOOS}_${GOARCH}/canid. According
> to github user ishanjain28 this is an expected convention. Therefore my
> patch corrects the binary installation directory in the install step.
>
> Another aspect is that canid is now statically linked. This also is
> expected behaviour as https://golang.org/cmd/cgo/ explains:
>
> | The cgo tool is enabled by default for native builds on systems where it
> | is expected to work. It is disabled by default when cross-compiling. You
> | can control this by setting the CGO_ENABLED environment variable when
> | running the go tool:
>
> In the interest of reproducible builds, we need to match the native
> behaviour and set CGO_ENABLED=1.
>
> I also tried building mtail (again running dpkg-buildpackage with -d)
> and it appeared to produce reasonable packages.
>
> Since dh-golang now actually honours the dpkg architecture variables,
> marking it Multi-Arch: foreign is a reasonable thing to do.
>
This all makes sense to me, as far as I understand how multi-arch works
(which isn't terribly far).
> If you upload a dh-golang with these changes, suddenly those go packages
> that don't have any library dependencies will become cross satisfiable
> (due to the Multi-Arch: foreign marking). However their dependency on
> golang-any will use the host architecture go, which cannot be run. We'll
> have to somehow figure out what to do about this. I don't have an answer
> yet.
>
I don't know what to do here either. On the one hand, it's simple (at least
for golang-go): we want to install the build go, because all go compilers
are capable of cross compilation. How is this handled for the C compiler?
> In the mean time, please consider applying the attached patch as an
> incremental step after buster is released.
>
> Helmut
>
