On Mon, 24 Nov 2025, Kirill Makurin wrote:
However, it seems that clang's -lwindowsapp handling works only with
lld. I tried linking a simple executable with `clang -lwindowsapp`
(installed from Msys2/UCRT64, which uses GNU ld unless -fuse-ld=lld is
used) and I got undefined references to Windows API functions.
AFAIK, lld unlike GNU ld can resolve references to libraries that have
been passed earlier on the command line, I think it has to do with
-lwindowsapp not following mingw-w64's -l flags when clang invokes ld.
Yes, that sounds about right.
It's possible to make it work by manually passing e.g. "-lwindowsapp
-lmsvcrt -lmingwex -lwindowsapp" or something like that, repeating the
same library multiple times (like the built-in defaults do), but that's
also quite inelegant. Given how uncommon it is to target UWP, and how it
works fine when using lld, I haven't spent more time on improving the
situation.
There's a recent fix for the handling of CRT parameters, see
https://github.com/llvm/llvm-project/commit/7f470586e10543aa12efc7e04d4d4ac814eaca35.
The same logic could be applied to -lwindowsapp as well, making the
compiler insert that option at the same place where -lkernel32 and the
others would have been.
If I understood correctly, Pali wants to propose a new option to gcc,
-msysdll=, which would allow to replace library that follows mingw-w64's
-l flags. This would not only allow using -lwindowsapp in that place,
but also import libraries like -lonecore.
I think that might be reasonable, but I haven't thought it through fully.
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
