On Tue Dec 2 23:34:59 2025 +0000, Yuxuan Shui wrote:
There is also a link order issue if we want to support `.CRT` on mingw. `lld` doesn't care about object file orders so it works, but GNU ld does care. Which means `libmsvcrt.a` can't use `__xc_a` etc. from `libwinecrt0.a`. Moving definitions into `dlls/msvcrt/crt_init.c` doesn't work either because `msvcr*.dll` naturally aren't linked with `libmsvcrt.a` (in addition to a few other ones). So I think I need to add a new staticlib specifically for these definitions, and link that staticlib into everything. Yeah, it is one of those mingw annoyances. For compiler driver default libs, mingw works around it by repeating default imports. In my case, GCC uses "-lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -lkernel32 -lpthread -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -lkernel32". Note how mingw32, mingwex, and msvcrt (and a few others) are repeated. That is exactly to allow calls between mingwex and msvcrt.
In Wine, we do not use compiler default libs and specify them ourselves. We have been fine without such tricks so far, but as we extend our CRT, I expect it to become increasingly problematic, so maybe we should just do the same with winecrt0. FWIW, in the broader context of how linkers handle these things, MSVC has yet another behavior, somewhere between binutils and LLD. There are attempts to make LLD more compatible, but it is tricky: https://github.com/llvm/llvm-project/pull/85290. Overall, it is probably a good idea to avoid relying on specific linker behavior in these areas. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9265#note_124540