The chromium build does ignore USES=iconv settings. If converters/libiconv is installed the header ${LOCALBASE}/include/iconv.h is found before base iconv.h. Since LIBICONV_PLUG defines from USES/iconv.mk do not affect the chromium build system linking with -liconv was added in commit bfedd5f1f016c. Commit eb0137c80b62d enforced use of converters/libiconv by switching to iconv:wchar_t. However chromium builds successfully without libiconv installed when the modification of third_party/maldoca/BUILD.gn is removed. If base iconv is sufficient for chromium, then third_party/maldoca/BUILD.gn should simply define LIBICONV_PLUG like this: -- cut -- --- third_party/maldoca/BUILD.gn~ 2022-11-20 12:40:52.000000000 +0100 +++ third_party/maldoca/BUILD.gn 2022-11-21 09:48:50.410589000 +0100 @@ -18,6 +18,9 @@ config("maldoca_flags") { config("maldoca_chromium_config") { defines = [ "MALDOCA_IN_CHROMIUM" ] + if (is_bsd) { + defines += [ "LIBICONV_PLUG" ] + } } static_library("zlibwrapper") { -- cut -- Whether this approach works on OpenBSD, I do not know. It does work on FreeBSD. Maybe USES=iconv should removed completely since it does not work as intended for chromium build.
(In reply to gnikl from comment #0) Hi Yes you can build it with iconv support from libc on FreeBSD however the build will still link to libiconv because other dependencies will pull it in, so my opinion is that it is best not to mix the two and just keep using libiconv.
@comment #1 > Yes you can build it with iconv support from libc. Thank you for the confirmation. I just realized that my digging about the iconv addition was incorrect. Linking with iconv was added with commit a23dfd2 to base/BUILD.gn, commit bfedd5f moved the library reference to third_party/maldoca/BUILD.gn. > however the build will still link to libiconv because other dependencies will pull it in so my opinion is that it is best not to mix the two and just keep using libiconv. That is a reasonable stance. Still, I am not sure that chromium must link with iconv only because a dependency uses it. I checked the direct dependencies and the "culprit" is devel/glib20. Since libiconv is available because of glib20 the chromium build process simply picks it up. I believe avoiding the libiconv dependency with the help of LIBICONV_PLUG would be reasonable. However, the decision how iconv should be handled, is your call.