Chromiumos uses cros-go.eclass which handles cross-compilations transparently.
See http://www.chromium.org/chromium-os/developer-guide/go-in-chromium-os

Vendoring of all these extra packages from inside this ebuild is not recommended.
If I'm not mistaken, these dependencies are being pulled directly from github.com.
That's especially discouraged.

For cross-compiling, at the very least, you'll need to get the correct cross-compiler using $(tc-getGO) and use that to build the packages.
This might mean patching the Makefiles to override any hardcoded "go" invocations.

Hi, thanks for the quick response -- I'm brand new to go -- what do you mean by "vendoring"?  I thought it meant hosting our own copy of that code, but it doesn't seem to be the correct definition here.

By vendoring, I mean the lxd package seems to require copies of other third party packages (at specific revisions) to be present before it can be built.

These third party packages do not seem to be included in the lxd archive itself, but seem to be listed in ${EGO_VENDOR} and are fetched by the ebuild directly from github.com and placed in ${S}.

In chromiumos, we import such third party packages using their own ebuilds (and from our own mirror repositories). For example, lxd needs "github.com/golang/protobuf". We already have an ebuild for that in "chromiumos-overlay/dev-go/protobuf" which installs it in the chroot so that a common version of protobuf library can be used by all packages that need it.

http://www.chromium.org/chromium-os/developer-guide/go-in-chromium-os has more details. chromiumos-overlay/dev-go/... has more example ebuilds.

I'm not sure how easy it is to adapt lxd build and Makefiles to use the pre-installed packages instead of their own vendored copies, but that would be good place to get to. At the very least, we should fetch them from our mirrors on chromium gerrit, or package them inside the "lxd-a.bc.tar.gz" itself so they don't need to be fetched separately at every build.

Regarding cross-compiling, it may be as simple as patching the Makefiles to replace hard-coded "go" invocations with the value of "$(tc-getGO)" from the ebuild.

ok I made the change to pass the output of $(tc-getGO) to the makefile and have it use that, it builds using the correct compilers, but then I ran into another problem which is that "go install" is putting the binaries in a different place when I'm building for arm vs x86

for example on x86 the binaries end up here:
onnyrao@sonnyrao2 /build/tatl/tmp/portage/app-emulation/lxd-2.18-r1/work/lxd-2.18/src/github.com/lxc/lxd $ find /build/tatl/tmp/portage/app-emulation/lxd-2.18-r1/work/lxd-2.18/bin/
/build/tatl/tmp/portage/app-emulation/lxd-2.18-r1/work/lxd-2.18/bin/
/build/tatl/tmp/portage/app-emulation/lxd-2.18-r1/work/lxd-2.18/bin/lxd
/build/tatl/tmp/portage/app-emulation/lxd-2.18-r1/work/lxd-2.18/bin/lxc
/build/tatl/tmp/portage/app-emulation/lxd-2.18-r1/work/lxd-2.18/bin/fuidshift
/build/tatl/tmp/portage/app-emulation/lxd-2.18-r1/work/lxd-2.18/bin/lxd-benchmark
/build/tatl/tmp/portage/app-emulation/lxd-2.18-r1/work/lxd-2.18/bin/deps


however on an arm build, go install decides to add another level of directory:


onnyrao@sonnyrao2 /build/tatl/tmp/portage/app-emulation/lxd-2.18-r1/work/lxd-2.18/src/github.com/lxc/lxd $ find /build/tael/tmp/portage/app-emulation/lxd-2.18-r1/work/lxd-2.18/bin/
/build/tael/tmp/portage/app-emulation/lxd-2.18-r1/work/lxd-2.18/bin/
/build/tael/tmp/portage/app-emulation/lxd-2.18-r1/work/lxd-2.18/bin/linux_arm
/build/tael/tmp/portage/app-emulation/lxd-2.18-r1/work/lxd-2.18/bin/linux_arm/lxd
/build/tael/tmp/portage/app-emulation/lxd-2.18-r1/work/lxd-2.18/bin/linux_arm/lxc
/build/tael/tmp/portage/app-emulation/lxd-2.18-r1/work/lxd-2.18/bin/linux_arm/fuidshift
/build/tael/tmp/portage/app-emulation/lxd-2.18-r1/work/lxd-2.18/bin/linux_arm/lxd-benchmark
/build/tael/tmp/portage/app-emulation/lxd-2.18-r1/work/lxd-2.18/bin/linux_arm/deps


