find_visual_studio_and_windows_sdk() now returns the newest available version of Visual Studio instead of the first found

[lilulo]

I have three versions of Visual Studio on my machine 2017, 2019 and 2022. The latest version of Odin dev-2024-08-nightly:8359995 was failing to build the simplest "hello world" program giving an error:

libucrt.lib(checkcfg.obj) : error LNK2001: unresolved external symbol guard_check_icall$fo$ C:/Dev/Odin/dev/odin1.exe : fatal error LNK1120: 1 unresolved externals

-print-linker-flags was showing following: /LIBPATH:"C:/Program Files (x86)/Windows Kits/10/Lib/10.0.26100.0/um/x64" /LIBPATH:"C:/Program Files (x86)/Windows Kits/10/Lib/10.0.26100.0/ucrt/x64" /LIBPATH:"C:/Program Files (x86)/Microsoft Visual Studio/2017/Professional/VC/Tools/MSVC/14.16.27023/lib/x64" /ENTRY:mainCRTStartup /defaultlib:libcmt /NOIMPLIB /NOEXP /incremental:no /opt:ref /nologo /subsystem:CONSOLE /machine:x64 "kernel32.lib"

Which is obviously picking the oldest version of Visual Studio. Inspecting the code I found that it returns the first Visual Studio that comes out of version enumeration. This fix is finding the newest version of Visual Studio instead and it fixed my linking problem.

I'm not sure if this is the right fix for linking problem I mentioned, maybe it should work with VS2017 in the first place.

[gingerBill]

So this fix doesn't fix the underlying problem. It should work with VS2017 in the first place, and that a linking error is happening suggests something else is going on. It might be a trivial linking problem rather than anything to do with the windows sdk nonsense.

[JesseRMeyer]

On Discord we established that building with -lld works, so it has to do with link.exe and Microsoft's SDK. A quick google reveals that since May of this year, other folks have encountered similar problems, which coincides with the May SDK update.

[lilulo]

Yeah, looks like a MS toolset problem: https://developercommunity.visualstudio.com/t/unresolved-external-symbol-guard_check/10683636?sort=newest

[Kelimion]

Yeah, looks like a MS toolset problem: https://developercommunity.visualstudio.com/t/unresolved-external-symbol-guard_check/10683636?sort=newest

So according to that, MDd fixes it?

Is that the case for you, because the default build.bat compile is debug mode, which uses -MDd.

if %release_mode% EQU 0 ( rem Debug
	set compiler_flags=%compiler_flags% -Od -MDd -Z7
) else ( rem Release
	set compiler_flags=%compiler_flags% -O2 -MT -Z7
	set compiler_defines=%compiler_defines% -DNO_ARRAY_BOUNDS_CHECK
)

[lilulo]

I do build in Debug mode, so according to this post it should link, but it doesn't. I think there should be no difference in linker's error between /MT and /MD because these are static vs dynamic versions of the same library. (edit) Also, this is linker's option for building Odin itself, shouldn't affect how Odin links executables it builds. (edit 2) Clarification - Odin compiler itself, builds without problems. It is programs that Odin compiler builds has it.