Golang.org/x/net/http2 module requires Go 1.17

I am getting the below error when I am building my project source. I downgraded my go version from 1.18 to 1.17. Still the issue exists. Can someone help me to fix this issue?

Error Logs:

golang.org/x/net/http2

…/…/…/…/pkg/mod/golang.org/x/net@v0.0.0-20211112202133-69e39bad7dc2/http2/transport.go:417:45: undefined: os.ErrDeadlineExceeded
note: module requires Go 1.17

Go Version:

vediyappan@LX-9N9H9R2:~/work/projectxyz/build$ go version
go version go1.17.8 linux/amd64

Hi! In my experience, Sub-repositories - Go Packages suite only supports the latest two big Go releases. Try to upgrade Go to 1.20 or at least 1.19 (if you really need it for some reason like remote platform requirements). Downgrade is not a good thing in 90% of cases unless is strictly necessary.

@Metalymph Thanks for the info. I was using latest version of go . I just downgraded and checked to narrow down the issue. I am using the GO in Yocto environment. When I am building the packages separately, packages were built correctly. When building through yocto’s bitbake, it shows such “module requires Go 1.17” and “module requires Go 1.18”. Any suggestions?

vediyappan@LX-9N9H9R2:~$ go version
go version go1.19.6 linux/amd64

I tried to update the packages to latest version using “go install” for external packages and “go get” for the internal packages. But this approach also didn’t help.

vediyappan@LX-9N9H9R2:~/work/yoctoproject/build$ go install github.com/edgexfoundry/go-mod-messaging/v3/internal/pkg/mqtt@latest
go: downloading github.com/edgexfoundry/go-mod-messaging v0.1.30
go: downloading github.com/edgexfoundry/go-mod-messaging/v3 v3.0.0-dev.14
go: downloading golang.org/x/sync v0.0.0-20210220032951-036812b2e83c
package github.com/edgexfoundry/go-mod-messaging/v3/internal/pkg/mqtt is not a main package
vediyappan@LX-9N9H9R2:~/work/yoctoproject/build$
vediyappan@LX-9N9H9R2:~/work/yoctoproject/build$ go get golang.org/x/sys/unix
go: downloading golang.org/x/sys v0.6.0
go: added golang.org/x/sys v0.6.0
vediyappan@LX-9N9H9R2:~/work/yoctoproject/build$ go version
go version go1.19.6 linux/amd64

I’m not proficient with Yocto and Bitbake, but since it uses a separated Linux environment and Bitbake is based on it maybe there’s a mistake in some building phase. Could you post the verbose stack? With go build -x

Here is the output of “go build -x The Go Programming Language”:

vediyappan@LX-9N9H9R2:~/work/yoctoproject/build$ go build -x golang.org/x/sys/unix
WORK=/tmp/go-build2295568789
go: downloading golang.org/x/sys v0.6.0
# get https://proxy.golang.org/golang.org/x/sys/@v/v0.6.0.zip
# get https://proxy.golang.org/golang.org/x/sys/@v/v0.6.0.zip: 200 OK (0.639s)
# get https://proxy.golang.org/golang.org/x/sys/@v/v0.6.0.mod
# get https://proxy.golang.org/golang.org/x/sys/@v/v0.6.0.mod: 200 OK (0.046s)
# get https://proxy.golang.org/golang.org/x/sys/@v/v0.6.0.info
# get https://proxy.golang.org/golang.org/x/sys/@v/v0.6.0.info: 200 OK (0.039s)
mkdir -p $WORK/b001/
cat >$WORK/b001/go_asm.h << 'EOF' # internal
EOF
cd /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix
/snap/go/10050/pkg/tool/linux_amd64/asm -p golang.org/x/sys/unix -trimpath "$WORK/b001=>" -I $WORK/b001/ -I /snap/go/10050/pkg/include -D GOOS_linux -D GOARCH_amd64 -D GOAMD64_v1 -gensymabis -o $WORK/b001/symabis ./asm_linux_amd64.s
cat >$WORK/b001/importcfg << 'EOF' # internal
# import config
packagefile bytes=/snap/go/10050/pkg/linux_amd64/bytes.a
packagefile encoding/binary=/snap/go/10050/pkg/linux_amd64/encoding/binary.a
packagefile math/bits=/snap/go/10050/pkg/linux_amd64/math/bits.a
packagefile runtime=/snap/go/10050/pkg/linux_amd64/runtime.a
packagefile sort=/snap/go/10050/pkg/linux_amd64/sort.a
packagefile strconv=/snap/go/10050/pkg/linux_amd64/strconv.a
packagefile strings=/snap/go/10050/pkg/linux_amd64/strings.a
packagefile sync=/snap/go/10050/pkg/linux_amd64/sync.a
packagefile syscall=/snap/go/10050/pkg/linux_amd64/syscall.a
packagefile time=/snap/go/10050/pkg/linux_amd64/time.a
EOF
cd /home/vediyappan/work/yoctoproject/build
/snap/go/10050/pkg/tool/linux_amd64/compile -o $WORK/b001/_pkg_.a -trimpath "$WORK/b001=>" -p golang.org/x/sys/unix -lang=go1.17 -buildid DUZ1Wxy9rsbxQplMBR2c/DUZ1Wxy9rsbxQplMBR2c -goversion go1.19.6 -symabis $WORK/b001/symabis -c=4 -nolocalimports -importcfg $WORK/b001/importcfg -pack -asmhdr $WORK/b001/go_asm.h /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/affinity_linux.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/aliases.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/bluetooth_linux.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/constants.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/dev_linux.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/dirent.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/endian_little.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/env_unix.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/fcntl.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/fdset.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/ifreq_linux.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/ioctl.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/ioctl_linux.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/pagesize_unix.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/race0.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/readdirent_getdents.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/sockcmsg_linux.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/sockcmsg_unix.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/sockcmsg_unix_other.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/syscall.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/syscall_linux.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/syscall_linux_alarm.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/syscall_linux_amd64.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/syscall_linux_amd64_gc.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/syscall_linux_gc.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/syscall_unix.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/syscall_unix_gc.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/sysvshm_linux.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/sysvshm_unix.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/timestruct.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/zerrors_linux.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/zerrors_linux_amd64.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/zptrace_x86_linux.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/zsyscall_linux.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/zsyscall_linux_amd64.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/zsysnum_linux_amd64.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/ztypes_linux.go /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix/ztypes_linux_amd64.go
cd /home/vediyappan/go/pkg/mod/golang.org/x/sys@v0.6.0/unix
/snap/go/10050/pkg/tool/linux_amd64/asm -p golang.org/x/sys/unix -trimpath "$WORK/b001=>" -I $WORK/b001/ -I /snap/go/10050/pkg/include -D GOOS_linux -D GOARCH_amd64 -D GOAMD64_v1 -o $WORK/b001/asm_linux_amd64.o ./asm_linux_amd64.s
/snap/go/10050/pkg/tool/linux_amd64/pack r $WORK/b001/_pkg_.a $WORK/b001/asm_linux_amd64.o # internal
/snap/go/10050/pkg/tool/linux_amd64/buildid -w $WORK/b001/_pkg_.a # internal
cp $WORK/b001/_pkg_.a /home/vediyappan/.cache/go-build/8c/8c727c4308b6b0acb9264b8c239d43df182633746fbbce4bf83c8d99854cdf77-d # internal
vediyappan@LX-9N9H9R2:~/work/yoctoproject/build$

So, you’re saying that:

  • building packages step by step works (also for x/net package?)
  • Building all together gives the error module 1.17/8 required
  • Building the sys/unix package is smoothly so the problem is not the interface between your Golang suite and the underlying system (which is I think a custom yocto instance right? A custom linux so…)
    Hence, the only thing I can say is that your file .bb has a problem or lacks of a command to correctly interface the several modules when your full build is work in progress.
    However what I meant is to post also the full build step analysis with verbose errors in order to find the right step when it fails :wink:

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.