Cross-compilation to Linux on MacOS sets CGO_ENABLED=0 even though cgo=True in go_library and platform set to linux_amd64_cgo about rules_go HOT 7 CLOSED

In fact, when I add this to WORKSPACE:

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

http_archive(
    name = "musl_toolchains",
    sha256 = "79c3dab39eb52a9c0927f6a222e2a10b733fd875ccdad59feadd5b30fd4518fb",
    url = "https://github.com/bazel-contrib/musl-toolchain/releases/download/v0.1.9/musl_toolchain-v0.1.9.tar.gz",
)

load("@musl_toolchains//:repositories.bzl", "load_musl_toolchains")

load_musl_toolchains()

load("@musl_toolchains//:toolchains.bzl", "register_musl_toolchains")

register_musl_toolchains()

and this to .bazelrc:

common --features=fully_static_link

it just works:

Read text from DB: Hello SQLite!

@illicitonion A great occasion to say "nice job"! Are you still planning to add Bazel support to musl-toolchain? ;-)

from rules_go.

do you have either of these flags set in .bazelrc?

build --features=pure --features=static

from rules_go.

What I don't see in the reproducer is a C++ toolchain that runs on macOS and targets Linux, such as https://github.com/bazel-contrib/musl-toolchain. Without such a toolchain, I don't see how you could compile CGO for Linux, but maybe I am misunderstanding what you are trying to achieve.

from rules_go.

@derekperkins neither of those were set.

@fmeum Thank you! It looks like this works (the added musl-toolchain plus --features=fully_static_link).

A few follow-up questions:

1. Looks like y'all just added support for bzlmod loading musl-toolchain (https://github.com/bazel-contrib/musl-toolchain/releases/tag/v0.1.10). When do you expect this will be available on the Bazel Central Registry so it can be used? In the monorepo I was reproducing, we've moved wholly to bzlmod and would like to keep it that way.
2. Is there any way to set --features=fully_static_link from Starlark so it's always run for a target and doesn't need to be set on the command line? I can't set it in .bazelrc as I have other targets which should never be run with this flag. I'd also rather it not be a surprise in the future (as someone will invariably forget to add the flag if it's not encoded in the build directly).
3. Is there any way to force a failure to build with cgo to cause a build failure? My binary absolutely requires SQLite to run correctly and it's very surprising that the same target can give wildly different runtime behavior (working vs. very much not) without any form of feedback. I'd rather avoid having a place where a platform transition causes a semantically different binary to be built. A perfect world would involve a successful build to give high confidence that runtime will work as expected.

from rules_go.

1. There are some problems with the BCR setup that we are iterating on and release take pretty long to build due to musl building from source, but soon.
2. I will enable this feature in the toolchain by default in a follow-up release.
3. Failing at runtime instead of build time is a conscious choice by go-sqlite3. Without that file, rules_go would fail at build time if CGo isn't available.

Since the remaining issues are unrelated to rules_go (and will be addressed soon in musl-toolchain), I will close this issue.

from rules_go.

@fmeum While I agree that go-sqlite3 choosing to be compilable in both fashions isn't the responsibility of rules_go, #3 (above) is specifically about my ability to mark a go_binary or go_library as requiring cgo compilation and failing when it can't be configured.

How can I make it so that there is a human-readable error which directly signals the Bazel target which required cgo, that cgo was not available, and plausibly some information about why it wasn't available? If this isn't available in rules_go right now (as I expect it isn't from this thread), then do you have any recommendations for how to hack some target which will fail in a reasonably readable fashion?

from rules_go.

How can I make it so that there is a human-readable error which directly signals the Bazel target which required cgo, that cgo was not available, and plausibly some information about why it wasn't available? If this isn't available in rules_go right now (as I expect it isn't from this thread), then do you have any recommendations for how to hack some target which will fail in a reasonably readable fashion?

This is directly available in Go itself and should also work with rules_go: The usual way how you would have something fail without cgo is by having it depend on something that is only there with cgo. Most Go packages provide both cgo and non-cgo definitions specifically to prevent this from happening, but if you want it, you could add a file with a !cgo or purego build tag and have it fail compilation or, alternatively, have a dependency on something in a cgo tagged file.

from rules_go.