From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17452 invoked by alias); 2 Jul 2002 19:27:00 -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 17322 invoked by uid 71); 2 Jul 2002 19:26:46 -0000 Date: Tue, 02 Jul 2002 12:27:00 -0000 Message-ID: <20020702192645.17296.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Bruno Haible Subject: Re: java/7169: /usr/ccs/bin/ld: Unsatisfied symbols: libiconv, libiconv_open, libiconv_close Reply-To: Bruno Haible X-SW-Source: 2002-07/txt/msg00070.txt.bz2 List-Id: The following reply was made to PR java/7169; it has been noted by GNATS. From: Bruno Haible 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