https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93602
--- Comment #13 from Liviu Ionescu <ilg at livius dot net> --- I'm not sure what the best solution might be, but it looks like the configure script can detect the case when a distinct libiconv is encountered. In this case the only thing that is needed is an explicit reference in libstdc++ to libiconv, to instruct the loader. The other possible case, which is to ignore the separate libiconv is a bit more tricky, since it involves the order of processing the headers. If iconv.h is first encountered in the distinct libiconv, I don't know what we can do to ignore it and go to the next definition in the system headers. As I said, in my environment it was easy to uninstall libiconv, since none of the applications really needed the new version, the system one was enough, but there might be situations when this is not true, and in this case compiling gcc produces a shared library that requires applications using it to explicitly use -liconv. It would be interesting to check what happens when installing libiconv in a regular system, not a custom build environment like mine, is it picked by configure or the system one is used and the problem is somehow masked.
