How to build gamelift C++ SDK for linux on Windows 10 VS17

Long story short, we want to save our money on server cost and avoid using the windows servers.

I’m on windows 10, and trying to build the gamelift linux servers requirements. I’m also running vs 2017.
When I run the below line in CMD it succeeds fine without errors. However, it’s not actually creating a makefile.


So I can never run the next line


Any suggestions?

I’ve tried these linux build commands in a ubuntu 18.04 build with no luck.
The makefile appears, but running the make command breaks with a bunch of issues (almost as if some other dependencies are missing? Would really love to know what those dependencies are!).
Tried using cygwin on windows.
Even tried using CMAKE GUI for windows.

Maybe I’m missing some dependencies or have the incorrect dependencies?
Bad work flow?
It’s hard to say as the set up documentation is just really lacking on the details regarding dependencies, versions, etc and it appears unreal engine is being abandoned due to amazons preferential treatment since the acquisition of cry engine (lumberyard).

I would really appreciate a clear explanation on what the proper work flow would be to make this build happen, we already have gamelift windows servers in unreal engine 4.21 working in vs17 but we really want to package for linux servers (spot instances are like 5-15x cheaper than windows servers!)

Please don’t leave us other engines hanging!

Some quick responses to your problems:

  1. Will need to look at where these are set to see how to move passed this.

  2. Windows is obviously case insensitive but Linux isn’t, hence issues with case sensitivity. I believe Windows 10 recently added a way to set directories as case sensitive, which may fix this issue.

  3. This is a known issue which requires a local modification, see

Apologies for your frustrating experience here.

Firstly, Gamelift does fully support both Unreal and Unity and we are actively working on new plugins to support the latest version of both engines. Many of our customers are on these engines.

Secondly, while Linux + Spot is the cheapest pricing option, there are considerable savings using Windows Spot instances, which could be a temporary alternative until we can fix your build issues.

As to your build issues, have you looked at the README file in the SDK? It has fairly detailed instructions and lists the key dependencies: Cmake, Protobuf, SIOClient and Boost. The SDK will attempt to fetch and build these so things can break there.

I have not tried building the Linux SDK on windows, typically we use Linux machines for that. I will though ask around if anyone has done this to see if folks have suggestions. The Linux build just needs a version of GCC that supports C++11 so if this is installed, you probably could make it work.

As for Linux SDK on Linux machine, this obviously should work.

Can you provide the list of commands you ran and, what if any errors you are seeing or the final parts of the output? Also which version of gcc is installed on your path?

If you are worried about confidentiality, this can be handled through standard AWS support.

  • We have seen some build failures with locally built CMake linking to system curl/libcurl that doesn’t support https but this is fairly clear in the logs. Just mentioning it incase you see https protocol warnings/errors in the logs.

You could try to add verbose logging to the CMake during building, which may help.

Could you explain a littlbe bit further on all 3 of your points?
Do you mean a fix such as this for 2) ?

For the 3)
The link provided appears to possibly be the incorrect link lol, can you double check that? Thanks again!

Hey pip thanks for the response! It’s not frustrating yet, definitely been a learning experience. We managed to get the .so to build using a vm of ubuntu but are still running into issues when attempting to create a linux server build for gamelift, using vs17 on windows 10.

We get a variety of the below 3 errors mainly.

  1. ‘PLATFORM_WINDOWS’ macros redefined

  2. non-portable path to file “CognitoIdentiyModule.h” and “aws/gamelift/Gameliftclient.h”, specified paths differ in case from file name on disk

  3. array index 101 is past the end of the array

I think you are correct, somehow the SIOclient either is or was breaking when being retrieved.

Again, appreciate the response and definitely would appreciate if anybody could give this sort of setup a chance and document how they did it.

The main goal is to use visual studio 17 on windows with UE 4.21 to build linux servers for gamelift which will be used for packaged window games.

If I could provide a suggestion, the above set up would be the most ideal and up to date set of instructions for a decent amount of gamelift/UE/windows customers, and possibly settle a lot of gamelift questions for the next next while :wink: )

I faced the same issue as you but I fixed it live on Twitch with a bunch of fellas helping me with Linux commands and telling me what to install:

I used the Ubuntu app from the Microsoft Store. And these commands were important:

apt update
apt upgrade
apt install cmake
apt install make
apt install essentials (or something like this. I have in in the twitch video. This fixed the last errors)

I tried using Docker before this but ran into permission issues so I recommend the other approach

I was able to finally build the .so binary and placed it in the ServerSDK plugin directory.


Also, @dodi, considering that you and I are both facing this similar issue and are both UE4 developers using GameLift, do you want to help each other out over voice chat or something in my Discord server? We can probably solve these problems quick.

I managed to build the binaries. However, I can’t seem to build the UE4 dedicated server for Linux :confused: I’ve ran into two errors that’s preventing me from finishing building the Linux server.

    C:/UnrealEngineSourceBuild/Engine/Source/Runtime/Core/Public/Serialization/BufferWriter.h(11,10): error: non-portable path to file '"logging/LogMacros.h"'; specified path differs in case from file name on disk [-Werror,-Wnonportable-include-path]
#include "Logging/LogMacros.h"
In file included from C:/Genesis/Krieg 4.20/Plugins/GameLiftClientSDK/Intermediate/Build/Linux/B4D820EA/KriegServer/Shipping/AWSCore/Module.AWSCore.cpp:2:
In file included from C:\Genesis\Krieg 4.20\Plugins\GameLiftClientSDK\Source\AWSCore\Private\AWSCoreModule.cpp:1:
In file included from C:/Genesis/Krieg 4.20/Plugins/GameLiftClientSDK/Source/AWSCore/Private/AWSCoreModulePrivatePCH.h:1:
In file included from C:/UnrealEngineSourceBuild/Engine/Source/Runtime/Engine/Public\Engine.h:337:
C:/UnrealEngineSourceBuild/Engine/Source/Runtime/Slate/Public\SlateBasics.h(11,10): error: non-portable path to file '"json.h"'; specified path differs in case from file name on disk [-Werror,-Wnonportable-include-path]
#include "Json.h"

I then ran into your “array index 101 is past the end of the array” error which I fixed by going to “YourUE4Game\Plugins\GameLiftServerSDK\Source\GameLiftServerSDK\Public\aws\gamelift\server\model\AttributeValue.h” and changed lines 320 and 309 to “m_key[MAX_STRING_LENGTH - 1] = ‘\0’;”

I’m currently getting your "non-portable path to file " errors too. I don’t have your “PLATFORM_WINDOWS’ macros redefined” error but I did have “-fdeclspec” errors which I fixed by adding in that command to the build command.


Did you manage to fix the “non-portable path to file” errors by using I’ll be taking a look at it this evening.

Thanks @SyedAman, that did the trick for the array issue.

Still running into the other issues so I’m to create a support ticket and hopefully get the rest of these issues fixed.

Sorry for digging up the thread. But did you guys successfully built linux-base UE Server?

I’m considering it as an option here, as window server are way too pricey…

I’m stucked at “error:: unable to find library -laws-cpp-sdk-gamelift-server” etc.

Can someone please help upload the GameLift lib for linux? I don’t have Linux nor do I want to VM it just for this. (Honestly, Gamelift staff could also just give us the built library (Window+Linux) instead of having us building it ourselves. Would save tons of problem…)