Closed nunotexbsd closed 1 year ago
The go
go.mod directive probably just needs a version bump to (at least) 1.17
.
thanks for updating the FreeBSD port Nuno! I'm sorry this was my fault: I often do a go get -u
to keep the dependencies up-to-date and it looks like recent updates to the golang.org/x/sys/unix package have included some post-1.16 features like unsafe.Slice. I'll fix for the next release.
The reason I try to pin it to 1.16 is because I deploy siegfried as an app to a google appengine which only supports 1.16 max. To fix this issue for google appengine, I added a replace directive to the mod file with this command: go mod edit -replace golang.org/x/sys@v0.0.0-20220909162455-aba9fc2a8ff2=golang.org/x/sys@v0.0.0-20220722155257-8c9f86f7a55f
Thanks for help and explanation,
Cheers
Same issue on 1.9.6:
# golang.org/x/sys/unix
vendor/golang.org/x/sys/unix/syscall.go:83:7: unsafe.Slice requires go1.17 or later (-lang was set to go1.16; check go.mod)
vendor/golang.org/x/sys/unix/syscall_unix.go:118:7: unsafe.Slice requires go1.17 or later (-lang was set to go1.16; check go.mod)
apologies - I overlooked this one when putting out the latest release (the only change in 1.9.6 is a PRONOM update). I'll re-open this so I don't miss it for the next release.
go mod is up-to-date with v1.10.0
Hello,
I'm updating FreeBSD port from 1.9.4 to 1.9.5.
This port is currently using GO_MODULE variable to the value specified by the module directive in go.mod:
GO_MODULE= github.com/richardlehane/siegfried
to fetch modules automatically from there and build fails at:To fix the problem I switched back to "traditional" method gomod-vendor to get modules:
Any clues about this being related to go.mod recent changes?
Thanks, Nuno Teixeira