Go plugin build error with protobuf

Using minimal example
Using DockerBuild in Windowsx64
Builded using these commands:
*PS C:\Users\Administrator\plugin_code> go get -u “github.com/heroiclabs/nakama-common” *

  • PS C:\Users\Administrator\plugin_code> docker run --rm -w “/builder” -v “${PWD}:/builder” heroiclabs/nakama-pluginbuilder:2.11.1 build -buildmode=plugin -trimpath -o ./modules/plugin_code.so*
  • go: downloading heroiclabs/nakama-common v1.4.0*
  • go: downloading protobuf v1.3.4*

Error:

“}
nakama | {“level”:“fatal”,“ts”:“2020-04-12T06:12:13.539Z”,“msg”:“Failed initializing runtime modules”,“error”:“plugin.Open(”/nakama/data/modules/plugin_code”): plugin was built with a different version of package github.com/golang/protobuf/proto",“stacktrace”:"main.main\n\tmain.go:132\nruntime.main\n\truntime/proc.go:203"}

Nakama version : 2.11.1
i had to remove github site from some errors because forums doesnt allow me to post links.

@irajsb The Nakama v2.11.1 release requires the protobuf v1.3.5 release. You can setup your dependencies to match like so:

env GO111MODULE=on go get "github.com/heroiclabs/nakama-common@v1.4.0"
env GO111MODULE=on go get "github.com/golang/protobuf@v1.3.5"
env GO111MODULE=on go mod edit -replace "github.com/golang/protobuf=github.com/golang/protobuf@v1.3.5"

Please try that and let me know if it resolves your issue. Your mod file should look somewhat like:

module games/project

go 1.14

require (
	github.com/golang/protobuf v1.3.5 // indirect
	github.com/heroiclabs/nakama-common v1.4.0
)

replace github.com/golang/protobuf => github.com/golang/protobuf v1.3.5

The replace is used to force the version if another dependency you use tries to specify a different transitive version.

Worked like a charm !!thanks!

1 Like

Didnt want to create another thread for this : is it possible to get client ip addres from a request with signature like this :
func RegisterServer(ctx context.Context, logger runtime.Logger, db *sql.DB, nk runtime.NakamaModule, payload string) (string, error)

This is not related to the current topic, so it should have been a new thread.

Have a look at the documentation for fields available in the context here, one of them is the caller’s IP address.

I think @zyro is right but this is some quick code to show what you need in Go.

clientIP, ok := ctx.Value(runtime.RUNTIME_CTX_CLIENT_IP).(string)
if !ok {
    // handle error
}

Sorry to bring back an old thread, but this still seems to be an issue.

Running through the quickstart guide, with no prior usage of Go on our systems, we get to a point where protobuf-1.3.4 is listed rather than protobuf-1.3.5. We were able to build our module using the docker image you provide, however, this won’t run within Nakama server due to the incompatibility.

We were only able to solve this by finding this thread and fetching the new protobuf version. We note that some Nakama repos are still using protobuf-1.3.4, is that where the incorrect version is coming from?

Should the quickstart guide be updated to ensure the correct dependencies are installed?

@kburgin As you’ll see from the Nakama 2.11.1 module definitions the issue you’re describing is already resolved. I’d recommend updating to 2.12.0 if at all possible, it’s best to stay up to date with server releases.

Can you point me to the quickstart section that still mentions protobuf-1.3.4, or submit a Pull Request to the documentation repository to fix it?

We were already using the fixed 2.11.1 image, so I think the issue is caused elsewhere.

It would seem the plugin sample is where it goes wrong: https://github.com/heroiclabs/nakama/blob/master/sample_go_module/README.md

In here it tells you to use nakama-common:1.4.0, which still had proto:1.3.4 as you can see here: https://github.com/heroiclabs/nakama-common/blob/v1.4.0/go.mod

This obviously doesn’t fit with the rest of the environment, which all reference proto:1.3.5 as you say.

I’m not sure how you want to approach the plugin docs, whether to point at nakama-common:1.7.2 or maybe there’s a reason it’s pointing to an older version?

@kburgin Each release of the game server uses a specific release of the nakama-common Go package because the common package provides the interface for custom server logic implemented in plugin code. They must be binary compatible. You can see which release of Nakama uses which release of the nakama-common package in the release notes on GitHub.

The protobuf dependency is a direct dependency of the nakama-common Go package so it must match. We ensure that the server release uses the same version of protobuf as the nakama-common dependency defines. This prevents “minimal version selection” in Go modules from attempting to use a different version of the Protobuf runtime.

Hope that helps.

Ah I see. There just seems to be a bit of a mismatch around 2.11.1 if you look at the releases. 2.11.0 and 2.11.1 both seem to need nakama-common:1.4.0 yet 2.11.0 and 2.11.1 use different proto versions which makes that not possible.

If we run 2.12.0 and 1.5.1, then it’s all fine.

There are just quite a few sporadic references to the old versions which don’t match up. For example, the sample plugin references heroiclabs/nakama-pluginbuilder:2.11.1 and then heroiclabs/nakama-common@v1.4.0 which seems like it’s going to cause issues (and did for us) when we tried to run this with the sample docker-compose file in the quick start that lists heroiclabs/nakama:2.11.1.

Just needs a few version numbers matching up by the looks of it.

Probably the best way to find all dependencies you need to match with is the vendor/modules.txt for your chosen server release. For Nakama 2.11.1 that’s here. It effectively contains the dependency versions selected by the Go toolchain for the server build at the time of the release. Note that this is just a useful tool, as @novabyte pointed out there’s more to Go dependency version selection than that.

We can’t necessarily document the latest version every time. There will be new versions of nakama-common for example that are not yet used in a Nakama server release, and should not be documented as dependencies at those version numbers.

1 Like

Thanks for your Reply.I have build code successfully and running fine.

Regards,
Rajesh