KhronosGroup
openxr_loader dll name on Windows
Hello!
There is currently an openxr PR active at libsdl-org/SDL adding openxr support.
It has support for loading openxr dynamically using LoadLibrary on Windows and dlopen on other platforms (instead of linking against the library).
However, on Windows the name of the shared library is slightly different when building a debug binary. This happens here.
Clearly, openxr_loader.dll (without d suffix) is the preferred name, but there is concern (vcpkg) package users will get non-functioning openxr SDL support because of this.
The suffix is configurable, but package maintainers are often hesitant to change default: developers have them for a reason.
Is the d suffix still required?
Current CMake Visual Studio generators put the various configurations in different folders.
Mixing DLLs built with the two different C runtimes is very prone to issues on Windows, which is why libraries tend to decorate their debug DLLs accordingly. I have not tested mixing a debug openxr_loader with a release (or relwithdebinfo) application, I simply assumed it did not work.
I have not tested mixing a debug openxr_loader with a release (or relwithdebinfo) application, I simply assumed it did not work.
I've been mixing and matching them when doing my testing on Windows (my game's Windows builds I cross compile from my linux host as relwithdebinfo [well, the equivalent in my build system], but on my Windows test system I use a re-named debug openxr_loaderd.dll with that build). Given this is all a raw C ABI with no C++ ABI happening, as long as the respective runtimes for both debug/release are installed on the system, it does seem to work correctly.
Mixing C runtimes is only an issue with MSVC. MingW does not have this.
If openxr_loader is built as a shared library and if the openxr API does not expose any libc or stl data types (it does not), then you can happily mix different runtimes. Static libraries are trouble, but I think they can be ignored here.
Also, building with Debug CMake build type does not automatically mean a debug runtime, CMake has MSVC_RUNTIME_LIBRARY)
yes, I'm aware of MSVC_RUNTIME_LIBRARY though it came out after we first released this. There's also if you build the library as static or dynamic, as well as whether you use a static or dynamic C runtime... All this stuff is a mess (but only with MSVC).
Can you just try loading the "d" suffixed one as a fallback if the regular one is missing and you're on Windows? (if it does actually work...)
Yes, the idea is that it only exposes super simple types through a C api is the point, but I am not confident in that to say without testing that it's ok to mix CRT's between the lib and the app.
An issue (number 2444) has been filed to correspond to this issue in the internal Khronos GitLab (Khronos members only: KHR:openxr/openxr#2444 ), to facilitate working group processes.
This GitHub issue will continue to be the main site of discussion.
