UE 5.8 fails to compile with Visual Studio 2026 (hash_map missing) — Source fix

[Drakgoku]

Summary

1>  Result: Failed (OtherCompilationError)
1>  Total execution time: 33797.48 seconds
1>  Trace written to file E:\UnrealEngine\Engine\Programs\UnrealBuildTool\Trace.uba with size 5.0mb
1>C:\Program Files\Microsoft Visual Studio\18\Community\MSBuild\Microsoft\VC\v180\Microsoft.MakeFile.Targets(44,5): error MSB3073: The command "..\..\Build\BatchFiles\Build.bat -Target="UnrealEditor Win64 Development" -Target="ShaderCompileWorker Win64 Development -Quiet" -WaitMutex -FromMsBuild -architecture=x64" exited with code 6.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
========== Build completed at 12:12 PM and took 09:23:28.886 hours ==========

Summary

1>E:\UnrealEngine\Engine\Source\ThirdParty\nvtesslib\inc\nvtess.h(154,1): fatal error C1083: Cannot open include file: 'hash_map': No such file or directory
1>  #include <hash_map>

I’m compiling an Unreal Engine 5.8 source code using Visual Studio 2026. After compiling for a few hours, I’m getting the following error:

E:\UnrealEngine\Engine\Source\ThirdParty\nvtesslib\inc\nvtess.h(154,1): fatal error C1083: Cannot open include file: 'hash_map': No such file or directory
#include <hash_map>

Is UE 5.8 expected to be compatible with Visual Studio 2026, or is this a compatibility issue with nvtesslib?

My vs 2026 config:

Summary

Epic is asking me for MSVC:

Preferred: 14.50.35717
Current: 14.51.36248

I cannot select another one since it comes by default.

[Drakgoku]

There’s nothing like editing the engine, right guys?

Imagine having to come and see what you’re doing…

Summary

#if USE_HASHMAP
#if PLATFORM_MAC || PLATFORM_LINUX
#include <unordered_map>
#include <vector>
#else
#include <hash_map>
#endif
#else
#include <map>
#endif

Summary

#elif USE_HASHMAP
		typedef stdext::hash_map<Edge, Edge> EdgeDict;
		typedef stdext::hash_map<nv::Vector3, Corner> PositionDict;

With MSVC 14.51, it seems that <hash_map> is no longer available (or at least not where that code expects to find it). It seems that this code hasn’t been updated when the compiler changed.

I’m getting rid of the platform-specific code like #if PLATFORM_MAC || PLATFORM_LINUX, which I understand was for legacy systems, and if not, then to keep it.

Changed:

Summary

#if USE_HASHMAP
#include <unordered_map>
#include <vector>
#else
#include <map>
#endif

Summary

#elif USE_HASHMAP
		typedef std::unordered_map<Edge, Edge> EdgeDict;
		typedef std::unordered_map<nv::Vector3, Corner> PositionDict;

I’m getting a bit tired of having to look up every little thing for the new version. If you’re going to set a version that’s compatible with “VS 2026,” one bad synchronization with Microsoft and you’ll leave us developers out of the game. Please, a little more professionalism.

I can’t be keeping track of every existing library you remove or don’t remove. It really annoys me.

What are we waiting for?

Unreal Engine should keep a closer eye on the MSVC versions used by Visual Studio. Unreal Engine is built in close conjunction with Visual Studio and Microsoft libraries. It is advisable to check for the latest versions available in Visual Studio whenever a new release is made, in order to avoid compatibility issues.

You’re welcome, regards.

[Braedy_NightDive]

For what it’s worth, I pushed this up into the epicsupport forum where there’s usually better responses from Epic staff.

I’m about 50/50 on responsibility here. MSVC removed it hash_map without “warning” (it was there and then it wasn’t) but also it’s apparently been deprecated for nearly a decade, so committing new code depending on it was flat out ignoring a warning. That being said, you can see when compiling (it’s even in your logs) that MSVC 14.51 has very clearly not been tested for compiling Unreal. I don’t think this one would’ve slipped by them if they’d tried it.

[Drakgoku]

I agree this is partly due to the MSVC change, but <hash_map> has been deprecated for many years, so relying on it in UE 5.8 seems unnecessary. Since replacing it with std::unordered_map resolves the issue with only minimal changes and without affecting functionality, it would be better to update this legacy code than require developers to use an older compiler version. Given how small the change is, it seems like a worthwhile improvement to keep Unreal compatible with future MSVC releases.

[Drakgoku]

We can manually install MSVC version 14.50 if necessary.

But relying on an older version to compile when the change is minor is a short-term fix that will lead to long-term problems.

[Braedy_NightDive]

Not just worthwhile: necessary. Something like Unreal can’t stop the inevitable forward progress of the compiler, or rather a project as active as Unreal won’t lock a compiler version. There’s no doubt in my mind that this will be resolved. I don’t think this code has been reviewed in a while. Probably easy to overlook a vendor library that’s been “working” until now. Frankly, the file needs a lot of reworking. The choices between the custom implementation and the hash_map extension made sense when you could be on a platform that didn’t offer the extension. The extra choice between using the ordered map (that wasn’t really a choice, given the hardcoded define) made less sense and seems more like an unwillingness to profile and know what the right choice is.

[Svegn2 (Martin Sevigny)]

Hello!

We recommend using the 14.44 (VS2022) or 14.50 (VS2026) toolsets with version 5.8. The information can be sourced from Engine\Config\Windows\Windows_SDK.json.

UnrealBuildTool will try to use one of the PreferredVisualCppVersions or default to the latest version of the toolchain installed if none are available.

As far as the removal of hash_map, we have addressed the problem in the main stream (CL54453441\commit) but our hotfix rules are preventing us from updating version 5.8. Going back to 14.50 is the best workaround as this is the toolset that we used during the mastering phase of version 5.8 and will stick to it unless major security issues are uncovered. We do test our code with the newest and beta toolchain but we also have to settle on a widely available version when we enter our release cycles so we often ship a couple of version behind VS’s latest.

Regards,

Martin