Re: Possible Bug in Gnulib

[Bruno Haible]

Hello Noah,

Thanks for your report. For a good report, you should also have stated
  - how you configured guile,
  - the precise error message that you got.
Without this info, I can only give general advice.

> I have two copies of libiconv on my computer (I run Mac OS X. One copy
> came with the computer, and one is from MacPorts). One of these
> defines the functions iconv, iconv_open, and iconv_close. The other
> one defines functions libiconv, libiconv_open, and libiconv_close,
> presumably so people can link with both libraries. The second copy
> does this via a preprocessor define, where the code actually defines
> iconv, etc., but earlier it does a "#define iconv libiconv", so all of
> those function names change.

This is the normal situation, once someone has installed GNU libiconv
on MacOS X. Nothing wrong here.

> I have been building GNU Guile, and as part of the configuration
> process it finds the second copy of libiconv, which has libiconv_open
> (and similar functions), and links with it. It also decides not to
> define REPLACE_ICONV_UTF, so Gnulib will not use its own iconv
> functions. Unfortunately, this causes a link error, because in
> Gnulib's iconv.c (also iconv_open.c and iconv_close.c), there is a
> "#undef iconv" in the function rpl_iconv (or rpl_iconv_open, etc.).

This is not expected. When GNU libiconv is installed, gnulib's
iconv_open.c should not be used. Take a look at m4/iconv_open.m4:
When GNU libiconv is found, ICONV_FLAVOR and REPLACE_ICONV_UTF should
not be defined in config.h.

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?

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 have fixed this problem for myself by commenting out the "#undef
> iconv" in those three files. Is this a solution that could be merged
> into Gnulib?

No, this is not a solution. Rather, it leads to an endless recursion
rpl_iconv_open -> rpl_iconv_open. The idiom to use instead would be
like in gnulib/lib/open.c. But it is not needed, because iconv_open.c
is not meant to be compiled in the first place, when GNU libiconv is
in use.

Bruno