From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1478 invoked by alias); 2 Jul 2002 21:26:27 -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 1458 invoked by uid 71); 2 Jul 2002 21:26:22 -0000 Date: Tue, 02 Jul 2002 14:26:00 -0000 Message-ID: <20020702212622.1456.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: "John David Anglin" Subject: Re: java/7169: /usr/ccs/bin/ld: Unsatisfied symbols: libiconv, li Reply-To: "John David Anglin" X-SW-Source: 2002-07/txt/msg00083.txt.bz2 List-Id: The following reply was made to PR java/7169; it has been noted by GNATS. From: "John David Anglin" To: bruno@clisp.org (Bruno Haible) 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: Tue, 2 Jul 2002 17:21:03 -0400 (EDT) > Dave Anglin writes: > > > I think what is happening is that the GNU version of > > libiconv installed in /opt/gnu is not found > > ... > > ../gcc/configure --with-gnu-as --with-as=/opt/gnu/bin/as --enable-shared > --disable-nls --prefix=/opt/gnu > > It is generally a bad idea to configure and install *any* program or > library with the same --prefix as you use for configuring gcc. The > reason is that many gcc versions/installations are broken in the sense > that they will look for include files in $prefix/include but not look > for libraries in $prefix/lib - or vice versa. I haven't found this to be a problem. You just have to realize that include directories and libraries are located relative to the installation location for cc1. For example, gcc adds the following -L/opt/gnu/lib/gcc-lib/hppa2.0w-hp-hpux11.11/3.1.1/../../..) when linking. As long as you ensure that the above is equivalent to -L/opt/gnu/lib then everything seems to work fine. There are issues about installing multiple versions of gcc and how best to do that. I have come to the conclusion that it's best to put the default version of gcc at the same prefix as used for other GNU packages (every version of linux that I have seen installs gcc with the prefix /usr) and install test versions elsewhere. I believe that there are problems using transform names with ada so I don't think they are a workable option. > 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. 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. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605)