From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 4F7BF3844041 for ; Sat, 4 Jul 2020 18:19:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4F7BF3844041 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=eliz@gnu.org Received: from fencepost.gnu.org ([2001:470:142:3::e]:37970) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jrmkr-0008Je-Iq; Sat, 04 Jul 2020 14:19:13 -0400 Received: from [176.228.60.248] (port=2619 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jrmkq-0002ol-Le; Sat, 04 Jul 2020 14:19:13 -0400 Date: Sat, 04 Jul 2020 21:19:16 +0300 Message-Id: <83sge7ta6z.fsf@gnu.org> From: Eli Zaretskii To: Nick Alcock Cc: brobecker@adacore.com, gdb-patches@sourceware.org In-Reply-To: <878sfztabt.fsf@esperi.org.uk> (message from Nick Alcock on Sat, 04 Jul 2020 19:16:22 +0100) Subject: Re: libctf compilation failure on MinGW References: <83y2o2vxm7.fsf@gnu.org> <878sfztabt.fsf@esperi.org.uk> X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Sat, 04 Jul 2020 18:19:30 -0000 > From: Nick Alcock > Cc: Joel Brobecker , gdb-patches@sourceware.org > Date: Sat, 04 Jul 2020 19:16:22 +0100 > > > GDB is about to branch for the imminent GDB 10.1 release, and > > currently the problems I described back then are still with us. > > Oh, I thought you pushed a fix already! Sorry! We did, but only on the-then GDB 9.1 branch. The master branch wasn't changed, as we expected to have you update the upstream with the proper solution. > I'll post a fix sticking suitable E* #defines in once I get back from > holiday on Tuesday. > > > we'd like a solution soon, and need to decide whether to go with the > > same workaround we used for GDB 9.1 or use a better change from you. > > I think that workaround is in hindsight better than the change I > proposed, and should go in trunk. :/ Thanks.