Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

golang.org/x/sys/unix relocation target not defined #4191

Open
SlyMarbo opened this issue Dec 8, 2024 · 1 comment
Open

golang.org/x/sys/unix relocation target not defined #4191

SlyMarbo opened this issue Dec 8, 2024 · 1 comment

Comments

@SlyMarbo
Copy link

SlyMarbo commented Dec 8, 2024

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

$ uname -a
Linux penguin 6.6.50-05090-g02ec56928355 #1 SMP PREEMPT_DYNAMIC Fri, 8 Nov 2024 00:13:13 +0000 x86_64 GNU/Linux

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:

$ bazel build //:cross-gazelle-amd64
INFO: Analyzed target //:cross-gazelle-amd64 (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
Target //:cross-gazelle-amd64 up-to-date:
  bazel-bin/cross-gazelle-amd64_/cross-gazelle-amd64
INFO: Elapsed time: 0.546s, Critical Path: 0.01s
INFO: 1 process: 1 internal.
INFO: Build completed successfully, 1 total action

The vdm-generated build target fails 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.

@SlyMarbo
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant