From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22313 invoked by alias); 28 Jan 2003 03:33:32 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 22306 invoked from network); 28 Jan 2003 03:33:31 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 172.16.49.205 with SMTP; 28 Jan 2003 03:33:31 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18dOO5-0004ZP-00 for ; Mon, 27 Jan 2003 23:34:21 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18dMVb-0002zJ-00 for ; Mon, 27 Jan 2003 22:33:59 -0500 Date: Tue, 28 Jan 2003 03:33:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: RFA: always default to using the libiberty regex Message-ID: <20030128033359.GA11366@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <1043715417.1134.7.camel@Dragon> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1043715417.1134.7.camel@Dragon> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-01/txt/msg00751.txt.bz2 On Mon, Jan 27, 2003 at 04:56:56PM -0800, Martin M. Hunt wrote: > This patch deletes the configure code to check the OS implementation of > regex and default to that. The default will now always be the builtin. > > > 2003-01-27 Martin M. Hunt > > * configure.in: Revert check for system regex. Use builtin regex by > default. > * configure: Rebuilt. > I'm still not convinced this is a good idea. Context: it's a bug in the system's GNU C library, and should be fixed as such. All the rest of us who have a version of glibc which has this issue addressed don't have a problem, and I don't really want to carry around yet another statically linked copy of regex if I don't need to. Since it doesn't manifest on my system, I suspect it is fixed in glibc 2.3.1; it's another piece of fallout from Red Hat's choice of using the brand-new barely-tested glibc 2.2.93 for their desktop product. What about getting a better range of affected glibc versions and conditioning the test on those? Do you think that would work? [Oh, and please don't post the diffs to "configure" to the mailing list.] -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer