Windows loader uses dynamic MSVCRT by default

[gboccone-qcom]

The comments on line 220-221 say one thing but this line is doing something else:

Edit: I've read the comment again, it seems to be fine, probably a misunderstanding on my side. However the default build behavior has changed, and we are using a dynamic MSVCRT for the static build. I don't know if this is the right thing to do. Changing the following line from AND NOT to OR NOT fixed my issue but it's probably the wrong approach.

OpenXR-SDK-Source/src/loader/CMakeLists.txt

Line 208 in 33c4600

if(DYNAMIC_LOADER AND NOT (CMAKE_SYSTEM_NAME STREQUAL "WindowsStore"))

[rpavlik]

Yes, that's why this release hasn't been announced yet, having the .def inside that condition is breaking UWP builds, I have a hotfix pending for it. It shouldn't change the default behavior, though...

For whatever reason, I understood the old and current behavior to be:

• UWP: Always dynamic msvcrt
• regular windows, loader DLL: Static crt
• regular windows, loader .lib (static library): dynamic crt

I do not know why exactly this is the way but I think that the Microsoft people were the ones who recommended it.

[gboccone-qcom]

I see. In my case, I was using the default static lib build, but I could link my application with static loader and static crt.

Now I get an error when I try to link because the loader requires the dynamic crt and the application is configured to use static.

It's not just default, it's the only option available.

[rpavlik-bot]

An issue (number 2159) has been filed to correspond to this issue in the internal Khronos GitLab (Khronos members only: KHR:openxr/openxr#2159 ), to facilitate working group processes.

This GitHub issue will continue to be the main site of discussion.