From patchwork Tue May 23 19:24:46 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eli Zaretskii X-Patchwork-Id: 766189 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3wXQTm4Fy1z9sNV for ; Wed, 24 May 2017 05:25:14 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="Sp/FZs6m"; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :message-id:from:to:cc:in-reply-to:subject:reply-to:references; q=dns; s=default; b=BNKoCH9dLlnG9CumxlXlFcZ2oXX1GH0rIH1NGJrQKfb Av+uy997F1W0KiwvccmLkEejV8Y6yVvAmE+eb9Rq62pUAeIP+k409GRXOZHTACYI bntGvDr0vr1ZOA/PhytqjvIXEeheXJzJztJWobrT7FTyFK+St+vuMFgBUnxHpIMo = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :message-id:from:to:cc:in-reply-to:subject:reply-to:references; s=default; bh=sJVe8TC13DczMdXDvVEfhoICrwI=; b=Sp/FZs6mAyuyMxQ8k OxD0op+Md3+fBXza/x30I4Yz5o27rYsHOrmcGKPlG/kyaWB1wI9wMVZ4yliOsnd+ ACQD24AsmzP+e5vr7dqbjdKHXd9KvHEZS3nfLbACy37z4zce5EnW74VJGo3HOdjA IhZqA7Z68GGagTzwjfjgWOANh8= Received: (qmail 91209 invoked by alias); 23 May 2017 19:25:02 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 91059 invoked by uid 89); 23 May 2017 19:25:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-11.0 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3, RP_MATCHES_RCVD, SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: fencepost.gnu.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (208.118.235.10) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 23 May 2017 19:24:59 +0000 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1514 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dDFQS-0001pj-1T; Tue, 23 May 2017 15:25:01 -0400 Date: Tue, 23 May 2017 22:24:46 +0300 Message-Id: <83poezml4x.fsf@gnu.org> From: Eli Zaretskii To: DJ Delorie CC: gcc-patches@gcc.gnu.org, gdb-patches@sourceware.org In-reply-to: (message from DJ Delorie on Mon, 22 May 2017 15:38:40 -0400) Subject: Re: MinGW compilation warnings in libiberty's waitpid.c Reply-to: Eli Zaretskii References: > From: DJ Delorie > Cc: gcc-patches@gcc.gnu.org, gdb-patches@sourceware.org > Date: Mon, 22 May 2017 15:38:40 -0400 > > Since (or "if") nobody will (should) use waitpid() on mingw anyway, and > since libiberty really wants to include waitpid.o, how difficult would > it be to use some #ifdefs to have waitpid() just return an error on > mingw? That at least gets past the mingw build problem. Instead of making waitpid an always-failing stub on MinGW, wouldn't it be better to make it work on MinGW? Like this: --- libiberty/waitpid.c~0 2016-08-01 18:50:21.000000000 +0300 +++ libiberty/waitpid.c 2017-05-23 21:19:34.302415000 +0300 @@ -23,6 +23,11 @@ does the return value. The third argume #include #endif +#ifdef __MINGW32__ +#include +#define wait(s) _cwait(s,pid,_WAIT_CHILD) +#endif + pid_t waitpid (pid_t pid, int *stat_loc, int options ATTRIBUTE_UNUSED) {