On Fri, 11 May 2007 15:09:34 +0400
Alexander Nasonov <alnsn@yandex.ru> wrote:

> I cannot compile x11/gtk2 on OpenBSD 4.1 because an execution of gtk-update-icon-cache --force <more args> fails with "GLib: Cannot convert message: Conversion from character set 'UTF-8' to '646' is not supported" message (it fails even without <more args> if executed manually).
> I found that glib2 function _g_locale_charset_raw calls nl_langinfo (CODESET) which returns "646".
> Code around nl_langinfo call looks like
> 
> # if HAVE_LANGINFO_CODESET
> 
>   /* Most systems support nl_langinfo (CODESET) nowadays.  */
>   codeset = nl_langinfo (CODESET);
> 
> # else
> 
>   /* On old systems which lack it, use setlocale or getenv.  */
>   ...
> 
> I disabled the first branch and ran LANG=en_US.ISO8859-1 gtk-update-icon-cache --force manually. It executed without an error but it still fails if I run LANG=en_US.ISO8859-1 bmake.
> Presumably, pkgsrc either clean LANG or set it to a portable value (which is good) but it makes me wonder how to patch the _g_locale_charset_raw function without hardcoding "en_US.ISO8859-1" into it.
> 
> BTW,
> cvs comment of the last version of nl_langinfo.c says that
> 
> > CODESET support. okay millert@, otto@
> > 
> > (not really useful for now, it mostly helps some programs which want
> > to use it, it will become useful when we have full 16 bits locale).
> 
> http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/locale/nl_langinfo.c
> 
> Does anybody has an idea how to fix this problem?
> -- 
> Alexander Nasonov

nl_langinfo(CODESET) returning 646 is not a problem.
Does this work?
$ echo "hello" | /usr/bin/iconv -f UTF-8 -t 646

If not, their iconv implementation is broken.
You can work around that by putting this in mk.conf:
_INCOMPAT_ICONV=   OpenBSD-*-*

This would force all packages to use gnu libiconv.

-T