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

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

[Bruno Haible]

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

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

[danglin]

Synopsis: /usr/ccs/bin/ld: Unsatisfied symbols: libiconv, libiconv_open, libiconv_close

Responsible-Changed-From-To: unassigned->danglin
Responsible-Changed-By: danglin
Responsible-Changed-When: Tue Jul  2 16:01:34 2002
Responsible-Changed-Why:
    Mine.
State-Changed-From-To: open->closed
State-Changed-By: danglin
State-Changed-When: Tue Jul  2 16:01:34 2002
State-Changed-Why:
    Work around found.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7169

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

[Tom Tromey]

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

From: Tom Tromey <tromey@redhat.com>
To: dave.anglin@nrc.ca
Cc: gcc-gnats@gcc.gnu.org, Bruno Haible <bruno@clisp.org>
Subject: Re: java/7169: /usr/ccs/bin/ld: Unsatisfied symbols: libiconv, libiconv_open, libiconv_close
Date: 01 Jul 2002 21:19:23 -0600

 >>>>> "Dave" == dave anglin <dave.anglin@nrc.ca> writes:
 
 Dave> I think what is happening is that the GNU version of
 Dave> libiconv installed in /opt/gnu is not found because
 Dave> the GNU iconv.h has "const" in the prototype for
 Dave> iconv_open:
 
 You can check this theory by looking in config.log.
 What does it say?  Any of the entries related to iconv would be
 interesting.
 
 Dave> However, gcc uses the GNU iconv.h header in the build.
 
 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.
 
 Bruno, do you remember what has happened in this area before?
 Do we need to upgrade the macros in gcc?
 
 Dave, I think what you're doing might not really be supported.
 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; hopefully Bruno will
 tell us what extra info we need to diagnose what has happened.
 
 Maybe the problem here is simply a lack of documentation on telling
 configure about libiconv?  I could write a doc patch...?  You can use
 --with-libiconv-prefix=/prefix to tell configure where to find libiconv.
 Does doing this cure the problem?
 
 Tom

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

[dave.anglin]

>Number:         7169
>Category:       java
>Synopsis:       /usr/ccs/bin/ld: Unsatisfied symbols: libiconv, libiconv_open, libiconv_close
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jun 29 22:06:01 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Dave Anglin
>Release:        3.1.1 20020628 (prerelease)
>Organization:
>Environment:
hppa2.0-hp-hpux11.11
>Description:
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  -o jc1 \
        java/parse.o java/class.o java/decl.o java/expr.o java/constants.o java/
lang.o java/typeck.o java/except.o java/verify.o java/zextract.o java/jcf-io.o j
ava/jcf-parse.o java/mangle.o java/mangle_name.o java/builtins.o java/jcf-write.
o java/buffer.o java/check-init.o java/jcf-depend.o java/jcf-path.o java/xref.o
java/boehm.o mkdeps.o main.o libbackend.a -L../zlib -lz    ../libiberty/libibert
y.a
/usr/ccs/bin/ld: Unsatisfied symbols:
   libiconv (first referenced in java/parse.o) (code)
   libiconv_open (first referenced in java/parse.o) (code)
   libiconv_close (first referenced in java/parse.o) (code)
collect2: ld returned 1 exit status

I think what is happening is that the GNU version of
libiconv installed in /opt/gnu is not found because
the GNU iconv.h has "const" in the prototype for
iconv_open:

  extern iconv_t iconv_open (const char* tocode, const char* fromcode);

configure then detects the HP iconv in libc and as a
result we have

#define HAVE_ICONV 1
#define ICONV_CONST

in auto-host.h and

LIBICONV=

in the gcc/Makefile

However, gcc uses the GNU iconv.h header in the build.

I think the fix is for the configure test program to define
"const" to "" when it does its declaration checks with
a non ISO compiler.
>How-To-Repeat:
export CC=cc
../gcc/configure --with-gnu-as --with-as=/opt/gnu/bin/as --enable-shared --disab
le-nls --prefix=/opt/gnu &&
make bootstrap &&
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: