On Fri, Jun 28, 2019 at 09:12:33PM +0100, Michael Hudson-Doyle wrote: > On Fri, 7 Jun 2019 at 21:33, Helmut Grohne <hel...@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
