mstorsjo wrote: > This implements the mingw `-mcrtdll` option recently added to gcc. This > option is useful for having the compiler be in charge of crt version > selection while only shipping a single copy of mingw for a multi-ABI > toolchain. That said, there are various ABI dependent compiler libraries > (e.g. libstdc++), so a certain degree of ABI awareness is nevertheless > required in order to use this option correctly.
Indeed - any precompiled static libraries are a problem. (And also shared libraries, if passing CRT resources over the DLL boundary, e.g. mallocing in one DLL and freeing in another.) Between the various msvcr* libraries, the difference in ABI is usually quite small (if any difference at all), but there are some notable ABI differences between object files between UCRT and msvcrt. The difference used to be bigger; if you'd have an object file calling e.g. printf, built for UCRT but linked against msvcrt, or vice versa, you'd have linker failures right away. Many of such differences have been removed in mingw-w64 these days though, which may give a stronger sense that this really is working - but there are devious ABI differences in e.g. `struct threadlocaleinfostruct`, which is accessed directly from many `ctype.h` macros. So in practice, using a non-default CRT is generally not a safe thing to do (and it kinda remains impossible due to such ABI differences). It's probably safe if linking a pure C executable, with compiler-rt builtins. It's also probably safe if linking a C executable with a static libgcc, assuming that none of the bits of libgcc that gets pulled in there have ABI variability. If linking a shared libgcc (which usually is the default on GCC iirc), I'm not confident in saying whether it is safe or not. If involving libstdc++ or libc++, then it's quite certainly not safe. That's why I haven't really been in favour of adding this option to GCC in the first place (even if it makes things much nicer and more convenient for experimenting with switching between CRT implementations - which I do myself to ease some testing; in that case with just C executables and compiler-rt builtins). But when that patch to GCC was proposed, I at least opted for it to come with a disclaimer that this really isn't safe in general, see the last couple of sentences at https://gcc.gnu.org/onlinedocs/gcc/Cygwin-and-MinGW-Options.html#index-mcrtdll. So while I wasn't keen on adding this in the first place, it does exist in GCC, so having feature parity is of course good, so I won't object to adding it here either. But I do think it needs to come with some sort of disclaimer, just like in GCC. Because having one single toolchain, and being able to switch between targeting msvcrt and UCRT - which is the main thing people would want to do - really isn't safe to do unless you're aware of the exact limitations of what you can and can't do with it. (I presume you're intending to use it in Julia somewhere, and that may very well be safe enough though.) https://github.com/llvm/llvm-project/pull/149469 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
