From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41488 invoked by alias); 22 May 2017 17:45:04 -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 41434 invoked by uid 89); 22 May 2017 17:45:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=invest, solid X-HELO: mail-wr0-f176.google.com Received: from mail-wr0-f176.google.com (HELO mail-wr0-f176.google.com) (209.85.128.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 22 May 2017 17:44:53 +0000 Received: by mail-wr0-f176.google.com with SMTP id w50so43050321wrc.0 for ; Mon, 22 May 2017 10:44:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=g4MYNJA6ZUowBud99Yqc4CjveDZ50yf/f/EtNyt2bi8=; b=NihrSJO4iEwxtmCutoRJupGbZz1lZUv0H1xcnSx8yCxyTerFAuqYJq6qmlpNdW54wi mIiiggkldMDZBepaWgw2tpNrZFIwevzUncyC9R4PRAFT07t8CA0eZadZtsz4Ukuld5L1 O2Bhfgr4KeOQF492ViyDH9/EDuRhaMfxxJdOovcGqfWLuWhASFoOaxJsls4ZZbW+nplV /HIFq15s7BZHHy4gkTqSUaasctuFT0vtvHrLKjYnMZSaAuIp0vpXGVdPARfEKJgcHjtQ XubykF01ydrQCboLIHz+CPTkks5JUqlIHcur/T/t10p5h6xSP3Jy6N547LqgSTfK7DJa eGLw== X-Gm-Message-State: AODbwcBBRSm5yIqgUUxYe5ToY2/L7jdqgzaHnPxCUkIRZ1n9lIdoXI2z ++mpkonsJ/if4642ER7ygA== X-Received: by 10.223.130.201 with SMTP id 67mr11920834wrc.106.1495475094194; Mon, 22 May 2017 10:44:54 -0700 (PDT) Received: from [192.168.0.102] ([37.189.166.198]) by smtp.gmail.com with ESMTPSA id 137sm19697397wmi.19.2017.05.22.10.44.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 May 2017 10:44:53 -0700 (PDT) Subject: Re: MinGW compilation warnings in libiberty's include/environ.h To: DJ Delorie References: Cc: eliz@gnu.org, gcc-patches@gcc.gnu.org, gdb-patches@sourceware.org From: Pedro Alves Message-ID: <7d56e68c-21f4-45b6-f446-889d3e5fa8a9@redhat.com> Date: Mon, 22 May 2017 17:45:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-05/txt/msg00495.txt.bz2 On 05/20/2017 02:27 AM, DJ Delorie wrote: > > Pedro Alves writes: >> That sounds to me like the root issue that should be fixed, >> so that these fallback definitions don't come into into play at all. >> I.e., why isn't HAVE_ENVIRON_DECL defined on mingw when >> setenv.o is built? Sounds like a decl check is missing >> in configure.ac. > > environ is tricky because it's typically messy on platforms, unlike a > standard C function. You can't use a generic check if the macro expands > to something that interferes with the check. gnulib has a check, which I assume to be solid: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=m4/environ.m4 we could import just that bit, I suppose, though every client of libiberty's environ.h would need to gain the same check. That's be quite doable with the shared libiberty.m4 idea (we'd just put the check there), but a nuisance if you have to copy the check all over the place. At this point it may be more worth it to invest in finishing the previous use-gnulib-in-gcc effort instead. Thanks, Pedro Alves