Linux cross-compilation fails on Windows when golang.google.org/grpc is imported

[Xjs]

Although third_party/org_golang_google_grpc/internal/channelz/BUILD.bazel.in actually declares the golang.org/x/sys/unix dependency as a conditional dependency (https://github.com/bazelbuild/rules_go/blob/4f3399d8ff00b1fa20d8619cc13edece1420cbd0/third_party/org_golang_google_grpc/internal/channelz/BUILD.bazel.in#L33), when trying to build a linux_amd64 binary on a Windows host, I get the error message:

(15:08:29) ERROR: C:/tmp/_bazel_jannis.schnitzer/47bkkx3e/external/org_golang_google_grpc/internal/channelz/BUILD.bazel:3:1: Couldn't build file external/org_golang_google_grpc/internal/channelz/linux_amd64_pure_stripped/go_default_library%/google.golang.org/grpc/internal/channelz.a: GoCompile external/org_golang_google_grpc/internal/channelz/linux_amd64_pure_stripped/go_default_library%/google.golang.org/grpc/internal/channelz.a failed (Exit 1)
GoCompile: missing strict dependencies:
        C:\tmp\_bazel_jannis.schnitzer\47bkkx3e\execroot\com_github_Xjs_proto_test\external\org_golang_google_grpc\internal\channelz\types_linux.go: import of "golang.org/x/sys/unix"
Known dependencies are:
        google.golang.org/grpc/connectivity
        google.golang.org/grpc/credentials
        google.golang.org/grpc/grpclog
Check that imports in Go sources match importpath attributes in deps.

(reproducable with https://github.com/Xjs/protoTest/tree/grpc_dependency)

I'm not sure why the conditional select() statement is not honoured in this case, but I get the feeling that it could lead to problems in other places as well.

[jayconrod]

Does this work with --platforms=@io_bazel_rules_go//go/toolchain:linux_amd64? That should be the primary method for cross compilation. goos and goarch cannot influence select expressions, and we need select expressions to correctly compile a lot of targets, especially those that depend on golang.org/x/sys/unix.

[arguile-]

Compiling from darwin has same issue, specifying --platforms=@io_bazel_rules_go//go/toolchain:linux_amd64 does not exhibit the same issue on that platform.

In our case, our use of goos and goarch is for defining container binaries (targeting linux).

gRPC v1.13 does not have that import so as a work-around you can define org_golang_google_grpc pinned at that version (or before) in WORKSPACE before go_rules_dependencies() is called.

[Xjs]

@jayconrod quickly tested, getting

$ bazel build --platforms=@io_bazel_rules_go//go/toolchain:linux_amd64 main
[...]
(10:55:21) ERROR: While resolving toolchains for target @org_golang_x_sys//unix:go_default_library._cgo_.o: no matching toolchains found for types @bazel_tools//tools/cpp:toolchain_type
(10:55:21) ERROR: While resolving toolchains for target @org_golang_x_sys//unix:go_default_library.cgo_c_lib: no matching toolchains found for types @bazel_tools//tools/cpp:toolchain_type
(10:55:21) ERROR: While resolving toolchains for target @org_golang_x_sys//unix:go_default_library.cgo_cxx_lib: no matching toolchains found for types @bazel_tools//tools/cpp:toolchain_type

in the repository linked in the issue.

Out of a hunch, I also tried with --compiler=mingw-gcc --glibc=mingw, but got the same error message.

Will not dig deeper myself right now, but let me know if I can provide more information.

[mishudark]

I have the same error on MacOS

bazel test //...

GoCompile: missing strict dependencies:
	/private/var/tmp/_bazel_mishel.vera/6b2c87153a1a9c49b8acbab759a652c0/sandbox/darwin-sandbox/371/execroot/__main__/external/org_golang_google_grpc/internal/channelz/types_linux.go: import of "golang.org/x/sys/unix"
Known dependencies are:
	google.golang.org/grpc/connectivity
	google.golang.org/grpc/credentials
	google.golang.org/grpc/grpclog

[jayconrod]

@Xjs I just tried to reproduce this again, but I ran into a crash (reported bazelbuild/bazel#6169). I'll look into this further soon.

@arguile- Unfortunately, goos, goarch don't work with select. It may be possible to do something like this in the future, but we're waiting on some features described in the Bazel configurability roadmap.

@mishudark Are you building this with a goos or goarch attribute?