From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7780 invoked by alias); 17 Nov 2004 01:53:21 -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 7434 invoked from network); 17 Nov 2004 01:53:16 -0000 Received: from unknown (209.128.65.135) by sourceware.org with QMTP; 17 Nov 2004 01:53:16 -0000 Received: (qmail 32100 invoked by uid 10); 17 Nov 2004 01:53:15 -0000 Received: (qmail 5427 invoked by uid 500); 17 Nov 2004 01:53:05 -0000 From: Ian Lance Taylor To: binutils@sourceware.org, gdb@sourceware.org Subject: gcc/intl vs. src/intl Date: Wed, 17 Nov 2004 02:11:00 -0000 Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-11/txt/msg00180.txt.bz2 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? Ian