https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93602
--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Liviu Ionescu from comment #0) > GCC 7.x and 8.x are fine, with the same build procedure the libstdc++ shared > library has no undefined references to libiconv. Have you checked that recently? Could libiconv have been installed since your last successful build? > To be noted that on a newer system (a Manjaro) where 9.2 is installed, > something similar happens: > > $ readelf -s /usr/lib/libstdc++.so | grep iconv > 24: 0000000000000000 0 FUNC GLOBAL DEFAULT UND > iconv_open@GLIBC_2.17 (44) > 125: 0000000000000000 0 FUNC GLOBAL DEFAULT UND > iconv_close@GLIBC_2.17 (44) > 174: 0000000000000000 0 FUNC GLOBAL DEFAULT UND iconv@GLIBC_2.17 > (44) > 9033: 0000000000000000 0 FUNC GLOBAL DEFAULT UND > iconv_open@@GLIBC_2.17 > 12636: 0000000000000000 0 FUNC GLOBAL DEFAULT UND > iconv_close@@GLIBC_2.17 > 14045: 0000000000000000 0 FUNC GLOBAL DEFAULT UND iconv@@GLIBC_2.17 > > $ ldd /usr/lib/libstdc++.so > linux-vdso.so.1 (0x0000007fbf4da000) > libm.so.6 => /usr/lib/libm.so.6 (0x0000007fbf1d6000) > libc.so.6 => /usr/lib/libc.so.6 (0x0000007fbf069000) > /usr/lib/ld-linux-aarch64.so.1 (0x0000007fbf4ac000) > libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x0000007fbf045000) No, that's not similar at all. This is the expected behaviour, where the iconv functions from glibc are used and so no additional library is needed. > It seems that in 9.x the build procedure expects the libiconv functionality > to be provided by one of the other system libraries. Again, I don't think anything changed in GCC 9. You might be able to use one of these options to control which iconv lib gets used: --with-libiconv-prefix[=DIR] search for libiconv in DIR/include and DIR/lib --without-libiconv-prefix don't search for libiconv in includedir and libdir --with-libiconv-type=TYPE type of library to search for (auto/static/shared)
