Re: Bug#930176: dh-golang: support cross building go packages
On Fri, Jun 28, 2019 at 09:12:33PM +0100, Michael Hudson-Doyle wrote:
> On Fri, 7 Jun 2019 at 21:33, Helmut Grohne <helmut@subdivi.de> wrote:
> > 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?
Difficult. The first issue is that we actually have at least two major C
compilers (gcc and clang). The majority of the archive uses gcc. gcc has
target-specific packages. We append a target to the binary package name
and get something like gcc-8-aarch64-linux-gnu. Thus far, this works for
many combinations but native building. There is work in progress to also
provide these names for native builds. The build-essential package
ensures that gcc is installed. For the purpose of cross building this
means that both a build gcc and a host gcc are present. No packages have
to issue any dependency here. Some packages want a versioned dependency
on gcc and we plan to support this using a special "gcc-for-host"
package. In any case, this is much different to go, because you select
the target by using a different compiler binary.
Then there is clang. Few packages use clang and we haven't done much
about it yet. It's in the same position as go as it also allows
supplying the target as a command line parameter. It's not presently
marked M-A:foreign and packages that depend on clang generally don't
cross build in Debian at present.
So go might just be the pioneer in this field. I don't have a good
intuition yet, how this should be solved. I therefore prefer
experimentation. Doing so becomes easier when the obvious bits (i.e.
this patch) are merged. For this reason, I suggest to sit back and wait
for buster to release, then upload the patch and observe its effects.
The experimentation approach involves cross building a package that is
slightly out of reach and using hacks to make it barely work. Then
filter the "obvious" and upstreamable bits and submit them as patches
(e.g. this one). Eventually, everything becomes obvious (that's my
theory) and cross building will work.
I fear that the bigger problem than the go compiler will be go
libraries. These are currently arch:all and susceptible to the
Multi-Arch interpreter problem[1]. There are two estimators[2]. Mine
only finds 13 go packages, because it does not consider Build-Depends,
but josch's has numbers around 300. Again, we can learn from another
ecosystem: rust. Rust is effectively using the suggested workaround by
having converted all of their libraries from Arch:all to Arch:any
M-A:same for the sake of transporting dependencies. My gut feeling is
that we'll have to do the same for go if cross building is to be a
thing. It would be great if you could familiarize yourself with this
part, because my expectation is that it will require a lot of churn.
Helmut
[1] https://wiki.debian.org/HelmutGrohne/MultiarchSpecChanges
[2] https://people.debian.org/~helmutg/multiarch_interpreter.html
https://bootstrap.debian.net/ma_interpreter.html
Reply to: