From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29716 invoked by alias); 18 Dec 2012 18:11:23 -0000 Received: (qmail 29699 invoked by uid 22791); 18 Dec 2012 18:11:21 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_NO 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; Tue, 18 Dec 2012 18:11:16 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id CE4722E24E; Tue, 18 Dec 2012 13:11:15 -0500 (EST) 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 j2s81Awc7CYA; Tue, 18 Dec 2012 13:11:15 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 673E22E052; Tue, 18 Dec 2012 13:11:15 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id AE889C394A; Tue, 18 Dec 2012 22:11:04 +0400 (RET) Date: Tue, 18 Dec 2012 18:11:00 -0000 From: Joel Brobecker To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [RFA/commit 2/2] Import gnulib's errno module. Message-ID: <20121218181104.GM3273@adacore.com> References: <1355756839-11337-1-git-send-email-brobecker@adacore.com> <1355756839-11337-2-git-send-email-brobecker@adacore.com> <20121218060719.GD3273@adacore.com> <87r4mns49t.fsf@fleche.redhat.com> <20121218165035.GI3273@adacore.com> <87ehins375.fsf@fleche.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ehins375.fsf@fleche.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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: 2012-12/txt/msg00655.txt.bz2 > Joel> I though libiconv had its own mechanism for defining EILSEQ. > Joel> Do you think the two are going to interfere? > > It seems possible to me. Yes, indeed. I don't know how to solve the problem, however, short of maybe asking gnulib to define it as ENOENT as well. But I don't know how I could justify this request, since other projects might have chosen a different value. IMO, a more promising approach would be to convince libiconv to use gnulib's errno instead. Or, something that occured to me today, would be to undo my change, and let the user figure out that to build on a system that does not provide EILSEQ, he should build with -DEILSEQ=ENOENT. Seems horrible to me, but it would probably work. -- Joel