`fatal error: 'resolv.h' file not found` on macOS / nix
Description of the bug:
Hey there Bazel team! I've run into a issue that I can't solve. I'm building a Go project with the following setup:
- macOS 14.7.1
- devenv 1.3.1
- Bazel 8.0.0
When trying to build my project, the resolv.h header can't be found.
$ bazelisk build //hello
INFO: Analyzed target //hello:hello (104 packages loaded, 5659 targets configured).
ERROR: /private/var/tmp/_bazel_kyle/c3d7894f4cdf3c1bcc4683dd549d8b70/external/rules_go~/BUILD.bazel:42:7: GoStdlib external/rules_go~/stdlib_/pkg failed: (Exit 1): builder failed: error executing GoStdlib command (from target @@rules_go~//:stdlib) bazel-out/darwin_arm64-opt-exec-ST-d57f47055a04/bin/external/rules_go~~go_sdk~devenv-bazel-go-broken__download_0/builder_reset/builder stdlib -sdk ... (remaining 13 arguments skipped)
Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
# net/internal/cgotest
bazel-out/darwin_arm64-fastbuild/bin/external/rules_go~/stdlib_/src/net/internal/cgotest/resstate.go:10:10: fatal error: 'resolv.h' file not found
#include <resolv.h>
^~~~~~~~~~
1 error generated.
stdlib: error running subcommand external/rules_go~~go_sdk~devenv-bazel-go-broken__download_0/bin/go: exit status 1
Target //hello:hello failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 27.889s, Critical Path: 12.49s
INFO: 8 processes: 7 internal, 1 darwin-sandbox.
ERROR: Build did NOT complete successfully
I'm confident this is a strange interaction with between Bazel and Nix / devenv, but I'm not having much success figuring out what that interaction is. Would appreciate any help solving the issue!
Which category does this issue belong to?
C++ Rules
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
This requires a nix installation and devenv.sh.
git clone https://github.com/kyleconroy/devenv-bazel-go-broken
cd devenv-bazel-go-broken
devenv shell
bazelisk build //hello
Which operating system are you running Bazel on?
macOS
What is the output of bazel info release?
release 8.0.0
If bazel info release returns development version or (@non-git), tell us how you built Bazel.
No response
What's the output of git remote get-url origin; git rev-parse HEAD ?
[email protected]:kyleconroy/devenv-bazel-go-broken.git
11bd0e334a2ecc44e11ac0b81bdba922b6524640
If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.
No response
Have you found anything relevant by searching the web?
I've opened up an issue (https://github.com/cachix/devenv/issues/1099) on devenv, as I'm not sure where the bug is happening.
I ran into a similar bug back in April and found a few Bazel issues that might be related
- https://github.com/bazel-contrib/rules_go/issues/3793
- https://github.com/bazelbuild/bazel/issues/20638
Any other information, logs, or outputs that you want to share?
No response
+1, I'm affected by this issue too
+1, I'm affected by this issue as well.
I got this to work by unsetting the DEVELOPER_DIR, CC, and CXX environment variables
+1.
Looks like this might be an issue of rules_go, can you please file this against https://github.com/bazel-contrib/rules_go?
I resolved it with llvm gcc.
I resolved it with llvm gcc.
Can you please share more details about your solution? Having the same problem I've tried different things and still couldn't fix it.
Does anyone ever see this error outside of Nix platforms?
I was able to fix this build by using mkShellNoCC instead of mkShell in flake.nix, which doesnt override systems c libs and gazelle worked.
But then I've got infinite loop in abseil build...
Does anyone ever see this error outside of
Nixplatforms?
I'm seeing this on an m1 mac and I don't use Nix @chickenandpork
@cessien ..
Does anyone ever see this error outside of
Nixplatforms?I'm seeing this on an m1 mac and I don't use
Nix@chickenandpork
Hmm. Sorry this is happening to you. Since this — I think — would be a bit simpler than installing Nix, are you able to repro in a simple example?
In parallel, does ‘—incompatible_strict_action_env’ change the outcome?
> /private/tmp/nix-build-go-1.23.7.drv-0/go/src /private/tmp/nix-build-go-1.23.7.drv-0/go
> Building Go cmd/dist using /nix/store/xgpdi6bymml0ca280k07wbkjjl09fba0-go-1.21.0-darwin-arm64-bootstrap/share/go. (go1.21.0 darwin/arm64)
> Building Go toolchain1 using /nix/store/xgpdi6bymml0ca280k07wbkjjl09fba0-go-1.21.0-darwin-arm64-bootstrap/share/go.
> Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
> Building Go toolchain2 using go_bootstrap and Go toolchain1.
> Building Go toolchain3 using go_bootstrap and Go toolchain2.
> Building packages and commands for darwin/arm64.
> # net/internal/cgotest
> ../go/src/net/internal/cgotest/resstate.go:10:10: fatal error: 'resolv.h' file not found
> 10 | #include <resolv.h>
> | ^~~~~~~~~~
> 1 error generated.
> go tool dist: FAILED: /private/tmp/nix-build-go-1.23.7.drv-0/go/pkg/tool/darwin_arm64/go_bootstrap install std: exit status 1
I got a similar issue when try to build a static linked go program using latest nixpkgs-unstable.
Have nothing to do with bazel though, just similar error message.
I resolved it with llvm gcc.
Can you please share more details about your solution? Having the same problem I've tried different things and still couldn't fix it.
you could try with llvm@19. then setting flag :
build --action_env=CC=/opt/homebrew/opt/llvm@19/bin/clang build --action_env=CXX=/opt/homebrew/opt/llvm@19/bin/clang++ build --action_env=LDFLAGS="-L/opt/homebrew/opt/llvm@19/lib" build --action_env=CPPFLAGS="-I/opt/homebrew/opt/llvm@19/include"
you could try with llvm@19. then setting flag :
Thank you, sir. You saved my day
My steps in detail:
brew install llvm
bazel build --action_env=CC=/opt/homebrew/opt/llvm/bin/clang //:go
or put into ~/.bazelrc:
common --action_env=CC=/opt/homebrew/opt/llvm/bin/clang
common --action_env=CXX=/opt/homebrew/opt/llvm/bin/clang++
+1 on opening this as a bug on https://github.com/bazel-contrib/rules_go - I suspect it really belongs there.
@bazelbuild/go-maintainers
Closing this bug as it should go to https://github.com/bazel-contrib/rules_go