Re: AM_ICONV failures on minimal gconv glibc systems

[Kevin J. McCarthy]

On Tue, Nov 05, 2024 at 03:21:10PM +0100, Bruno Haible via Gnulib discussion 
list wrote:
> Kevin J. McCarthy wrote:
> > I wonder if that test in AM_ICONV is relevant or useful anymore.
>
> Yes, it is relevant. Some of the PO file from the Japanese translators
> at <https://translationproject.org/team/ja.html> still are in EUC-JP
> encoding. When the corresponding .mo files are made with a GNU gettext
> version older than 0.22, they are in EUC-JP as well, and when iconv()
> does not support EUC-JP, gettext() will not be able to process these
> translations.

I understand.  Note that I wasn't asking if EUC-JP was relevant, but if 
the test for a missing converter in HP-UX 11.11 was still relevant.  I 
noticed none of the other tests in AM_ICONV reported a problem if 
iconv_open() failed.

> > Is an
> > iconv with just the modules in "gconv-modules" considered "working"?
>
> No.

Okay, thank you for letting me know gnulib's stance on the issue.

> > None of the gconv modules
> > in gconv-modules-extra.conf (now split out since glibc-2.34) were
> > enabled.
>
> These are modules. Why do you think that you have no other choice than
> installing them all or installing none of them? Where do you get this
> black-and-white thinking from?

Uh... because I don't?

This isn't my system we're talking about here, though.  This was a 
report from someone trying to configure/compile my project on *their* 
minimal GNU/Linux system.  I'm pretty sure my email was clear about 
this.

I'd tend to think a person running on a minimal GNU/Linux system, 
without the extra conv modules enabled, wouldn't be surprised if there 
were some conversion issues, but that they might be surprised being told 
their iconv "didn't work".  That's why I politely asked here.

Thank you anyways, for your quick reply!

-Kevin