Jake-Shadle
Failed to find DirectML.lib and PathCch.lib due to case insensitivity
Targeting x86_64-pc-windows-msvc on ubuntu, linking failed with the error:
= note: lld: error: could not open 'DirectML.lib': No such file or directory
lld: error: could not open 'PathCch.lib': No such file or directory
I noticed that directml.lib and pathcch.lib were both there in my .xwin/sdk/lib/um/x86_64 directory. I copied them over to the case-sensitive version that the linker was looking for, and then it worked fine.
It seems like xwin is typically supposed to solve this automatically. I suspect this might be related to my use of the ort library, which as part of its build process, downloads a prebuilt binary from Microsoft. ( https://docs.rs/ort/latest/ort/#how-to-get-binaries ) I'm just guessing, but maybe these dependencies aren't picked up by xwin automatically like most dependencies?
Anyway, it would be nice if there was some way to fix this, other than manually copying these files as part of the build process. Like if you could manually specify a .lib dependency that was needed, or perhaps my guess is wrong and the problem is something else entirely.
xwin generates symlinks to fix casing issues, where the symlinks point to the original casing of the file. Both directml.lib and pathcch.lib use all lower case, and the only symlink generated is a SCREAMING version since that's the only other common kind of reference. I thought maybe these were referenced by that casing with #pragma comment(lib in the SDK, but they aren't, so there is no way internally in the SDK to determine the casing, other than seeing that there happen to be headers with that casing, but that seems brittle and too expansive.
The easiest thing to do is just...fix their library.
https://github.com/pykeio/ort/blob/87dc4f21fa91ceac8393a7034522c5ebccf69437/ort-sys/build.rs#L148
That is where they reference directml.lib by the invalid casing, but I don't know where the pathcch reference comes from.
I see. So ort is a wrapper that uses prebuilt copies of Microsoft's onnxruntime, and onnxruntime has the CamelCase references in a number of places:
https://github.com/microsoft/onnxruntime/blob/1e5bda88f034b2e50055c9ab251b150e4fae9f8a/onnxruntime/core/platform/path_lib.cc#L22
https://github.com/microsoft/onnxruntime/blob/1e5bda88f034b2e50055c9ab251b150e4fae9f8a/cmake/onnxruntime_providers_dml.cmake#L40
To me, if xwin is already generating various screaming symlinks, the easiest thing would be to symlink these up as well, but I can understand if you did not want to just constantly add more symlinks.
I've previously thought about adding a way for users to specify symlinks but it's never been worth it to take the time. I think in this case I still would say the easiest thing to do is to send PRs to that library to fix the casing to match the SDK, as then it will fix it for everyone who cross compiles on a case sensitive file system, not just xwin users.