https://pantsbuild.org/ logo
Join Slack
Powered by
Hey all - back here with another go packaging ques...
# general
s
Hey all - back here with another go packaging question. I’m running the package command in a docker environment defined as
Copy code
docker_environment(
    name="linux_go",
    platform="linux_x86_64",
    image="golang:1.20"
)
with this target
Copy code
go_binary(
    name="bin",
    cgo_enabled=False,
    environment=parametrize("osx", "linux_go")
)
and getting the following error
Copy code
Engine traceback:
  in `package` goal

ProcessExecutionFailure: Process 'Link Go binary: ./package_analyzer' failed with exit code 1.
stdout:
loadinternal: cannot find runtime/cgo

stderr:
2023/08/17 01:39:45 go/build: reference to nonexistent package runtime
I’ve tried messing around with a few other go-based docker images but they all fail somehow related to the 
runtime
package. Is there a recommended way to utilize docker environments for this? My assumption was it just needed the tools to compile the binary, but it looks like some of the dependency inference is occurring in that environment as well. Thanks!
h
cc @fast-nail-55400, our golang plugin expert
But yes, all relevant processes will run in the environment, not just the compiler, so that would include dep inference processes I assume
f
The issue is the Go backend is trying to build one of its support binaries and is not finding cgo, which would be different than normal Go compilation by the Go backend.
👍 1
./package_analyzer
is the support Go binary used by the Go backend to parse Go code for its imports and other metadata
s
Thanks for the insight! Is there an off-the-shelf alternative image I should use, or is it supposed to be something like a dev-container where it emulates the whole environment?
f
I don't think that is the problem
It is likely the package archive for runtime/cgo is not being added to the linker command line when linking that support binary.
the more direct error is 
2023/08/17 01:39:45 go/build: reference to nonexistent package runtime
which is just weird, the 
runtime
package in the SDK should always be available in the 
GOROOT
🫥 1
s
f
yes that is the rule which invokes another rule to build the support binary
Can you split the 
go_binary
target into two different targets and see if the issue persists?
I want to make sure paramatrize is not the culprit.
The environment support for the Go backend is not stable; certainly I have not tried to test it in all possible combinations.
s
sure thing - here’s the new linux-only target
Copy code
go_binary(
    name="bin-linux",
    cgo_enabled=False,
    environment="linux_go"
)
with a slightly more verbose error?
Copy code
17:08:29.02 [ERROR] 1 Exception encountered:

Engine traceback:
  in `package` goal

ProcessExecutionFailure: Process 'Link Go binary: ./package_analyzer' failed with exit code 1.
stdout:
loadinternal: cannot find runtime/cgo

stderr:
link: reference to undefined builtin "runtime.morestack_noctxt" from package "runtime"



Use `--keep-sandboxes=on_failure` to preserve the process chroot for inspection.
The environment support for the Go backend is not stable; certainly I have not tried to test it in all possible combinations.
No worries! Luckily this is just for a hobby project. If you want to dig in further, here’s the repo/PR i’m working on https://github.com/ianwesleyarmstrong/distributed-services-with-go-pants/pull/10
f
It would be helpful if you can run with 
-ldebug
and upload the logs into a GitHub issue.
✅ 1
s
l
@silly-spring-18687 curious if you have you made any progress on this. wondering if using 
golang:1.20
as the image will work as 
unzip
is not installed. I guess one option would be to extend the image and install the 
unzip
lib
Open in Slack
PreviousNext
Powered by