java/7169: /usr/ccs/bin/ld: Unsatisfied symbols: libiconv, li

John David Anglin dave@hiauly1.hia.nrc.ca
Tue Jul 2 14:26:00 GMT 2002


The following reply was made to PR java/7169; it has been noted by GNATS.

From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
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)



More information about the Gcc-prs mailing list