From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11616 invoked by alias); 17 Nov 2004 03:28:38 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 11533 invoked from network); 17 Nov 2004 03:28:32 -0000 Received: from unknown (HELO cgf.cx) (66.30.17.189) by sourceware.org with SMTP; 17 Nov 2004 03:28:32 -0000 Received: by cgf.cx (Postfix, from userid 201) id E7BC91B3E5; Tue, 16 Nov 2004 22:28:56 -0500 (EST) Date: Wed, 17 Nov 2004 14:25:00 -0000 From: Christopher Faylor To: binutils@sourceware.org, gdb@sourceware.org Subject: Re: gcc/intl vs. src/intl Message-ID: <20041117032856.GD28679@trixie.casa.cgf.cx> Mail-Followup-To: binutils@sourceware.org, gdb@sourceware.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-SW-Source: 2004-11/txt/msg00182.txt.bz2 On Tue, Nov 16, 2004 at 08:53:05PM -0500, Ian Lance Taylor wrote: >So, I notice that gcc/intl and src/intl are pretty different. And I >wonder how this can possibly work in the context of uberbaum. I >suppose it will work fine on a host on which all the intl code can be >found in libc with no other dependencies--such as GNU/Linux. On such >a host the intl directory will not be built, and code will simply link >with -lc. But on a host in which gcc/intl requires -liconv--such as >NetBSD, or Cygwin--the differing expectations of gcc/intl and src/intl >will cause conflict. > >Has anybody looked into resolving this? Presumably the correct >short-term fix is to bring gcc/intl over to src/intl, and update the >Makefiles accordingly. Presumably the long-term fix would to keep >intl in sync as we keep libiberty in sync. Does anybody have a better >idea? The other, more radical way of doing this is to get rid of uberbaum and finally put gcc, gdb, and binutils under one repository. cygwin, sid and other non-GNU projects could keep using the src repository while the other GNU projects could use the same infrastructure. cgf