From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8800 invoked by alias); 3 Jul 2002 13:36:05 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 8759 invoked by uid 71); 3 Jul 2002 13:36:03 -0000 Date: Wed, 03 Jul 2002 06:36:00 -0000 Message-ID: <20020703133603.8750.qmail@sources.redhat.com> To: danglin@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Bruno Haible Subject: Re: java/7169: /usr/ccs/bin/ld: Unsatisfied symbols: libiconv, li Reply-To: Bruno Haible X-SW-Source: 2002-07/txt/msg00097.txt.bz2 List-Id: The following reply was made to PR java/7169; it has been noted by GNATS. From: Bruno Haible To: "John David Anglin" Cc: tromey@redhat.com, dave.anglin@nrc.ca, gcc-gnats@gcc.gnu.org Subject: Re: java/7169: /usr/ccs/bin/ld: Unsatisfied symbols: libiconv, li Date: Wed, 3 Jul 2002 15:35:44 +0200 (CEST) John David Anglin writes: > > libiconv installs its header in $prefix/include and its library in > > $prefix/lib. If gcc now looks in one of these directories but not the > > other, you get the link error that you saw. > > If I add "-liconv" to the link command for jc1, the link is successful. Good. That excludes my prior hypothesis. > The reason that there isn't a library specification in the command is > that the HP iconv routines are in libc and those were the ones found > by configure. Which means that the aclocal.m4 macros are outdated and ought to be upgraded to gettext 0.11.2. Bruno