rules_go: cgo does not propagate mode. sys/unix is broken with race = "on"

I’m trying version 0.13.0 of rules_go and gazelle. Thanks for the # gazelle:proto disable_global, it is great, now I don’t need to wait for the protoc to be compiled.

But I’m getting the following errors:

warning: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: warning for library: bazel-out/darwin-fastbuild/bin/vendor/golang.org/x/sys/unix/libgo_default_library.cgo_c_lib.lo the table of contents is empty (no object file members in the library define global symbols)
ERROR: /Users/ash2k/go/src/github.com/atlassian/smith/vendor/golang.org/x/sys/unix/BUILD.bazel:3:1: GoCompile vendor/golang.org/x/sys/unix/darwin_amd64_race_stripped/go_default_library~/github.com/atlassian/smith/vendor/golang.org/x/sys/unix.a~partial.a failed (Exit 1)
/private/var/tmp/_bazel_ash2k/18feaf204f522c9679e75c03985bfc8f/sandbox/darwin-sandbox/582/execroot/com_github_atlassian_smith/bazel-out/darwin-fastbuild/bin/vendor/golang.org/x/sys/unix/darwin_amd64_stripped/go_default_library.cgo_codegen~/syscall_unix.cgo1.go:148:5: undefined: raceenabled
/private/var/tmp/_bazel_ash2k/18feaf204f522c9679e75c03985bfc8f/sandbox/darwin-sandbox/582/execroot/com_github_atlassian_smith/bazel-out/darwin-fastbuild/bin/vendor/golang.org/x/sys/unix/darwin_amd64_stripped/go_default_library.cgo_codegen~/syscall_unix.cgo1.go:150:4: undefined: raceWriteRange
/private/var/tmp/_bazel_ash2k/18feaf204f522c9679e75c03985bfc8f/sandbox/darwin-sandbox/582/execroot/com_github_atlassian_smith/bazel-out/darwin-fastbuild/bin/vendor/golang.org/x/sys/unix/darwin_amd64_stripped/go_default_library.cgo_codegen~/syscall_unix.cgo1.go:153:4: undefined: raceAcquire
/private/var/tmp/_bazel_ash2k/18feaf204f522c9679e75c03985bfc8f/sandbox/darwin-sandbox/582/execroot/com_github_atlassian_smith/bazel-out/darwin-fastbuild/bin/vendor/golang.org/x/sys/unix/darwin_amd64_stripped/go_default_library.cgo_codegen~/syscall_unix.cgo1.go:160:5: undefined: raceenabled
/private/var/tmp/_bazel_ash2k/18feaf204f522c9679e75c03985bfc8f/sandbox/darwin-sandbox/582/execroot/com_github_atlassian_smith/bazel-out/darwin-fastbuild/bin/vendor/golang.org/x/sys/unix/darwin_amd64_stripped/go_default_library.cgo_codegen~/syscall_unix.cgo1.go:161:3: undefined: raceReleaseMerge
/private/var/tmp/_bazel_ash2k/18feaf204f522c9679e75c03985bfc8f/sandbox/darwin-sandbox/582/execroot/com_github_atlassian_smith/bazel-out/darwin-fastbuild/bin/vendor/golang.org/x/sys/unix/darwin_amd64_stripped/go_default_library.cgo_codegen~/syscall_unix.cgo1.go:164:5: undefined: raceenabled
/private/var/tmp/_bazel_ash2k/18feaf204f522c9679e75c03985bfc8f/sandbox/darwin-sandbox/582/execroot/com_github_atlassian_smith/bazel-out/darwin-fastbuild/bin/vendor/golang.org/x/sys/unix/darwin_amd64_stripped/go_default_library.cgo_codegen~/syscall_unix.cgo1.go:165:3: undefined: raceReadRange
/private/var/tmp/_bazel_ash2k/18feaf204f522c9679e75c03985bfc8f/sandbox/darwin-sandbox/582/execroot/com_github_atlassian_smith/bazel-out/darwin-fastbuild/bin/vendor/golang.org/x/sys/unix/darwin_amd64_stripped/go_default_library.cgo_codegen~/syscall_unix.cgo1.go:363:5: undefined: raceenabled
/private/var/tmp/_bazel_ash2k/18feaf204f522c9679e75c03985bfc8f/sandbox/darwin-sandbox/582/execroot/com_github_atlassian_smith/bazel-out/darwin-fastbuild/bin/vendor/golang.org/x/sys/unix/darwin_amd64_stripped/go_default_library.cgo_codegen~/syscall_unix.cgo1.go:364:3: undefined: raceReleaseMerge
GoCompile: error running subcommand: exit status 2

