Confusion around compiling go modules for different platforms

We use nakama on a variety of platforms - developers use windows, we have a test environment running on a mac, and we will eventually run a production environment on linux droplets (until such time that we can afford your managed services).
I understand the recommendation for go module development is to use the docker images along with the docker build tool. But there’s some confusion about how to manage a production environment. Apparently the compiled shared objects for go modules are not transferable from platform to platform? And the recommendation for a production environment is NOT to use Docker, but to use binaries. So how does this then apply to go modules on the production environment - they need to be compiled there?
And for windows, does the docker build tool work, or is it still the case go can’t use the plugin buildmode on windows.

Hi @oscargoldman

developers use windows, we have a test environment running on a mac, and we will eventually run a production environment on linux droplets

This sounds fine we’ve crafted the technology to minimize the amount of infrastructure required to run in various environments so it’s as easy as possible for local development too.

I understand the recommendation for go module development is to use the docker images along with the docker build tool.

This recommendation is in general because it means you don’t need to bother to configure and setup containers with Docker Compose the environment is composed of all the containers needed and are started together.

But there’s some confusion about how to manage a production environment. Apparently the compiled shared objects for go modules are not transferable from platform to platform?

No. Like any compiled language the shared object generated by the Go toolchain is architecture specific. When you use our pluginbuilder Docker image the compiled code on the host filesystem is built for the Linux x64 architecture. You can see this with:

$> file ./your-compiled-module.so
ELF 64-bit LSB shared object x86-64, version 1 (SYSV), dynamically linked

And the recommendation for a production environment is NOT to use Docker, but to use binaries.

This has come up a couple of times recently. There’s no production recommendation not to use Docker images or to suggest that native binaries are the right way. The only strong recommendation is NOT to use Docker Compose to run your server environment.

And for windows, does the docker build tool work, or is it still the case go can’t use the plugin buildmode on windows.

The Go language and compiler toolchain does not support plugins built on Windows. This is a constraint which comes from the Go team. It may change in the future but we’d recommend against Windows for your host OS with production instances anyway.

OK, so it sounds like if I use the docker build tool on a Linux environment, then move to the .so to a linux based VM for production, that should work?

And if compilation for go modules is platform specific, and can’t be build on windows, then go modules simply don’t work on windows using the windows binary?

This is a limitation of the current Go plugin system, it’s only available on Linux and macOS but we support Windows development too by using Docker to run Nakama and building plugins through our pluginbuilder.

one more clarification needed. Are go plugins that are built with the docker build tool, for the same platform, compatible with the nakama binaries? We have the latest linux binary running in our production environment, and compiled our go source code with go 1.13 to a shared object, and moved it to sever, and it doesn’t work.

Just to note, we have successfully build the same go source code, using the docker tool for mac os, running nakama from docker in our dev environment.

As a hail mary, I installed the go 1.13 tool kit on our production server, set GOPATH to our source code folder, did go module init, and go get the nakama common package 1.0.0. The shared object built, but still will not run in the server, we’re still getting the error:
plugin was built with a different version of package internal/cpu
This is using nakama 2.7.0 linux binary.