make fails with undefined: jsoniter error #9000
Labels
kind/bug
Categorizes issue or PR as related to a bug.
locked - please file new issue/PR
Assist humans wanting to comment on an old issue or PR with locked comments.
Comments
openshift-ci-robot
added
the
kind/bug
|
Which version of Go are you using? |
|
|
Same result with Go 1.15.6 . This was on a virtual machine (still Ubuntu 20.04 though) just created for the sake of this test. |
|
Very curious. The log indicates that the git tree is dirty, did you try with Go 1.15 on a clean tree? |
|
Yes, I did try it on a clean tree (in fact the build machine itself was brand new). It was the make that dirtied the tree. See transcript below. |
|
Thanks a lot, @dc25! I will spin up an Ubuntu VM and have a look; I hope to find time today. It passed CI (which is using Ubuntu) and I fail to reproduce locally, so I want to get my hands dirty. |
|
Thank you. Are you using Ubuntu 20.04 or 20.10 (or something else) for CI ? |
Both, 20.04 and 20.10. |
|
For the sake of completeness, I created an Ubuntu 20.10 VM and built on that. Same problem exactly. Also for completeness sake, the shell scripts that I've been using (more or less) to do my builds are here : https://github.com/dc25/buildPodman My intention though is for those scripts to follow the podman instructions as much as possible: https://podman.io/getting-started/installation.html |
|
@dc25 just curious, do you need to use |
|
This indicates something is blowing up in the go generate code. Basically the bindings are not being created correctly. |
Probably not. My intention was to build a "vanilla" podman. Not being sure which options I needed, I went with the first make command on the "Podman Installation Instructions" page ( copied below ). It worked until it broke on 2021-01-14 . At that point it seemed like reporting the problem was the thing to do rather than playing with different BUILDTAGS values. |
|
We debugged it yesterday and found that it's an interplay of an unset $GOPATH, the way the Makefile sets it to I suggest setting |
GOPATH was already exported in the environment in which this bug happened. I'll follow up with a transcript showing this. |
|
I added "set -x" to the bash script that I have been using to demonstrate this bug. As you can see, the first thing that the script does to to export GOPATH. Every demonstration of this bug that I have shown for this issue was done with GOPATH set. |
vrothberg
added a commit
to vrothberg/libpod
that referenced
this issue
Jan 20, 2021
The Go gods did not shine upon us trying to understand what's going on in containers#9000. The symptom is that `go generate` did not add required imports to a generated file, ultimately breaking subsequent compilation. While it still remains unclear *why* Go is behaving like that, the symptom disappears when `go generate` runs in module mode; that is without `-mod=vendor` and without `GO111MODULE=off`. This was reproducible on two separate machines (Ubuntu and Fedora). Also, when facing an unset GOPATH, set it to Go's default (i.e., $HOME/go) and make sure that GOBIN is in PATH since `goimports` is required by `go generate`. Fixes: containers#9000 Signed-off-by: Valentin Rothberg <[email protected]>
iwita
pushed a commit
to iwita/podman
that referenced
this issue
Jan 26, 2021
The Go gods did not shine upon us trying to understand what's going on in containers#9000. The symptom is that `go generate` did not add required imports to a generated file, ultimately breaking subsequent compilation. While it still remains unclear *why* Go is behaving like that, the symptom disappears when `go generate` runs in module mode; that is without `-mod=vendor` and without `GO111MODULE=off`. This was reproducible on two separate machines (Ubuntu and Fedora). Also, when facing an unset GOPATH, set it to Go's default (i.e., $HOME/go) and make sure that GOBIN is in PATH since `goimports` is required by `go generate`. Fixes: containers#9000 Signed-off-by: Valentin Rothberg <[email protected]>
mheon
pushed a commit
to mheon/libpod
that referenced
this issue
Jan 29, 2021
The Go gods did not shine upon us trying to understand what's going on in containers#9000. The symptom is that `go generate` did not add required imports to a generated file, ultimately breaking subsequent compilation. While it still remains unclear *why* Go is behaving like that, the symptom disappears when `go generate` runs in module mode; that is without `-mod=vendor` and without `GO111MODULE=off`. This was reproducible on two separate machines (Ubuntu and Fedora). Also, when facing an unset GOPATH, set it to Go's default (i.e., $HOME/go) and make sure that GOBIN is in PATH since `goimports` is required by `go generate`. Fixes: containers#9000 Signed-off-by: Valentin Rothberg <[email protected]>
github-actions
bot
added
the
locked - please file new issue/PR
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Steps to reproduce the issue:
Clone the podman repo. (per instructions)
make BUILDTAGS="selinux seccomp"
observe output as shown below
Describe the results you expected:
Note that in the above transcript the build was attempted twice. The first time it died in generate-bindings, the second time it died with the "undefined: jsoniter" error.
Additional information you deem important (e.g. issue happens only occasionally):
This is on ubuntu 20.04 . If I revert to the last version of podman from 2021-01-13, (b2ac2a3 ) the problem goes away. For me, for now, this is an acceptable workaround.
Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?
Yes
Additional environment details (AWS, VirtualBox, physical, etc.):
Ubuntu 20.04 physical intel.
The text was updated successfully, but these errors were encountered: