From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) by sourceware.org (Postfix) with ESMTPS id 3ACD33844041 for ; Sat, 4 Jul 2020 18:16:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3ACD33844041 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 064IGVwc120701; Sat, 4 Jul 2020 18:16:31 GMT Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by aserp2120.oracle.com with ESMTP id 322kv6186f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 04 Jul 2020 18:16:30 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 064IClN9191314; Sat, 4 Jul 2020 18:16:30 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3020.oracle.com with ESMTP id 322h3haamk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 04 Jul 2020 18:16:30 +0000 Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 064IGOU8001263; Sat, 4 Jul 2020 18:16:24 GMT Received: from loom (/81.187.191.129) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 04 Jul 2020 11:16:23 -0700 From: Nick Alcock To: Eli Zaretskii Cc: Joel Brobecker , gdb-patches@sourceware.org Subject: Re: libctf compilation failure on MinGW References: <83y2o2vxm7.fsf@gnu.org> Emacs: or perhaps you'd prefer Russian Roulette, after all? Date: Sat, 04 Jul 2020 19:16:22 +0100 In-Reply-To: <83y2o2vxm7.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 02 Jul 2020 16:45:52 +0300") Message-ID: <878sfztabt.fsf@esperi.org.uk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9672 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxlogscore=999 malwarescore=0 mlxscore=0 suspectscore=0 spamscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2007040127 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9672 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 bulkscore=0 malwarescore=0 suspectscore=0 mlxlogscore=999 phishscore=0 spamscore=0 priorityscore=1501 clxscore=1011 impostorscore=0 mlxscore=0 adultscore=0 cotscore=-2147483648 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2007040127 X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP, UNPARSEABLE_RELAY 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:16:39 -0000 On 2 Jul 2020, Eli Zaretskii outgrape: > We had a conversation about this back in February, AFAIR, and your > conclusion was that you'd like to remove those E* constants from the > sources, and thus avoid the problem altogether. > > Did you have time to make those changes since then? I... tried. It's *so annoying* to use that I'm going to go for your original approach, and just #define undefined-on-some-platform E* constants as needed. (Maybe I should automate this, and scan *all* E* constants used by libctf in configure and define suitable replacements, to avoid the whack-a-mole nature of this?) > 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! 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. :/