[llvm-dev] gcc mcrt option

Martin Storsjö via llvm-dev llvm-dev at lists.llvm.org
Tue May 18 01:17:49 PDT 2021


Hi,

On Tue, 18 May 2021, René W. Olsen via llvm-dev wrote:

> With GCC you can select C Library with the option -mcrt=xxx
> 
> how would/should I implement this?

I presume that you mean for MinGW targets - and mean the option -mcrtdll= 
option?

That option doesn't exist in proper upstream GCC, but is only carried 
around in an MSYS specific patch in 
https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-gcc/0006-Windows-New-feature-to-allow-overriding.patch

(Grepping the gcc tree for "mcrt" doesn't pick up on anything else that 
seems relevant.)

With clang, this can be handled by just passing -l<crt>, which makes clang 
drop the implicit -lmsvcrt argument - see https://reviews.llvm.org/D37530 
where this was implemented. (This works fine when using ld.lld for 
linking, where library order matters less than with ld.bfd; with ld.bfd 
you might need to specify libraries multiple times.)

Switching this way between e.g. -lmsvcr and -lmsvcr120 or such might work 
pretty fine, but if your intent is that you want to switch between 
msvcrt.dll and UCRT, there are more complications. msvcrt.dll and UCRT 
aren't binary compatible on the linking/object file level, e.g. some 
structures have different sets of members and different layouts. So any 
object files/static libraries that you are going to link must have been 
built against headers configured in a matching way.

So in practice, with clang/compiler-rt and ld.lld, you can switch between 
CRTs when you build plain C executables that don't link to anything else, 
but when you bring in the C++ standard library, that one pretty much has 
to be linked against the default used for the toolchain.

So in practice, the defacto way of switching between CRTs in mingw-w64 is 
to reconfigure the toolchain from the ground up with a different default, 
set with the --with-default-msvcrt=ucrt option.

Within MSYS2, there's a new package root named "ucrt64", where all tools 
and packages are built this way.

// Martin


More information about the llvm-dev mailing list