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
