On Sun, Apr 26, 2026 at 06:33:16PM +0200, Dennis Preiser wrote:
Release 2.3.2 (or rather, the configure script), which was released today, no longer recognizes libiconv, at least on the current version of macOS (26.4.1).
The m4/iconv.m4 file differs between the two versions, but I'm not familiar enough with it to figure out what´s going wrong.
I started having autopoint build issues with the stable-branch of mutt's installation of gettext files, so I needed to force install their newer configuration files to build and generate the tarballs for 2.3.2.
(We've already switched to grabbing the system versions in the master branch for 2.4.0)
The short story is that the newer gettext config files appear to have a test that the old version did not:
/* Test against macOS 14.4 bug: Failures are not distinguishable from
successful returns.
POSIX:2018 says: "The iconv() function shall ... return the number of
non-identical conversions performed."
But here, the conversion always does transliteration (the suffixes
"//TRANSLIT" and "//IGNORE" have no effect, nor does iconvctl()) and
does not report when it does a non-identical conversion. */
{
iconv_t cd_utf8_to_88591 = iconv_open ("ISO-8859-1", "UTF-8");
if (cd_utf8_to_88591 != (iconv_t)(-1))
{
static ICONV_CONST char input[] = "\305\202"; /* LATIN SMALL LETTER L
WITH STROKE */
char buf[10];
ICONV_CONST char *inptr = input;
size_t inbytesleft = strlen (input);
char *outptr = buf;
size_t outbytesleft = sizeof (buf);
size_t res = iconv (cd_utf8_to_88591,
&inptr, &inbytesleft,
&outptr, &outbytesleft);
/* Here:
With glibc, GNU libiconv (including macOS up to 13): res ==
(size_t)-1, errno == EILSEQ.
With musl libc, NetBSD 10, Solaris 11: res == 1.
With macOS 14.4: res == 0, output is "l". */
if (res == 0)
result |= 2;
iconv_close (cd_utf8_to_88591);
}
}
My guess is that this is failing on MacOS now. It's not surprising, I
guess. Mutt already has an open ticket about MacOS buggy iconv:
https://gitlab.com/muttmua/mutt/-/work_items/504#note_2982482398
You could try installing libiconv and using the --with-libiconv-prefix. See the ticket 504 for what worked for the reporter there.
Please let us know if that works, because I'm guessing we'll be getting a few other tickets about this.
-- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
