Possible Bug in Gnulib

[Noah Lavine]

Hello Gnulib Developers,

I have found what I think is a bug in Gnulib. Unfortunately it takes a
bit of work to make it happen, but here's what I think is causing it:

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.

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.).
Because REPLACE_ICONV_UTF is not defined, rpl_iconv just becomes a
wrapper for the system's iconv. But doing the "#undef iconv" means
that rpl_iconv loses the "#define iconv libiconv" which happened in
the other library, so rpl_iconv attempts to link with a function with
the wrong name.

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? Or is there another solution that could be merged?

Thanks
Noah Lavine