From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 36252 invoked by alias); 30 Apr 2019 17:58:47 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 36244 invoked by uid 89); 30 Apr 2019 17:58:47 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=CC X-HELO: mail-wr1-f50.google.com Received: from mail-wr1-f50.google.com (HELO mail-wr1-f50.google.com) (209.85.221.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 30 Apr 2019 17:58:46 +0000 Received: by mail-wr1-f50.google.com with SMTP id l2so6406334wrb.9 for ; Tue, 30 Apr 2019 10:58:45 -0700 (PDT) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:56ee:75ff:fe8d:232b? ([2001:8a0:f913:f700:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id s145sm6526110wme.38.2019.04.30.10.58.43 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 30 Apr 2019 10:58:43 -0700 (PDT) Subject: Re: Fix compilation using mingw.org's MinGW To: Eli Zaretskii References: <835zrbe36c.fsf@gnu.org> <250801eb-14f6-5a35-0556-cf5797dd8a7b@redhat.com> <83y347cfbu.fsf@gnu.org> <556cefd7-47ce-54ab-a228-2c727aab4179@redhat.com> <83d0lick7o.fsf@gnu.org> <93ccb0fa-8a05-60ff-d1a8-85d5663b8d16@redhat.com> <831s1murm2.fsf@gnu.org> <365578d2-82fb-8860-26e6-1b31a63632ed@gmail.com> <83imuvsefv.fsf@gnu.org> <014135c5-5bb8-d451-ec7a-6d765b1ea5f5@redhat.com> <83v9yvquoz.fsf@gnu.org> <83r29jqtmi.fsf@gnu.org> Cc: lrn1986@gmail.com, gdb-patches@sourceware.org From: Pedro Alves Message-ID: <0d75e646-1030-9047-f4a5-0b5a881bfbfd@redhat.com> Date: Tue, 30 Apr 2019 17:58:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <83r29jqtmi.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-04/txt/msg00664.txt.bz2 On 4/30/19 6:40 PM, Eli Zaretskii wrote: >>> But no matter where it is set, it must be defined after _any_ >>> standard header is included, so in practice I think it's defined at >>> the place where the patch tests for it. >> I think you mean "before". > No, I meant "after". The default value is set once you included at > least on standard header. Hence you can at that place test for > whether it is defined and what is its default value. Sorry, but no, there's no need to wait until there's a default to override it. In fact, your patch is doing exactly that. common-defs.h is garanteed to be included before any started header. That's exactly why I suggested that spot. That's because the default is only defined if not already defined: /* Select Default WIN32_WINNT Value */ #if !defined(_WIN32_WINNT) && !defined(_CHICAGO_) #define _WIN32_WINNT _WIN32_WINNT_WS03 #endif This family of macros is usually defined on the command line / Makefile on Windows-only projects, even: $CC -D_WIN32_WINNT=xxx That's what MSVC/Visual Studio does. Or at least, used to last I used it, years ago. I did not suggest doing that because it's not as convenient on portable projects that don't just target Windows. > Overriding that > default is generally important only before including w32api headers, > such as windows.h. Agreed. But defining it really early just makes sure it's consistently set. Thanks, Pedro Alves