From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17551 invoked by alias); 20 Nov 2013 03:46:32 -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 17496 invoked by uid 89); 20 Nov 2013 03:46:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_50,RDNS_NONE,SPF_SOFTFAIL,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: mtaout20.012.net.il Received: from Unknown (HELO mtaout20.012.net.il) (80.179.55.166) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 20 Nov 2013 03:46:26 +0000 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MWJ00C00MGMSK00@a-mtaout20.012.net.il> for gdb-patches@sourceware.org; Wed, 20 Nov 2013 05:46:18 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MWJ00COLMH5I1A0@a-mtaout20.012.net.il>; Wed, 20 Nov 2013 05:46:18 +0200 (IST) Date: Wed, 20 Nov 2013 03:47:00 -0000 From: Eli Zaretskii Subject: Re: [PATCH v3 10/13] don't check for unistd.h In-reply-to: <8738mskqam.fsf@fleche.redhat.com> To: Tom Tromey Cc: pierre.muller@ics-cnrs.unistra.fr, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83fvqrg2gn.fsf@gnu.org> References: <1384806318-12231-1-git-send-email-tromey@redhat.com> <1384806318-12231-11-git-send-email-tromey@redhat.com> <13494.0459196971$1384894582@news.gmane.org> <877gc4ksnz.fsf@fleche.redhat.com> <8738mskqam.fsf@fleche.redhat.com> X-IsSubscribed: yes X-SW-Source: 2013-11/txt/msg00580.txt.bz2 > From: Tom Tromey > Cc: > Date: Tue, 19 Nov 2013 14:57:53 -0700 > > Pierre> How could this problem be solved? > > Tom> I'll send you a patch to try shortly. > > Well, so I thought. It turned into an insane nightmare. The unistd > module pulls into everything, which stomps all over our > namespace. > > I'm probably going to revert the whole series tomorrow morning. Perhaps we could still leave it, and overcome the gethostname problem on our own. Pierre, can you see if 'configure' detects the presence of gethostname when it probes the system? If not, that might be the problem, and I might have a trick to overcome it.