From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119133 invoked by alias); 19 May 2017 15:51:44 -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 119052 invoked by uid 89); 19 May 2017 15:51:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 19 May 2017 15:51:30 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EBDE017AC60; Fri, 19 May 2017 15:51:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com EBDE017AC60 Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=palves@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com EBDE017AC60 Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1CB9E7D977; Fri, 19 May 2017 15:51:30 +0000 (UTC) Subject: Re: MinGW compilation warnings in libiberty's include/environ.h To: Eli Zaretskii , gcc-patches@gcc.gnu.org References: <83k25rcqw2.fsf@gnu.org> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Fri, 19 May 2017 15:51: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: <83k25rcqw2.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-05/txt/msg00456.txt.bz2 On 05/08/2017 04:25 PM, Eli Zaretskii wrote: > When compiling libiberty (as part of GDB) with MinGW on MS-Windows, I > see the following warning: > > gcc -c -DHAVE_CONFIG_H -O2 -gdwarf-4 -g3 -D__USE_MINGW_ACCESS -I. -I./../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic -D_GNU_SOURCE ./setenv.c -o setenv.o > In file included from ./setenv.c:64:0: > ./../include/environ.h:30:1: warning: function declaration isn't a prototype [-Wstrict-prototypes] > extern char **environ; > ^ > > This was already reported 4 years ago, here: > > https://gcc.gnu.org/ml/gcc-patches/2013-03/msg00471.html > > and was solved back then. But it looks like the offending code was > copied to include/environ.h without the fix, and the warning is thus > back. > > The problem is with this code in environ.h: > > #ifndef HAVE_ENVIRON_DECL > # ifdef __APPLE__ > # include > # define environ (*_NSGetEnviron ()) > # else > extern char **environ; > # endif > # define HAVE_ENVIRON_DECL > #endif > > which causes the MinGW compiler to see the declaration of environ, > whereas MinGW's stdlib.h has this: > > #ifdef __MSVCRT__ > # define _environ (*__p__environ()) > extern _CRTIMP __cdecl __MINGW_NOTHROW char ***__p__environ(void); > # define _wenviron (*__p__wenviron()) > extern _CRTIMP __cdecl __MINGW_NOTHROW wchar_t ***__p__wenviron(void); > > #else /* ! __MSVCRT__ */ > # ifndef __DECLSPEC_SUPPORTED > # define _environ (*_imp___environ_dll) > extern char ***_imp___environ_dll; > > # else /* __DECLSPEC_SUPPORTED */ > # define _environ _environ_dll > __MINGW_IMPORT char ** _environ_dll; > # endif /* __DECLSPEC_SUPPORTED */ > #endif /* ! __MSVCRT__ */ > > #define environ _environ So again there's a system header that defines the symbol but for some reason libiberty still wants to declare/define it is if it weren't? 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. Thanks, Pedro Alves