Re: Possible Bug in Gnulib

[Noah Lavine]

Hello,

> Thanks for your report. For a good report, you should also have stated
>  - how you configured guile,
>  - the precise error message that you got.

Sorry about that. I configured Guile with

./configure --prefix=/Users/noah/Desktop/guile
--with-libiconv-prefix=/opt/local
--with-libunistring-prefix=/opt/local --with-libgmp-prefix=/opt/local
--with-libintl-prefix=/opt/local --with-libreadline-prefix=/opt/local
--enable-guile-debug.

(My extra libiconv is in /opt/local)

The error message I got was

Undefined symbols:
  "_iconv", referenced from:
      _rpl_iconv in libgnu.a(iconv.o)
     (maybe you meant: _mem_iconveh, _iconveh_close , _rpl_iconv_open
, _mem_cd_iconveh , _str_iconveh , _rpl_iconv , _iconveh_open ,
_rpl_iconv_close , _str_cd_iconveh )
  "_iconv_close", referenced from:
      _rpl_iconv_close in libgnu.a(iconv_close.o)
     (maybe you meant: _rpl_iconv_close)
  "_iconv_open", referenced from:
      _rpl_iconv_open in libgnu.a(iconv_open.o)
      _rpl_iconv_open in libgnu.a(iconv_open.o)
     (maybe you meant: _rpl_iconv_open)
ld: symbol(s) not found

> Can you look whether ICONV_FLAVOR is defined in a config.h in your
> build? If so, can you look in config.log what were the results of
> the corresponding tests of iconv_open.m4?

ICONV_FLAVOR is not defined. REPLACE_ICONV_UTF is defined as 1. Here
is what I found in config.log.

First, there is an expected failure of an iconv test, where configure
didn't use the iconv path I gave it. It then reran the test with the
correct iconv path and found that iconv worked.

The test that prints "checking for working iconv" also returned yes.

However, the test "checking whether iconv supports conversion between
UTF-8 and UTF-{16,32}{BE,LE}" failed, on the conversion from UTF-8 to
UTF-32LE. I can give the test program if you would like, but it's
quite long. config.log shows that the test was linked with the correct
libiconv, too.

> All this assumes that you have added to CPPFLAGS and LDFLAGS the
> -I and -L options that match for using the right copy of libiconv.
> If you only add a -I option but not the corresponding -L option,
> it is perfectly possible to confuse the .m4 macros in such a way
> that you get bad configure results and link errors.

I did not add the path to CPPFLAGS and LDFLAGS, but I did pass
--with-libiconv-prefix to configure, which I believe should have the
same effect.

Thank you very much for your help
Noah