MinGW build issues

[cshenton]

I'm evaluating netcode for integration with my C VR engine, and am running into issues building client.c and server.c for windows using the mingw ABI.

Using the zig compiler toolchain, I am compiling with:

zig cc client.c netcode.c sodium/*.c -Isodium -lshlwapi -lws2_32 -m64 -o client.exe
zig cc server.c netcode.c sodium/*.c -Isodium -lshlwapi -lws2_32 -m64 -o server.exe

(in a shell that supports * wildcards, such as Git Bash)

This gives me the following error:

netcode.c:186:17: error: conflicting types for 'inet_ntop'
  186 |     const char *inet_ntop(int af, const void *src, char *dst, socklen_t cnt)
      |                 ^
C:\Program Files\zig\lib\libc\include\any-windows-any/ws2tcpip.h:402:35: note: previous declaration is here
  402 | WINSOCK_API_LINKAGE LPCSTR WSAAPI InetNtopA(INT Family, LPCVOID pAddr, LPSTR pStringBuf, size_t StringBufSize);
      |                                   ^
C:\Program Files\zig\lib\libc\include\any-windows-any/ws2tcpip.h:399:19: note: expanded from macro 'InetNtopA'
  399 | #define InetNtopA inet_ntop
      |                   ^
netcode.c:349:9: warning: 'inet_pton' redeclared without 'dllimport' attribute: previous 'dllimport' ignored [-Winconsistent-dllimport]
  349 |     int inet_pton(int af, const char *src, void *dst)
      |         ^
C:\Program Files\zig\lib\libc\include\any-windows-any/ws2tcpip.h:409:32: note: previous declaration is here
  409 | WINSOCK_API_LINKAGE INT WSAAPI InetPtonA(INT Family, LPCSTR pStringBuf, PVOID pAddr);
      |                                ^
C:\Program Files\zig\lib\libc\include\any-windows-any/ws2tcpip.h:406:19: note: expanded from macro 'InetPtonA'
  406 | #define InetPtonA inet_pton
      |                   ^
C:\Program Files\zig\lib\libc\include\any-windows-any/ws2tcpip.h:409:1: note: previous attribute is here
  409 | WINSOCK_API_LINKAGE INT WSAAPI InetPtonA(INT Family, LPCSTR pStringBuf, PVOID pAddr);
      | ^
C:\Program Files\zig\lib\libc\include\any-windows-any/winsock2.h:36:29: note: expanded from macro 'WINSOCK_API_LINKAGE'
   36 | #define WINSOCK_API_LINKAGE     DECLSPEC_IMPORT
      |                                 ^
C:\Program Files\zig\lib\libc\include\any-windows-any/winnt.h:154:37: note: expanded from macro 'DECLSPEC_IMPORT'
  154 | #define DECLSPEC_IMPORT __declspec (dllimport)
      |                                     ^
netcode.c:648:20: warning: result of comparison of constant 18446744073709551615 with expression of type 'netcode_socket_handle_t' (aka 'unsigned int') is always false [-Wtautological-constant-out-of-range-compare]
  648 |     if ( s->handle == INVALID_SOCKET )
      |          ~~~~~~~~~ ^  ~~~~~~~~~~~~~~
2 warnings and 1 error generated.

If I correct socklen_t to size_t the error disappears, and I can build both client and server. However the server crashes upon attempted client connection.

Changes are I've made an error in my compiler config, but since I will plan to integrate this into my own build system, it would be great to understand how to build netcode without the premake build script.

[cshenton]

When running the server and client with the modified inet_ntop prototype, the server gets to here:

[server]
server listening on 127.0.0.1:40000
server started with 256 client slots

Then, launching the client:

[client]
client started on port 51166
client id is fd67ff24bbdb0d0d
client connecting to server 127.0.0.1:40000 [1/1]

The server crashes. Then on the client:

client connect failed. connection request timed out
client disconnected

[cshenton]

This seems to be an issue with the libsodium build. Linking against an official libsodium release works fine.

[cshenton]

I'm going to close this since I think I'd prefer to use an up to date libsodium build alongside netcode anyway. Hopefully this is useful for anyone targeting this ABI who just wants to get the examples running in future.

[gafferongames]

Yes, I think you have made the right choice. In effect, the modified lib sodium build is really only supplied for convenience.

[cshenton]

Sounds good. Do you think that if ( s->handle == INVALID_SOCKET ) is something to be concerned about / worth opening a separate issue for? The handle is 32 bit on windows and is being compared against a ~u64(0).

[gafferongames]

Let me look at the code and think about it

[gafferongames]

OK I think it's' fine. if you truncate ~0 64bit to 32bit, which will be what happens, it is still 0xFFFFFFFF which is correct.

[cshenton]

I believe the behaviour goes the other way. The uint32_t is promoted to a uint64_t and the compiler will optimize the comparison away.

An explicit cast to uint32_t might be necessary: https://godbolt.org/z/Md96Yr6Y4

[gafferongames]

Ah, in that case could you create a PR?

[cshenton]

Will do.