This is the mail archive of the
gcc-prs@gcc.gnu.org
mailing list for the GCC project.
Re: java/7169: /usr/ccs/bin/ld: Unsatisfied symbols: libiconv, li
- From: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- To: nobody at gcc dot gnu dot org
- Cc: gcc-prs at gcc dot gnu dot org,
- Date: 2 Jul 2002 19:16:22 -0000
- Subject: Re: java/7169: /usr/ccs/bin/ld: Unsatisfied symbols: libiconv, li
- Reply-to: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot 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)