You’re mixing files and use cases quite wildly here. MSVC-style and mingw style environments use different lib naming conventions. You generally shouldn’t be mixing files from such environments with each other unless you really know what you’re getting yourself into.
Bringing up a whole cross compilation environment from scratch is quite a bit of work; if you want to know how to do that for a mingw environment, have a look at the scripts in the llvm-mingw repo, starting e.g. at the toplevel script: https://github.com/mstorsjo/llvm-mingw/blob/5ad257fed02b5c3086eabadb8b482a62254321e6/build-all.sh#L79-L92
If you want to build with MSVC headers and libs, then ignore all of llvm-mingw - don’t mix it in here, it will only confuse you. @tobiashieta’s comment was more of a suggestion for a prepackaged ready solution.
The issue with the MSVC headers and libs is that they aren’t redistributable, so others can’t build a premade package with everything in place and redistribute it publicly.
This is indeed an issue with the WinSDK.
One way to do it, is to run some scripts over the SDK to lowercase all files (and their internal include directives) - the install scripts in GitHub - mstorsjo/msvc-wine: Scripts for setting up and running MSVC in Wine on Linux does this.
Alternatively, when building with Clang, it’s possible to use Clang’s VFS overlay feature to handle the case insensitivity here. See e.g. https://github.com/llvm/llvm-project/blob/15eaefa5fe3608b03f1abefc31129efaf9eab88e/llvm/cmake/platforms/WinMsvc.cmake#L265-L273 for how this is done in the cmake files for building LLVM itself with such a setup.
For linking with lld, I’m not entirely sure if there are the same options available for using a case insensitivity VFS overlay. It looks like the same WinMsvc.cmake above creates a directory of symlinks to do the name mappings: https://github.com/llvm/llvm-project/blob/15eaefa5fe3608b03f1abefc31129efaf9eab88e/llvm/cmake/platforms/WinMsvc.cmake#L288-L296
Alternatively, if you’ve got lowercased files as if installed with msvc-wine above, it’s enough to just add the relevant directories to $INCLUDE and $LIB. I pushed a branch on msvc-wine that includes a script that does this for you: https://github.com/mstorsjo/msvc-wine/blob/env-native/msvcenv-native.sh So with an install from msvc-wine, with an environment set up with the msvcenv-native.sh script, it should be enough to just call clang-cl or clang --target x86_64-windows-msvc and lld-link with any clang/lld build.
It’s quite possible to build Qt for Windows on Linux using llvm-mingw - but it seems like you have somehow intermingled the install of the prepackaged llvm-mingw with your own setup. With llvm-mingw everything you need should be available from the get go without needing to meddle with anything in the toolchain package at all.
If you’ve extracted a release package of llvm-mingw and have added it to your $PATH, then you can build Qt 5.x like this:
./configure -xplatform win32-clang-g++ -device-option CROSS_COMPILE=x86_64-w64-mingw32- -release -opensource -confirm-license -nomake examples -silent -opengl desktop
make -j$(nproc)
For Qt 6.x, the procedure is a bit more complex, as you need to build the native Qt tools manually first:
mkdir build-native
cd build-native
cmake \
-G Ninja \
-DCMAKE_BUILD_TYPE=Release \
-DCMAKE_INSTALL_PREFIX=$(pwd) \
-DQT_BUILD_EXAMPLES=OFF \
-DQT_BUILD_TESTS=OFF \
-DINPUT_opengl=no \
../qtbase
ninja host_tools
QT_HOST_PATH="$(pwd)"
cd ..
mkdir build-cross
cd build-cross
cmake \
-G Ninja \
-DCMAKE_BUILD_TYPE=Release \
-DCMAKE_INSTALL_PREFIX=$(pwd) \
-DCMAKE_CROSSCOMPILING=TRUE \
-DCMAKE_SYSTEM_NAME=Windows \
-DCMAKE_C_COMPILER=x86_64-w64-mingw32-clang \
-DCMAKE_CXX_COMPILER=x86_64-w64-mingw32-clang++ \
-DCMAKE_RC_COMPILER=x86_64-w64-mingw32-windres \
-DQT_QMAKE_TARGET_MKSPEC=win32-clang-g++ \
-DQT_HOST_PATH=$QT_HOST_PATH \
-DQT_BUILD_EXAMPLES=OFF \
-DQT_BUILD_TESTS=OFF \
../qtbase
ninja
I haven’t tried cross compiling Qt with clang in MSVC mode so I can’t help with that.