Re: [Mingw-w64-public] gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library

["Martin Storsjö" <martin@martin.st>]

[-- Attachment #1: Type: text/plain, Size: 3207 bytes --]

On Sun, 20 Nov 2022, Pali Rohár wrote:

> Hello! I would like to propose a new parameter for gcc: -mcrtdll= to
> allow specifying against which Windows C Runtime library should be
> binary linked. On Windows there are more crt libraries and currently gcc
> links to libmsvcrt.a which is in most cases symlink to libmsvcrt-os.a
> (but can be changed, e.g. during mingw-w64 building). mingw-w64 project
> already builds import .a library for every crt dll library (from the old
> crtdll.dll up to the new ucrtbase.dll), so it is ready for usage. Simple
> patch for gcc which implements -mcrtdll parameter is below. Note that on
> internet are other very similar patches for -mcrtdll= parameters and
> some are parts of custom mingw32 / mingw-w64 gcc builds. What do you
> think? Could gcc have "official" support for -mcrtdll= parameter?

I think it would be important to add as context here:

The fact that you can use a different CRT DLL isn't controversial here - 
mingw-w64 has had that option since 2017. As LIU Hao pointed out, the 
common way of doing that is by configuring the default with 
--with-default-msvcrt= in mingw-w64-headers and mingw-w64-crt.

The reason for this, is that the only entirely robust way of switching 
from one CRT to another (especially between the msvcr* and UCRT) is by 
rebuilding the toolchain (including all toolchain bundled runtime 
libraries such as libgcc and libstdc++) from scratch with the desired 
default, since there are some subtle ABI differences at various points.

Earlier, there were bigger differences (e.g. for UCRT, most stdio 
functions were defined inline in headers, expanding to calls to e.g. 
__stdio_common_vfprintf), while things have been unified a bit more.

For most C executables, switching to a non-default CRT probably is safe as 
long as all user code is compiled with the right, consistent 
__MSVCRT_VERSION__/_UCRT defines, and runtime libraries (libgcc or 
compiler-rt builtins) are linked statically.

For C++ code, I'm fairly sure that both libstdc++ and libc++ contain 
references to things that differ between msvcr* and UCRT.

While some differences between the CRT choices have vanished (moved into 
the CRT import libraries), there are some remaining differences that 
fundamentally are hard to get rid of.


With Clang/LLD, it's possible to manually experiment with linking a 
different CRT - you need to manually set the right -D__MSVCRT_VERSION__ / 
-D_UCRT, and manually pass -lmsvcr* or -lucrt; whenever an option that 
matches -lmsvcr*, -lucrt* or -lcrtdll is detected, Clang omits the default 
-lmsvcrt.

I don't oppose adding an option like this to GCC (and having such an 
option does help experimenting with reducing the differences) - but it 
does need to come with a pretty stern disclaimer, warning the user that 
they're pretty much on their own if they use it, and that it only really 
fully works as desired under some specific circumstances.

As a technical detail to the patch, you could add ucrtbase as a separate 
alternative to ucrt too. With the ucrtbase import library, the executable 
links directly against the ucrtbase.dll library instead of using the 
api-ms-win-crt-* frontend libraries.

// Martin