Cross-package asm #include error
eliottness opened this issue · 1 comments
What version of rules_go are you using?
We are using v0.40.1. (cf. MRE)
What version of gazelle are you using?
We are using v0.30.0. (cf. MRE)
What version of Bazel are you using?
$ bazel version
Bazelisk version: development
Build label: 6.3.0
Build target: bazel-out/darwin_arm64-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Mon Jul 24 17:26:34 2023 (1690219594)
Build timestamp: 1690219594
Build timestamp as int: 1690219594
Does this issue reproduce with the latest releases of all the above?
Yes it does.
What operating system and processor architecture are you using?
OSX 13 latest on arm64 and some GNU/Linux on x64.
What did you do?
Here is the MRE that we have done. To create this I only used the README from rules_go.
The only command needed to run after cloning the repo is bazel build //:main.
What did you expect to see?
I would expect the project to compile when running bazel build //:main because running env CGO_ENABLED=0 go build -a works.
What did you see instead?
Full errors logs here:
❯ bazel build //:main
INFO: Analyzed target //:main (25 packages loaded, 285 targets configured).
INFO: Found 1 target...
ERROR: /private/var/tmp/_bazel_eliott.bouhana/102698d60e14ef29c8a302f064528c7e/external/com_github_ebitengine_purego/internal/fakecgo/BUILD.bazel:3:11: GoCompilePkg external/com_github_ebitengine_purego/internal/fakecgo/fakecgo.a failed: (Exit 1): builder failed: error executing command (from target @com_github_ebitengine_purego//internal/fakecgo:fakecgo) bazel-out/darwin_arm64-opt-exec-2B5CBBC6/bin/external/go_sdk/builder_reset/builder compilepkg -sdk external/go_sdk -installsuffix darwin_arm64 -src ... (remaining 59 arguments skipped)
Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
external/com_github_ebitengine_purego/internal/fakecgo/asm_arm64.s:7: #include: open /var/folders/fn/j3_08pb94p9_hyz4myff84br0000gq/T/abi/abi_arm64.h: no such file or directory
compilepkg: error running subcommand external/go_sdk/pkg/tool/darwin_arm64/asm: exit status 1
Target //:main failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 0.580s, Critical Path: 0.21s
INFO: 3 processes: 3 internal.
FAILED: Build did NOT complete successfully
ERROR: Build failed. Not running target
Preliminary diagnostic
The error happens when compiling this file or its amd64 counter-part which has the following line:
#include "../abi/abi_arm64.h"This line references a file from another package in the same module but because the sandbox is building things package by package, other packages of the same module are not in the same place when compilation takes place. Note for the debugging that the package is only built when cgo is disabled.
Don't hesitate to ask me for more logs or some tests. Thanks for you help 🙇
I just fixed some Cgo assembler related issues, so I wanted to check if they had any impact on this. They do not. This is not related and is still broken (after running bazelisk run //:gazelle -- update-repos -from_file=go.mod in the reproduction repo, since the go.mod and WORKSPACE are out of sync as of the current writing )
Interestingly: The Go project itself uses relative assembler includes in some test files: For example: https://github.com/golang/go/blob/master/src/cmd/asm/internal/asm/testdata/amd64enc.s#L4 ; however the rest of the assembler files all use "same directory" includes, e.g. #include "textflag.h".
My limited understanding of how bazel works: Since this header file is in a different directory, the only way to fix this is to have gazelle parse the #include statements and generate the appropriate package directives. A workaround might be to use a patch on the go_repository rule to edit the generated gazelle BUILD.bazel file to add this file as a dependency for the go_library that uses it.
The workaround that seems to have been committed upstream seems the easiest to me: copy these files and only use "directory relative" #includes .