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

["John David Anglin" <dave@hiauly1.hia.nrc.ca>]

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: tromey@redhat.com
Cc: dave.anglin@nrc.ca, gcc-gnats@gcc.gnu.org, bruno@clisp.org
Subject: Re: java/7169: /usr/ccs/bin/ld: Unsatisfied symbols: libiconv, li
Date: Tue, 2 Jul 2002 14:45:43 -0400 (EDT)

 > >>>>> "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.
 
 On closer inspection today, I realize that I was somewhat confused about
 the above.  The above only happens when --with-libiconv-prefix is
 specified as /opt/gnu.  Without --with-libiconv-prefix, the config.log is
 
 configure:4457: checking for iconv
 configure:4475: cc -o conftest -g   conftest.c  1>&5
 (Bundled) cc: warning 480: The -g option is available only with the C/ANSI C pro
 duct; ignored.
 configure:4518: checking for iconv declaration
 configure:4543: cc -c -g  conftest.c 1>&5
 (Bundled) cc: warning 480: The -g option is available only with the C/ANSI C pro
 duct; ignored.
 
 and the result is
 
 checking for iconv... yes
 checking for iconv declaration... 
          extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft);
 
 So, the use of iconv is enabled by the system version of iconv.  The system
 iconv.h header is in /usr/include and the routines in libc.  This is the
 situation where the build failure occurs.
 
 > Dave> However, gcc uses the GNU iconv.h header in the build.
 
 If configure determines that the system has the iconv function,
 Gcc will use the GNU iconv.h header in the build if it is installed
 in $(includedir) or $(local_includedir), the directory for site-specific
 includes.  
 
 The GNU iconv.h redefines iconv, iconv_open, iconv_close except when
 LIBICONV_PLUG is defined.  If the GNU header is used, then "-liconv"
 needs to be added to the link command to link with the GNU library.
 This works without a problem in builds starting with gcc if the
 directory $(libsubdir) exists.
 
 > 
 > 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?
 
 If I specify --prefix=/opt/gnu and --with-libiconv-prefix=/opt/gnu, then
 the libiconv configure test for libiconv fails:
 
 configure:4457: checking for iconv
 configure:4475: cc -o conftest -g  -I/opt/gnu/include  conftest.c  1>&5
 (Bundled) cc: warning 480: The -g option is available only with the C/ANSI C pro
 duct; ignored.
 (Bundled) cc: "/opt/gnu/include/iconv.h", line 72: warning 5: "const" will becom
 e a keyword.
 (Bundled) cc: "/opt/gnu/include/iconv.h", line 72: error 1000: Unexpected symbol
 : "char".
 (Bundled) cc: "/opt/gnu/include/iconv.h", line 72: warning 5: "const" will becom
 e a keyword.
 (Bundled) cc: "/opt/gnu/include/iconv.h", line 72: error 1000: Unexpected symbol
 : "char".
 (Bundled) cc: "/opt/gnu/include/iconv.h", line 72: error 1705: Function prototyp
 es are an ANSI feature.
 (Bundled) cc: "/opt/gnu/include/iconv.h", line 82: error 1000: Unexpected symbol
 : "libiconv".
 
 and we have
 
 /* Define if you have the iconv() function. */
 /* #undef HAVE_ICONV */
 
 /* Define as const if the declaration of iconv() needs const. */
 /* #undef ICONV_CONST */
 
 As a result, I believe that the build will be successful (it's past the
 previous failure point).
 
 Dave
 -- 
 J. David Anglin                                  dave.anglin@nrc.ca
 National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)