From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24747 invoked by alias); 20 Nov 2013 11:21:13 -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 24733 invoked by uid 89); 20 Nov 2013 11:21:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=2.6 required=5.0 tests=BAYES_50,MSGID_MULTIPLE_AT,RDNS_NONE,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: mailhost.u-strasbg.fr Received: from Unknown (HELO mailhost.u-strasbg.fr) (130.79.222.211) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 20 Nov 2013 11:21:11 +0000 Received: from mailhost.u-strasbg.fr (localhost [127.0.0.1]) by antispam (Postfix) with ESMTP id 0C32222039A; Wed, 20 Nov 2013 12:21:03 +0100 (CET) Received: from mailhost.u-strasbg.fr (localhost [127.0.0.1]) by antivirus (Postfix) with ESMTP id F2E462206CF; Wed, 20 Nov 2013 12:21:02 +0100 (CET) Received: from md13.u-strasbg.fr (md13.u-strasbg.fr [130.79.200.248]) by mr1.u-strasbg.fr (Postfix) with ESMTP id B25032206D1; Wed, 20 Nov 2013 12:20:59 +0100 (CET) Received: from ms17.u-strasbg.fr (ms17.u-strasbg.fr [130.79.204.117]) by md13.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id rAKBKx0u008064 ; Wed, 20 Nov 2013 12:20:59 +0100 (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from E6510Muller (unknown [177.32.73.144]) (Authenticated sender: mullerp) by ms17.u-strasbg.fr (Postfix) with ESMTPSA id 63D541FD95; Wed, 20 Nov 2013 12:20:55 +0100 (CET) From: "Pierre Muller" To: "'Eli Zaretskii'" , "'Tom Tromey'" Cc: 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> <83fvqrg2gn.fsf@gnu.org> In-Reply-To: <83fvqrg2gn.fsf@gnu.org> Subject: RE: [PATCH v3 10/13] don't check for unistd.h Date: Wed, 20 Nov 2013 12:16:00 -0000 Message-ID: <006701cee5e2$972ad7a0$c58086e0$@muller@ics-cnrs.unistra.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-SW-Source: 2013-11/txt/msg00590.txt.bz2 Hi all, > -----Message d'origine----- > De=A0: gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Eli Zaretskii > Envoy=E9=A0: mercredi 20 novembre 2013 01:46 > =C0=A0: Tom Tromey > Cc=A0: pierre.muller@ics-cnrs.unistra.fr; gdb-patches@sourceware.org > Objet=A0: Re: [PATCH v3 10/13] don't check for unistd.h >=20 > > 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. >=20 > Perhaps we could still leave it, and overcome the gethostname problem > on our own. >=20 > 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. I checked the config files in the gdb build directory. Indeed, there is a check for gethostbyname, but not for gethostname. But there is no line associated with this in=20 the generated build dir gdb/config.h. When I looked into source gdb/configure.ac, I only found AC_SEARCH_LIBS(gethostbyname, nsl) with a comment talking about Solaris system. But there is nothing about gethostname. Like Eli suggests, maybe adding a check for existence of this function and disabling the call if it is not found would be enough indeed. I also suppose that I am too weak on autoconf and the like to try this myself, but could easily test a patch... Adding #ifdef HAVE_GETHOSTNAME around the call to gethostname function in m32r-rom.c source of course solves the linking problem.=20 =20=20 Pierre =20 PS: I tried to compile a simple source with a call to gethostname, the problem is that the functions are both defined but in winsock.h or winsock2.h and the seem to link to ws2_32.dll Thus, without adding this DLL to the test, the check will not work. This is already done in configure.ac around line 1907, so that the checks for gethostname and gethostbyname need to be done after this, no? I have no clue about how to add the winsock or winsock2 header in the test...