From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Tromey To: tromey@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org Subject: Re: java/2812: Build failure; missing symbols (iconv) in link of jc1 Date: Wed, 13 Jun 2001 14:46:00 -0000 Message-id: <20010613214602.29037.qmail@sourceware.cygnus.com> X-SW-Source: 2001-06/msg00606.html List-Id: The following reply was made to PR java/2812; it has been noted by GNATS. From: Tom Tromey To: Dave Gilbert Cc: gcc-gnats@gcc.gnu.org, gcc@treblig.org Subject: Re: java/2812: Build failure; missing symbols (iconv) in link of jc1 Date: 13 Jun 2001 15:51:18 -0600 >>>>> "Dave" == Dave Gilbert writes: Dave> So all I can presume is that whatever happened during the test Dave> had LIBICONV_PLUG defined or picked up something else. The test to see if iconv() is available is a simple link test. The test doesn't include any headers. So this can't explain what we're seeing. You can see the results of compilation and link tests that configure runs. The output is stored in a file called `config.log' (in the `gcc' build directory). If this approach to iconv is very common we can easily accomodate it. We can add an additional test to see if -liconv exists. Or we can add a test to see if a compile with `#include ' can use `iconv_open' and still link. (Or ... almost anything.) I'm guessing that your system has iconv() in libc, but your is from a different package and conflicts with it. We don't expect this, since this is broken. I have no way to test any fix I might write. However I could write a simple configure.in patch and send it to you if you would test it. Still, I'm reluctant to do this if your machine is the only one with this configuration. That would be pointless... Tom