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