Bazel go rule problem

[Carl Quinn]

I am having trouble getting the latest 0.5.0 version of rules_go to work with some Go libraries, and I am hoping this is the right place to ask. This is with a mostly 0.4.5 version of Bazel, with a couple of patches from the latest 0.5.1.

One of the libraries that exhibit the problem is https://github.com/spf13/cobra.

With a trivial main.go of:

package main
import (
"github.com/spf13/cobra"
)
func main() {
cobra.OnInitialize(func() {})
}

And BUILD of:

load("@io_bazel_rules_go//go:def.bzl", "go_binary", "go_library")
go_library(
    name = "go_default_library",
    srcs = [
        "main.go",
    ],
    visibility = ["//visibility:private"],
    deps = [
        "@github_com_spf13_cobra//:go_default_library",
        "@github_com_spf13_pflag//:go_default_library",
    ],
)
go_binary(
    name = "breaks",
    library = ":go_default_library",
    visibility = ["//visibility:public"],
)

And the WORKSPACE entries of:

go_repository(
    name = "github_com_spf13_cobra",
    importpath = "github.com/spf13/cobra",
    commit = "e458bb7ab84aae1bb4b4d36eccf9332f0d659e38",
)
go_repository(
    name = "github_com_spf13_pflag",
    importpath = "github.com/spf13/pflag",
    commit = "e57e3eeb33f795204c1ca35f56c44f83227c6e66",
) 

Bazzel errors out with:

ERROR: /home/carl/.cache/bazel/_bazel_carl/fe86bc66a3ff77706ee81b4d35b28ef3/external/github_com_spf13_cobra/BUILD.bazel:5:1: no such package '@com_github_spf13_pflag//': No such repository and referenced by '@github_com_spf13_cobra//:go_default_library'.
ERROR: Analysis of target '//experimental/carl/breaks:breaks' failed; build aborted.

With stock Bazel 0.4.5 it's actually an IllegalStateException due to the REPOSITORY_NOT_FOUND case not being handled that is fixed in 0.5.0, but the underlying problem is the same. The Gazelle generated BUILD.bazel files seem OK, but I can post them if that would help.

So I guess I am wondering if anyone else has seen this, or has built spf13/cobra successfully, or has some ideas.

thanks,

carl

[Ian Cottrell]

The workspace names do not match the ones gazelle is expecting, you have called it "github_com_spf13_pflag" but it should be "com_github_spf13_pflag"(the com bit comes first). When the rules download the github.com/spf13/cobra package, they automatically generate build files for it by running gazelle, which is why you must match it's conventions in your WORKSPACE at the moment. github_com_spf13_cobra is also wrong but you are writing those dependencies by hand, so it does not matter.

In general, if you use wtool and gazelle to generate your workspace and build files, you won't see these issues, and if they don't work for you we would love to hear about it!

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/ba29bd66-992a-430b-a28b-99769a6f9f36%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Carl Quinn]

Thanks Ian, that was exactly the problem! 

I had not even noticed the github_com vs com_github difference in the various build files.

I am trying to introduce Go to our team that uses Bazel, so I want to be able to show off how easy and productive it is for building microservices using Goa.

I wanted to get my head around the build environment differences between Go and Bazel and how the plugin handled them before I relied on the tools. But I will try wtool next time, and I had used gazelle to get my project's BUILD files created initially but will try it more. 

I now just need to wait for the fix for https://github.com/bazelbuild/rules_go/issues/526 to be released to get past the next hurdle :)

[Carl Quinn]

I was able to grab rules_go from latest master by adjusting its git_repository def:

    #tag = "0.5.0",

    commit = "dd999cefc15bbfd4f74ade6efb45bc6118309bf4",

I am now seeing a compile error with mattn/go-sqlite3, so I'll check the current issues and make sure this is known.

ERROR: /home/carl/.cache/bazel/_bazel_carl/fe86bc66a3ff77706ee81b4d35b28ef3/external/com_github_mattn_go_sqlite3/BUILD.bazel:5:1: C++ compilation of rule '@com_github_mattn_go_sqlite3//:cgo_default_library.cgo_c_lib' failed: gcc failed: error executing command tools/cpp/gcc-4.8/bin/gcc -nostdinc -isystem external/gcc_4_8/usr/include -isystem external/gcc_4_8/usr/include/x86_64-linux-gnu -isystem external/gcc_4_8/usr/lib/gcc/x86_64-linux-gnu/4.8/include ... (remaining 56 argument(s) skipped): com.google.devtools.build.lib.shell.BadExitStatusException: Process exited with status 1.

/home/carl/.cache/bazel/_bazel_carl/fe86bc66a3ff77706ee81b4d35b28ef3/execroot/driving/external/com_github_mattn_go_sqlite3/sqlite3.go:62:1: error: '_sqlite3_exec' defined but not used [-Werror=unused-function]

 _sqlite3_exec(sqlite3* db, const char* pcmd, long long* rowid, long long* changes)

 ^

cc1: all warnings being treated as errors

[Jay Conrod]

Just to close the loop, this was discussed further and resolved in https://github.com/bazelbuild/rules_go/issues/578.

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/e20d53ac-1be8-4046-8f38-4a68d242479a%40googlegroups.com.

[Carl Quinn]

@jayconrod pointed out to me that this last problem must have been a -Werror in our crosstools, and sure enough, that was it.

But after setting up a custom BUILD file for mattn/go-sqlite3, I have one last issue. We have:

   linker_flag: "-nodefaultlibs"

in our crosstools, and I can't figure out how to override this in a cgo_library rule. With the -nodefaultlibs in place, the link fails with a bunch of "undefined reference to `pthread_*'" errors. With that option the link succeeds. But I can't globally remove that flag since much of our C++ relies on it.

It seems too that the default linker_flags are placed after rule's clinkopts, so it'd be tricky to add an override that way.

I'm wondering if anyone knows how to redact default linker flags in a cgo_library rule, or another way to explicitly undo the -nodefaultlibs.

[Carl Quinn]

OK, my office mate figured this out for me. Adding a -lpthread to the clinkopts took care of bypassing the -nodefaultlibs and getting pthread linked:

...

clinkopts = [

    "-lpthread"

] + select({

...

Thanks for all the help everyone!