From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [209.51.188.92]) by sourceware.org (Postfix) with ESMTPS id 88A073945C36 for ; Fri, 1 Apr 2022 14:26:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 88A073945C36 Received: from [2001:470:142:3::e] (port=54466 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1naIEo-0000QJ-Rd; Fri, 01 Apr 2022 10:26:54 -0400 Received: from [87.69.77.57] (port=2621 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1naIEo-0001Nw-Bi; Fri, 01 Apr 2022 10:26:54 -0400 Date: Fri, 01 Apr 2022 17:27:06 +0300 Message-Id: <8335iw6fr9.fsf@gnu.org> From: Eli Zaretskii To: Joel Brobecker Cc: aburgess@redhat.com, pedro@palves.net, gdb-patches@sourceware.org In-Reply-To: (message from Joel Brobecker on Fri, 1 Apr 2022 07:12:06 -0700) Subject: Re: GDB 12.0.90 available for testing References: <83pmm8a7gn.fsf@gnu.org> <83o81sa6nu.fsf@gnu.org> <83ilrzap07.fsf@gnu.org> <83mth67i8m.fsf@gnu.org> <72ad3448-0ff0-f36c-d1f3-cc194c0503b8@palves.net> <83ee2i72vl.fsf@gnu.org> <87sfqx864d.fsf@redhat.com> <83fsmx59wi.fsf@gnu.org> <838rsp55nl.fsf@gnu.org> X-Spam-Status: No, score=1.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2022 14:26:57 -0000 > Date: Fri, 1 Apr 2022 07:12:06 -0700 > From: Joel Brobecker > Cc: Joel Brobecker , aburgess@redhat.com, > pedro@palves.net, gdb-patches@sourceware.org > > > If this problem only happens with mingw.org's MinGW, I'm okay with > > having local workarounds. Although I'm puzzled how can that be, since > > both MinGW flavors are supposed to share the same runtime. Or do you > > build GDB against the UCRT (as opposed to MSVCRT) runtime? > > I don't know how to answer that question. Is that something > I can figure out from looking at how we configure the build > of MinGW-w64? It's enough (and simpler) to look at the DLLs on which the GDB executable on Windows depends, with this command: objdump -x gdb.exe | fgrep "DLL Name" Here's the output on my system: (standard input):72: DLL Name: ADVAPI32.DLL (standard input):82: DLL Name: libguile-2.0-22.dll (standard input):219: DLL Name: KERNEL32.dll (standard input):326: DLL Name: msvcrt.dll (standard input):353: DLL Name: msvcrt.dll (standard input):501: DLL Name: libncurses5.dll (standard input):578: DLL Name: libsource-highlight-4.dll (standard input):585: DLL Name: USER32.dll (standard input):594: DLL Name: WS2_32.dll (standard input):615: DLL Name: zlib1.dll (standard input):629: DLL Name: libgcc_s_dw2-1.dll (standard input):645: DLL Name: libstdc++-6.dll (standard input):736: DLL Name: python34.dll Note the two instances of msvcrt.dll -- this is the (traditional) MS C runtime library. If you see UCRT instead, it might explain the difference in our observations.