I’ve tried nuking everything with rm -rf /private/var/tmp/_bazel_<user> (I thought maybe this is the recent OS update…) but I’m getting the same error regardless. This is on latest macOS, bazel 0.15.0. Same code and same dependencies work fine with 0.12.1.

To reproduce:

clone https://github.com/atlassian/smith into your gopath
checkout rules_0.13.0 branch
run dep ensure (you need to have dep installed)
run make test

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 2
Comments: 15 (15 by maintainers)

Commits related to this issue

cgo: declare rules for each supported mode, select in aspect go_binary and go_test allow developers to set mode attributes that affect build tags, such as goos, goarch, race, and msan. These attribut... — committed to jayconrod/rules_go by deleted user 6 years ago
cgo: declare rules for each supported mode, select in aspect go_binary and go_test allow developers to set mode attributes that affect build tags, such as goos, goarch, race, and msan. These attribut... — committed to atlassian/rules_go by deleted user 6 years ago
cgo: declare rules for each supported mode, select in aspect (#1595) go_binary and go_test allow developers to set mode attributes that affect build tags, such as goos, goarch, race, and msan. These... — committed to bazelbuild/rules_go by jayconrod 6 years ago
cgo: declare rules for each supported mode, select in aspect (#1595) go_binary and go_test allow developers to set mode attributes that affect build tags, such as goos, goarch, race, and msan. These ... — committed to bazelbuild/rules_go by jayconrod 6 years ago

Most upvoted comments

The select issue comes up when you have something like this:

go_binary(
    name = "cmd",
    goos = "linux",
    goarch = "amd64",
    embed = [":go_default_library"],
)

go_library(
    name = "go_default_library",
    srcs = [...],
    deps = select({
        "@io_bazel_rules_go//go/platform:linux": [":linux_only"],
        "@io_bazel_rules_go//go/platform:windows": [":windows_only"],
        "//conditions:default": [],
    }),
)

The problem is that select is not aware (and cannot be made aware) of the mode attributes (goos, goarch, pure, static, msan, race). The mode attributes are implemented using an aspect. So Bazel basically constructs the configured target graph normally (ignoring the mode attributes), then creates a copy of the target graph with the aspect, and the copy is what gets built. select is used to build the original configured target graph before the aspect gets applied.

So in the situation above, if you build the go_binary on Windows, it will compile for Linux, but a Windows-only dependency will be built (that will probably fail the build), and the Linux-only dependency will be missing. I think this is always going to break loudly. One silent situation is when Bazel builds a package for the wrong platform without errors, but the sources that import that package should be filtered out by build constraints, so it wouldn’t get linked into the final build.

If you don’t have any platform-specific dependencies in your dependency graph (i.e., you don’t need select to work correctly), you’re probably fine. If you have unix dependencies and you’re building from a unix platform (e.g., host is darwin, target is linux), that’s probably okay, but be careful.

jayconrod on Sep 17, 2018

There are two test files which already have // +build !race, and have since before we wrote bazel rules. I guess we could arguably just remove the race = "off" annotation on those, since that would be equivalent coverage as what we had before.

Specifically:

pkg/master/master_openapi_test.go: the race detector made this test slow and often timeout (https://github.com/kubernetes/kubernetes/pull/39649)
staging/src/k8s.io/client-go/tools/cache/mutation_detector_test.go: I have no idea why it was disabled here

Thanks for merging #1595. When do you expect there will be a new rules_go release?

ixdy on Aug 30, 2018