You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I try to build two targets, both depending on golang.org/x/sys/unix. One has been generated by Gazelle, the other by a custom tool. The two destination targets are //vendor/golang.org/x/sys/unix:gazelle and //vendor/golang.org/x/sys/unix:vdm. The corresponding top-level targets are //:cross-gazelle-amd64 and //:cross-vdm-amd64.
What did you expect to see?
Both top-level build targets to succeed.
What did you see instead?
The Gazelle-generated build target succeeds as follows:
$ bazel build //:cross-vdm-amd64
INFO: Analyzed target //:cross-vdm-amd64 (0 packages loaded, 0 targets configured).
ERROR: /tmp/cross/BUILD.bazel:35:10: GoLink cross-vdm-amd64_/cross-vdm-amd64 failed: (Exit 1): builder failed: error executing GoLink command (from target //:cross-vdm-amd64) bazel-out/k8-opt-exec-ST-d57f47055a04/bin/external/rules_go~~go_sdk~cross__download_0/builder_reset/builder link -sdk external/rules_go~~go_sdk~cross__download_0 -installsuffix linux_amd64 -arc ... (remaining 17 arguments skipped)
Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
golang.org/x/sys/unix.munmap: relocation target golang.org/x/sys/unix.Syscall not defined
golang.org/x/sys/unix.mremap: relocation target golang.org/x/sys/unix.Syscall6 not defined
golang.org/x/sys/unix.mmap: relocation target golang.org/x/sys/unix.Syscall6 not defined
main.main: relocation target golang.org/x/sys/unix.SyscallNoError not defined
link: error running subcommand external/rules_go~~go_sdk~cross__download_0/pkg/tool/linux_amd64/link: exit status 2
Target //:cross-vdm-amd64 failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 0.679s, Critical Path: 0.23s
INFO: 2 processes: 2 internal.
ERROR: Build did NOT complete successfully
The key difference appears to be that the working target specifies the source files in golang.org/x/sys/unix individually, whereas the failing target uses a glob. Changing the working target to use an identical glob breaks the build. Crucially, asm_linux_amd64.s seems to be filtered out. However, the glob is definitely including it, as adding + ["asm_linux_amd64.s"] to the glob results in an error about the file being included twice.
I'll investigate modifying vdm to produce explicit files like Gazelle, but I wouldn't have thought that would be necessary. Any help would be much appreciated.
The text was updated successfully, but these errors were encountered:
Minor update, I've managed to identify the following 10 files in golang.org/x/sys/unix that somehow break the build. The latest commit in https://github.com/SlyMarbo/cross shows this. The breaking files are:
syscall_hurd.go
types_aix.go
types_darwin.go
types_dragonfly.go
types_freebsd.go
types_netbsd.go
types_openbsd.go
types_solaris.go
zsyscall_aix_ppc.go
zsyscall_aix_ppc64_gccgo.go
Each file has sensible build tags and thus should be ignored with GOOS=linux GOARCH=amd64, but removing any of them from the exclude list breaks the build.
What version of rules_go are you using?
0.50.1
What version of gazelle are you using?
0.37.0
What version of Bazel are you using?
Bazelisk version: v1.20.0
Build label: 7.2.0
Build target: @@//src/main/java/com/google/devtools/build/lib/bazel:BazelServer
Build time: Mon Jun 10 13:04:32 2024 (1718024672)
Build timestamp: 1718024672
Build timestamp as int: 1718024672
Does this issue reproduce with the latest releases of all the above?
Yes
What operating system and processor architecture are you using?
Linux x86-64
Any other potentially useful information about your toolchain?
N/A
What did you do?
I'm trying to cross-compile (statically linking) a package that depends on a vendored copy of
golang.org/x/sys/unix
. I've made a fairly minimal reproduction at https://github.com/SlyMarbo/cross.I try to build two targets, both depending on
golang.org/x/sys/unix
. One has been generated by Gazelle, the other by a custom tool. The two destination targets are//vendor/golang.org/x/sys/unix:gazelle
and//vendor/golang.org/x/sys/unix:vdm
. The corresponding top-level targets are//:cross-gazelle-amd64
and//:cross-vdm-amd64
.What did you expect to see?
Both top-level build targets to succeed.
What did you see instead?
The Gazelle-generated build target succeeds as follows:
The vdm-generated build target fails as follows:
The key difference appears to be that the working target specifies the source files in
golang.org/x/sys/unix
individually, whereas the failing target uses a glob. Changing the working target to use an identical glob breaks the build. Crucially,asm_linux_amd64.s
seems to be filtered out. However, the glob is definitely including it, as adding+ ["asm_linux_amd64.s"]
to the glob results in an error about the file being included twice.I'll investigate modifying vdm to produce explicit files like Gazelle, but I wouldn't have thought that would be necessary. Any help would be much appreciated.
The text was updated successfully, but these errors were encountered: