Re: java/7169: /usr/ccs/bin/ld: Unsatisfied symbols: libiconv, libiconv_open, libiconv_close

[Bruno Haible <bruno@clisp.org>]

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

From: Bruno Haible <bruno@clisp.org>
To: tromey@redhat.com
Cc: dave.anglin@nrc.ca, gcc-gnats@gcc.gnu.org
Subject: Re: java/7169: /usr/ccs/bin/ld: Unsatisfied symbols: libiconv, libiconv_open, libiconv_close
Date: Tue, 2 Jul 2002 21:19:22 +0200 (CEST)

 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.
 
 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.
 
 You can check this theory by looking what the preprocessor does and
 what the linker does when you call it though
 
   XGCC="stage1/xgcc -Bstage1/ -B/opt/gnu/hppa2.0w-hp-hpux11.11/bin/ \
     -DIN_GCC    -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes \
     -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long \
     -DHAVE_CONFIG_H"
 
 For the preprocessor, use "$XGCC -v  -E -".
 For the linker, use "$XGCC -v -v dummy.o -o /tmp/a.out"
 
 > Ok.  This could be a minor problem in the libiconv autoconf macros.
 > We've run into the odd bit of confusion in this area before.
 
 I can recommend the gettext 0.11.2 macros for iconv.m4 and gettext.m4;
 they appear to be bug-free. Of course, when you upgrade gettext.m4 you
 also need to run gettextize of the same version and commit its changes
 and your changes to the CVS.
 
 I can't comment on details of the gcc/aclocal.m4 contents because the
 gettext and iconv macros used there look quite old to me and have been
 patched by other people.
 
 > If you install libiconv in a place that is going to be visible to gcc,
 > then it seems like you can't pretend it doesn't exist.  What do you
 > think about that?  I'd agree that it would be best if the autoconf
 > macros automatically detected this situation
 
 The gettext 0.11.2 macro automatically does this; i.e. it will look for
 iconv.h and libiconv.{a,so} in $prefix/include and $prefix/lib,
 respectively, removing the need for --with-libiconv-prefix in most
 cases.
 
 Bruno