From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail8.parnet.fi (mail8.parnet.fi [77.234.108.134]) by sourceware.org (Postfix) with ESMTPS id E40AA3858D28 for ; Sun, 20 Nov 2022 21:22:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E40AA3858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=martin.st Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=martin.st Received: from mail9.parnet.fi (mail9.parnet.fi [77.234.108.21]) by mail8.parnet.fi with ESMTP id 2AKLM0RN000440-2AKLM0RO000440; Sun, 20 Nov 2022 23:22:00 +0200 Received: from foo.martin.st (host-97-187.parnet.fi [77.234.97.187]) by mail9.parnet.fi (Postfix) with ESMTPS id 64404A1469; Sun, 20 Nov 2022 23:22:00 +0200 (EET) Date: Sun, 20 Nov 2022 23:22:00 +0200 (EET) From: =?ISO-8859-15?Q?Martin_Storsj=F6?= To: mingw-w64-public@lists.sourceforge.net cc: gcc@gcc.gnu.org Subject: Re: [Mingw-w64-public] gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library In-Reply-To: <20221120125348.a6xh7kxmvrimse72@pali> Message-ID: <7e5b2195-7cfc-c7a9-e098-169ebce54cf5@martin.st> References: <20221120125348.a6xh7kxmvrimse72@pali> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-55395190-1668979320=:3645219" X-FE-Policy-ID: 3:14:2:SYSTEM X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-55395190-1668979320=:3645219 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT 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 --8323329-55395190-1668979320=:3645219--