-
Notifications
You must be signed in to change notification settings - Fork 176
4.27.0 on Windows fails with error C4668: 'WINAPI_PARTITION_GAMES' is not defined as a preprocessor macro, replacing with '0' for '#if/#elif' #192
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Confirming, I've reproduced this. Error:
Now the question is: is it actually specific to ue4-docker? |
Google reveals several hits... https://answers.unrealengine.com/questions/1029719/view.html |
That's interesting: https://github.com/EpicGames/UnrealEngine/commit/ecc4872c3269e75a24adc40734cc8bcc9bbed1ca |
If we closely look at UE-4.27 release notes, we'll see that "IDE Version the Build farm compiles against" says "Windows 10 SDK (10.0.18362.0)". The weird thing is that you cannot install Visual Studio 2017 and Windows 10 SDK 10.0.18362.0 in a single step because the newest Windows SDK that VS2017 channel contains is 10.0.17763.0. So, what we can do here... a. Install newer SDK when using VS2019. |
Regarding compatibility of newer SDKs with older Engine versions, the Windows SDK is supposed to be fully backwards compatible, right? We'd definitely still want to verify that rather than just taking Microsoft's word for it, but in theory it should be safe to use a newer SDK version to build older software. |
What about adding Otherwise, perhaps we can ignore C4668, since in this case, "undefined preprocessor macro evaluates to 0" is the standard and desired behaviour. |
@adamrehn There is a reason why we're using Windows SDK 17763 currently. It is the latest thing that is available through VS2017 channel. We'll have to use VS2019 channel to install newer Windows SDK, while continuing to use VS2017 channel to install all the rest of build tools. I don't even want to think how this works from licensing perspective. Does it mean I now need to have VS2019 license even though the only thing I install through it is available independently with a different license? Anyway, see #193. |
There's not different VS2017 and VS2019 licenses, AFAIK. A VS license covers all versions, and installing anything from the VS Build Tools installer means the user must have such a license. |
Are you sure? I thought having a VS license covers all prior versions. |
... I was sure until you asked that. Thinking about it, I'm on a Visual Studio subscription through my employer, so I always have access to the latest version, and I forgot that box-product licenses for VS are still a thing. You're right, the standalone license doens't include newer versions... Or older versions, accordsing to Pricing Details. |
I believe it has exactly the same wording for VS2017. So, it someone has VS2017-only license, it isn't clear whether it is ok for them to install Windows SDK through VS2019 Build Tools.
|
Created UDN ticker for this issue: https://udn.unrealengine.com/s/question/0D54z000079HcjJCAS/d3d12h427-error-c4668-winapipartitiongames-is-not-defined-as-a-preprocessor-macro-replacing-with-0-for-ifelif If Epics restore pre-18362 Windows SDK compatibility in 4.27.x, I'd suggest doing nothing on our side for now. |
I tried the new version and it works! I can also confirm the new SDK works with unreal 4.26. |
@tibzuru Do you mean you built with changes from #193? |
Well-well-well. 4.20.3 doesn't compile against Windows SDK 18362.
|
So, we no longer have a single Windows SDK that is compatible with all our supported engine versions. |
Indeed. |
Don't worry, we already know that multiple engine versions are fucked up:
|
I've got a response from Epics, but it isn't clear whether 4.27 compatibility with pre-18362 Windows SDK will be restored:
|
Those are all the same problem: It was fixed in 4.23.0 onwards by locally defining that macro's value. Given the date of the change (June 2019), I assume that came out of Epic validating the 18362 SDK, and 4.23 was the first release after that. I had a quick poke around, and it seems this is indeed a bug in the Windows SDK 18362 onwards: A header was copied over from the Driver Development Kit to replace a block of (presumably hand-maintained) parallel definitions for the NDIS API version. However, the header relied on behaviour elsewhere to set some macros including Users of this header from user-space are also required to set a macro, but a different macro, and the replaced code only looked at that macro, not the other possible macros like Annoyingly, a much older (Windows 8) version of the DDK protected these checks with I've no idea why UE4 is pulling in the NDIS driver userspace API. The closest I could find with GitHub searching is the WebRTC library's test suite pulls in Edit: I raised this as a report to MS, as best I could. |
Another update from Epics:
So maybe we just... wait? :D |
Let's collect together what we have:
What we can do: I'm leaning towards option B, given that this is a one-liner that @TBBle linked |
Certainly build-system patches not untrodden ground for this project, so I'd prefer B too from this list. I think it's more maintainable to meet current environment expectations and patch old, unchanging versions, than continuously patch newer versions back to older environments. We could perhaps do D but as a build-system patch (i.e. like B, but setting |
Oh, I forgot one more aspect. We can have different SDKs for VS2017 and VS2019. And this does make sense because newer engines (UE5) already dropped VS2017 support and they will definitely drop SDK 17763 sooner or later. So, option G: use newer SDK for VS2019 ue4-build-prerequisites. Claim that broken 4.27.0 is only supported for VS2019. I think I like this option the most. P.S. VS2019 is supported since 4.25 that already contains a fix for SDK >= 18362. |
I've implemented option G in #195. |
Epics fixed 4.27.x to compile against Windows SDK older than 18362: https://github.com/EpicGames/UnrealEngine/commit/1abe97fc35ff45f2138419469faf9e85f1057930 |
Output of the
ue4-docker info
command:Additional details:
Hello, I am having issues building the newest UE 4.27 using the latest ue4-docker (0.0.88).
At first I thought it was due to the custom UE version we use in the company, but I have also tried to build the not customized version from epic and the issue persists. Building the engine using the
ue4 build-target UE4Editor
works on both native OS and windows containers.Linux image builds just fine.
Previous UE images build just fine.
Older ue4-docker versions (tested 0.0.77 and 0.0.86) have the same issue.
I am able to reproduce the issue on any windows server machine by running:
Thanks in advance
The text was updated successfully, but these errors were encountered: