From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32761 invoked by alias); 27 Apr 2011 16:59:13 -0000 Received: (qmail 32741 invoked by uid 22791); 27 Apr 2011 16:59:09 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 27 Apr 2011 16:58:56 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id C25E62BAE55; Wed, 27 Apr 2011 12:58:55 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5N15-9cBhC+H; Wed, 27 Apr 2011 12:58:55 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 987582BAE53; Wed, 27 Apr 2011 12:58:55 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id D2614145615; Wed, 27 Apr 2011 09:58:53 -0700 (PDT) Date: Wed, 27 Apr 2011 16:59:00 -0000 From: Joel Brobecker To: Mark Kettenis Cc: yao@codesourcery.com, gdb-patches@sourceware.org Subject: Re: New ARI warning Wed Apr 27 01:54:55 UTC 2011 Message-ID: <20110427165853.GD2489@adacore.com> References: <20110427015455.GA24839@sourceware.org> <4DB78A74.9060105@codesourcery.com> <20110427150815.GB2489@adacore.com> <4DB83ACB.6080503@codesourcery.com> <20110427161802.GC2489@adacore.com> <201104271642.p3RGgUW8025117@glazunov.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201104271642.p3RGgUW8025117@glazunov.sibelius.xs4all.nl> User-Agent: Mutt/1.5.20 (2009-06-14) 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 X-SW-Source: 2011-04/txt/msg00515.txt.bz2 > And suddenly even that "trivial" linux-ptrace.h diff is turning into a > can of worms. Some people, including me, have stated that the stuff in > common/ should *not* depend on any configure checks Do you think that's attainable, though? There are a lot of basic types which depend on configure... There might be some code such as gdb_select which might be useful to gdbserver as well, one day. I'm sure we might be able to implement some of the code without the use of configure, but configure helps keep things cleaner. > In this case there probably is a way out though. I don't think there > are any systems out there that don't have . So we could > just get rid of gdb_wait.h altogether. Is that because sys/wait is somehow mandated (by C90, perhaps?). I'm wondering why we had it in the first place, it must have been useful at some point... -- Joel