Hey guys, having trouble again compiling go for the latest server build 2.13 on linux and mac. Have updated go to 1.15. I have run the mod cache clean and tidy commands as recommended before. Here are the steps we’ve taken:
Delete existing .mod, .sum and .so files.
env GO111MODULE=on go clean -modcache
env GO111MODULE=on go mod tidy
go mod init “go_source”
go get -u “github.com/heroiclabs/nakama-common@v1.7.3”
go build -buildmode=plugin -trimpath -o ./module.so
@oscargoldman Also note that it’s important the exact version of the build toolchain you use. Go 1.15.0 is different to Go 1.15.2 (which is the latest). The 2.13.0 release of Nakama was built with the Go 1.15.0 release of the toolchain. These will need to match for the shared object to be loaded without a mismatch in the Go runtime.
Yeah, we definitely have 1.15.0 installed:
{“level”:“info”,“ts”:“2020-10-01T08:36:38.967-0600”,“caller”:“v2/main.go:105”,“msg”:“Node”,“name”:“nakama”,“version”:“2.13.0+ec8f5d70”,“runtime”:“go1.15”,“cpu”:1,“proc”:1}
go version go1.15 linux/amd64
I noticed that in the nakama source code on master https://github.com/heroiclabs/nakama/blob/master/go.mod
that the crypto package version is the same that we’re getting golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9, and not the version that Andrei specified, maybe that’s an update for the next release?
Can I just add that specific version to our mod file after cleaning the cache? Or how do I specify to grab that version? Thanks for the help guys.
I have 3 modules.txt files, one in the nakama-common 1.7.3 package that doesn’t specify the crypto package, and 2 others in go installation.
/usr/local/go/src/cmd/vendor/modules.txt
/usr/local/go/src/vendor/modules.txt
The both have the crypto package with the mismatched version, but commented out:
GNU nano 4.8 /usr/local/go/src/vendor/modules.txt
@oscargoldman The master branch of the server is always ahead of the official releases. You should look at the specific release tag as @zyro showed to determine the dependencies within that release:
what’s the best way to correct the version? Thanks again.
There’s some other posts on the forum on how to pin transitive dependencies which are different due to minimal version selection. The shortest answer I can give is to create a blank import in your main.go file which specifies the dependency you want to pin:
import (
_ "golang.org/x/crypto/pbkdf2"
)
This way you can control the dependency version in your modfile.
I also noticed that the go.mod file in nakama-commomn@v1.7.3 specifies go 1.13, not sure if that’s related or not.
No that’s not relevant. The version information in the modfile simply indicates what version of the Go toolchain was used to create the file it does not indicate the minimum required version of the Go toolchain to perform builds. It’s a source of confusion with Go developers but that version info in the modfile is mostly useless.
Thanks Chris for the help. When you say main.go file, you’re referring to the go source code we’re trying to compile into a shared object? I’ve added the import as you suggested, and now when I build I see that the crypto package is added to the imports in the mod file, only it’s still the wrong version. If I change the version to the required version Andrei specified, it is just reverted each time.
I tried adding the -mod=readonly argument to the build command, but get back
go: updates to go.mod needed, disabled by -mod=readonly
and the build fails. Nothing I do seems to stop the crypto package from being the wrong version v0.0.0-20200622213623-75b288015ac9
OH, I got somewhere. I ran go get golang.org/x/crypto@v0.0.0-20200323165209-0ec3e9974c59
and that seems to have resolved the issue with the pbkdf2 version. now I’m seeing a similar error related to the x/text/transfrom package.
I checked the text package for the 2.13 release and it needs v0.3.2 and for reasons I don’t understand I was getting version v.0.3.3. I ran go get for that version, changed the mod file, and it’s working!