bzlmod + golang + cgo = undefined symbols

[bdleitner]

What version of rules_go are you using?

0.50.1

What version of gazelle are you using?

0.38.0

What version of Bazel are you using?

7.4.1

Does this issue reproduce with the latest releases of all the above?

I believe I am on the latest for all these.

What operating system and processor architecture are you using?

Windows 10 64-bit

Any other potentially useful information about your toolchain?

I admit I am not sure I have everything correctly set up. I have mingw-64 within msys2 on my system. I've been unable to find from-scratch documentation to make sure my setup is fully cgo-ready so if there is documentation for this that would reveal I've missed something, a pointer to that would be appreciated.

What did you do?

I attempted first to have my bzlmod monolith repo depend on a library (gosseract) that uses cgo. When that failed I also tried just implementing an example cgo library.

golang_bzlmod_demo has minimal examples of all the issues I've had with golang/bzlmod that I've been able to repro. The cgoimport and cgo subprojects illustrate the import failure and the self-contained failure, respectively. The specific errors I see are shown in the README files there.

What did you expect to see?

I expected the code to compile and to be able to use the library code.

What did you see instead?

The builds failed with "undefined" errors for every time a symbol in the cgo-using library was referenced.

[bdleitner]

Looks like gazelle has v0.40.0 out. I wouldn't expect that to matter since the issue seems unrelated to gazelle, but just in case I tried changing the version to 0.40.0 locally and got all the same errors.

[alexey-artemjev]

Try use pure = off in binary that depends on lib.

[alercah]

There is no pure option on a go_libarary rule, and the go_libarary rule will fail to compile without cgo.

[alexey-artemjev]

I mean pure in go_binary which uses that lib. You can find that binary with the following command: bazelisk query "rdeps(//..., //lib)" or if it external lib do the same actions but with lib that uses it: bazelisk query "rdeps(//..., //lib_which_uses_external_lib)"

Or you may try to set pure in attributes https://github.com/bazel-contrib/rules_go/blob/master/go/modes.rst#mode-attributes (I didn't try that)

[bdleitner]

I believe I ran into this kind of error again today as I was trying to look into the fyne library.

I updated the deps for rules_go and gazella in my cgoimport minimal example. I am still able to reproduce the issue in bazel 8.3.0.

Aided by Gemini, I found some more information that may be useful.

• bazel build @com_github_otiai10_gosseract_v2//:gosseract succeeds
• bazel build --verbose_failures @com_github_otiai10_gosseract_v2//:gosseract_test fails, see attached gosseract_test_failure.txt
  • Note SET CGO_ENABLED=0
• bazel query @com_github_otiai10_gosseract_v2//:gosseract_test --output=build gives the following:

go_test(
  name = "gosseract_test",
  generator_name = "gosseract_test",
  generator_function = "go_test_macro",
  generator_location = "D:/_bazel_out/uni3i7pb/external/gazelle++go_deps+com_github_otiai10_gosseract_v2/BUILD.bazel:39:8",
  srcs = ["@com_github_otiai10_gosseract_v2//:all_test.go", "@com_github_otiai10_gosseract_v2//:benchmark_test.go", "@com_github_otiai10_gosseract_v2//:example_test.go"],
  deps = ["@@gazelle++go_deps+com_github_otiai10_mint//:mint"],
  embed = ["@com_github_otiai10_gosseract_v2//:gosseract"],
)

• bazel build --verbose_failures //ocr:ocr_lib failed:
  ocr_lib_failure.txt
  • Note: SET CGO_ENABLED=0 even though cgo=True is on the ocr_lib target.
  • I still see SET CGO_ENABLED=0 even if I run the command as bazel build --action_env=CGO_ENABLED=1 --verbose_failures //ocr:ocr_lib which seems... wrong?
• I'm not sure if it'll help, Gemini suggested I run with toolchain_resolution_debug, and that got bazel_cgo_issue_log.txt
• Also at Gemini's suggestion, I navigated to the Bazel execroot in the bazel out directory for this workspace and then to external/rules_go++go_sdk+go_default_sdk/bin there. A go env CGO_ENABLED run there resulted in 1, which seems to contradict the SET CGO_ENABLED=0 I'm seeing elsewhere.

This is posing a real problem in the ability to use dependencies that use cgo anywhere down the line. Please up the priority.

[bdleitner]

I wonder if #4356 is potentially related? The symptom of always seeing SET CGO_ENABLED=0 seems to match