I'm not sure why "go install" does this -- I think it's sensing that host arch and target arch are the same in the x86 case even though I pass in a specific compiler.

I also tried setting GOBIN but "go install" barfs on that:

armv7a-cros-linux-gnueabi-go install -work -x -v   ./...
go install: cannot install cross-compiled binaries when GOBIN is set
go install: cannot install cross-compiled binaries when GOBIN is set
go install: cannot install cross-compiled binaries when GOBIN is set
go install: cannot install cross-compiled binaries when GOBIN is set
go install: cannot install cross-compiled binaries when GOBIN is set


from what I can tell, "go install" isn't really designed to handle cross compiliation -- see 

https://github.com/golang/go/issues/9769
https://github.com/golang/go/issues/11778


There's a comment in 11778 saying:
"In general with your own programs, you should go build cross-compiled binaries, not go install them. You can use -o to specify where you want the binary to end up."


Wowever "go build" doesn't let you target ./... so i'm not sure what the correct way to solve this problem is except put a hack in the ebuild to look in multiple places for the binaries?

If you follow the suggestions on http://www.chromium.org/chromium-os/developer-guide/go-in-chromium-os
and specify your binaries using CROS_GO_BINARIES variable and inherit from cros-go eclass, all this will be taken care of automatically. Seamless cross-compile and installation for Go packages and binaries is just what the eclass is for.

It does mean that you'd need to migrate from the Makefiles to build your program. What does the Makefile in this project do that cannot be done by directly invoking the go tool?

If the project is only meant to use the Makefiles, and the Makefiles invoke "go install", and as you discovered, "go install" is not meant to be used for cross-compiles, I would suggest that you take this issue to upstream lxd project for their recommendations. What is the official way for cross-compiling using their Makefiles?

re #6  the makefile doesn't do that much -- it mostly makes various calls to "go"
so I can translate those into the ebuild relatively easily

I did some searching on their official method and found this:
https://github.com/lxc/lxd/issues/2740

so I guess they're expecting you to ignore the makefile and call go build directly.  I'll try this out.

Great. If the only thing Makefile does is handle CGo, cros-go.eclass does that as well.
Just add the binaries you want to build to CROS_GO_BINARIES variable, and cross-compiles with CGo will be handled automatically (i.e. the right cross-compiler will be called for the C code automatically).

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/dce9b03633b7eb6d80365a3e99a8f4185df6c45d

commit dce9b03633b7eb6d80365a3e99a8f4185df6c45d
Author: Sonny Rao <sonnyrao@chromium.org>
Date: Fri Feb 16 01:42:21 2018

app-emulation/lxd: fix ebuild for cross-compiliation

Support cross-compiliation for lxd using the CrOS go infrastructure
which means not using the Makefiles provided by lxd which aren't meant
to support cross-compiliation --
see https://github.com/lxc/lxd/issues/2740

Also eliminate some of the noise about checking kernel configs which
doesn't make sense since the build isn't happening on the target, and
make sure we rebuild when protoc is upreved.

BUG= chromium:810955 
TEST=emerge-tatl lxd
TEST=emerge-tael lxd

Change-Id: I7a051b32cae4304c4273e82b0098563b6b1ee751
Reviewed-on: https://chromium-review.googlesource.com/914510
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>

[modify] https://crrev.com/dce9b03633b7eb6d80365a3e99a8f4185df6c45d/app-emulation/lxd/lxd-2.18.ebuild
[delete] https://crrev.com/dd1e3b0b134cc6854e6d552ce0a21efe3f626dcf/app-emulation/lxd/files/lxd-2.18-detect-sqlite.patch
[delete] https://crrev.com/dd1e3b0b134cc6854e6d552ce0a21efe3f626dcf/app-emulation/lxd/files/lxd-2.18-dont-go-get.patch
[rename] https://crrev.com/dce9b03633b7eb6d80365a3e99a8f4185df6c45d/app-emulation/lxd/lxd-2.18-r2.ebuild
[delete] https://crrev.com/dd1e3b0b134cc6854e6d552ce0a21efe3f626dcf/app-emulation/lxd/files/lxd-2.18-dont-hardcode-gcc.patch