Docs Request: Linking

[wez470]

Hey! Thanks for making this project! I'd like to use it but am having trouble setting it up. It'd be great to have some documentation for the linking steps. I'm definitely more on the noob side of things when it comes to CGO.

Currently I'm trying to get something similar to the example code running on macos. Steps I've done so far.

• Vendored the lib. This resulted in:

ld: warning: directory not found for option '-L/Users/<user>/Projects/network-game/vendor/github.com/nielsAD/gns/lib/GameNetworkingSockets/build/src'
ld: library not found for -lGameNetworkingSockets

• Because go modules does not check out submodules, I manually added lib/GameNetworkingSockets/build/src to the vendored gns dep including a dynamic lib I built from GameNetworkingSockets source (libGameNetworkingSockets.dylib). Now when I run I get:

# github.com/nielsAD/gns
Undefined symbols for architecture x86_64:
  "_SteamAPI_ISteamNetworkingSockets_RunConnectionStatusChangedCallbacks", referenced from:
      __cgo_de1002ec4758_Cfunc_SteamAPI_ISteamNetworkingSockets_RunConnectionStatusChangedCallbacks in _x002.o
     (maybe you meant: __cgo_de1002ec4758_Cfunc_SteamAPI_ISteamNetworkingSockets_RunConnectionStatusChangedCallbacks)
  "_SteamAPI_SteamNetworkingSockets_v008", referenced from:
      __cgo_de1002ec4758_Cfunc_SteamAPI_SteamNetworkingSockets_v008 in _x002.o
     (maybe you meant: __cgo_de1002ec4758_Cfunc_SteamAPI_SteamNetworkingSockets_v008)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

src (master) $ file libGameNetworkingSockets.dylib 
libGameNetworkingSockets.dylib: Mach-O 64-bit dynamically linked shared library x86_64

I was hoping I could get some tips on the proper way to do this stuff (or pointed to resources to follow). I'd be down to also add documentation for this stuff if I can get it figured out.

[charles-d-burton]

So, the reason you're getting that error is Valve updated the library and a whole lot has changed. This whole library needs refactored to fix it. I'm working on it but I don't really have a lot of time to dedicate to it. I think it should be possible to clone the submodule at an older version but I'm not sure which version it should be.

[wez470]

Sorry, I forgot to come back and update here. I do have a workaround for now, but Idk if it pertains exactly as something to add to documentation. Basically, I built the steam lib at the version this lib expects, then stored it in a docker image. When I do a build of my game, I just copy the built lib out of the docker container and store it in the proper spot in my vendored gns lib. It works using dynamic linking atm.

[charles-d-burton]

I found another work-around too if it helps. So I manually did the following

cd $GOPATH/src
mkdir nielsAD
cd nielsAD
git clone https://github.com/nielsAD/gns.git
cd gns/lib/GameNetworkingSockets
mkdir build
cmake -G Ninja ..
ninja

Then in my VSCode terminal I do:

export LD_LIBRARY_PATH=/home/charles/go/src/github.com/neilsAD/gns/lib/GameNetworkingSockets/build/src

Finally I made my go.mod file in my code look like this:

module github.com/charles-d-burton/devnet

go 1.16

require github.com/nielsAD/gns v0.0.0

replace github.com/nielsAD/gns => /home/charles/go/src/github.com/neilsAD/gns

Then when I run go build using the example code.

➜  devnet git:(master) ✗ go build
➜  devnet git:(master) ✗ ./devnet 
Compare(in, out) == true

[charles-d-burton]

It's kinda fugly so I'd love to see how the author does it. Considering the mental overhead it seems like the author should have a more streamlined process somewhere that I'm just not seeing.

[wez470]

Yeah, I'd say this repo is more or less unmaintained so we probably won't find out :). I'm just moving away from it

[charles-d-burton]

Considering the potential here I might pick it up in my fork if I have time. Built in encryption with symmetric keys, good re-assembly handling, and solid fault tolerance to crappy connections is pretty compelling. I'm actually thinking about using it for IoT because of those features. Much faster than websockets and I don't have to deal with TLS and distributing certs, rather I can rely on the encryption then on rollup use auth. Even the P2P bits are pretty useful in IoT.