{"thread":{"id":"64599","subject":"t3900 failure on macOS, iconv(3) broken?","startedAt":"2025-12-08T22:59:19Z","lastAt":"2025-12-24T08:08:18Z","messageCount":45,"participants":["René Scharfe","Koji Nakamaru","Yee Cheng Chin","Collin Funk","Torsten Bögershausen","Carlo Marcelo Arenas Belón","brian m. carlson","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"531864","messageId":"53690064-1c98-40e9-8b9a-7ba6bee63703@web.de","threadId":"64599","inReplyTo":null,"subject":"t3900 failure on macOS, iconv(3) broken?","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2025-12-08T22:59:11Z","receivedAt":"2025-12-08T22:59:19Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Hi all,\n\nthree tests of t3900 fail on macOS 26.1 for me:\n\n not ok 17 - ISO-2022-JP should be shown in UTF-8 now\n not ok 25 - ISO-2022-JP should be shown in UTF-8 now\n not ok 38 - commit --fixup into ISO-2022-JP from UTF-8\n\nHere's the verbose output of the first one:\n\n----- snip! -----\nexpecting success of 3900.17 'ISO-2022-JP should be shown in UTF-8 now':\n compare_with ISO-2022-JP \"$TEST_DIRECTORY\"/t3900/2-UTF-8.txt\n\n--- /Users/x/src/git/t/t3900/2-UTF-8.txt 2024-10-01 19:43:24.605230684 +0000\n+++ current 2025-12-08 21:52:45.786161909 +0000\n@@ -1,4 +1,4 @@\n はれひほふ\n\n しているのが、いるので。\n-濱浜ほれぷりぽれまびぐりろへ。\n+濱浜ほれぷりぽれまび$0$j$m$X!#\nnot ok 17 - ISO-2022-JP should be shown in UTF-8 now\n#\n# compare_with ISO-2022-JP \"$TEST_DIRECTORY\"/t3900/2-UTF-8.txt\n#\n1..17\n----- snap! -----\n\ncompare_with runs git show to display a commit message, which in this\ncase here was encoded using ISO-2022-JP and is supposed to be reencoded\nto UTF-8, but git show only does that half-way -- the \"$0$j$m$X!#\" part\nis from the original ISO-2022-JP representation.\n\nThat botched conversion is done by utf8.c::reencode_string_iconv(). It\ncalls iconv(3) to do the actual work, initially with an output buffer of\nthe same size as the input. If the output needs more space the function\nenlarges the buffer and calls iconv(3) again.\n\niconv(3) won't tell us how much space it needs, but it will report what\npart it already managed to convert, so we can increase the buffer and\ncontinue from there. ISO-2022-JP has escape codes for switching between\ncharacter sets, so it's a stateful encoding. I guess the iconv(3) on my\nmachine forgets the state at the end of part one and then messes up part\ntwo.\n\nI only noticed now because I used to compile with NO_ICONV for some\nreason.\n\nIs anyone else seeing this breakage as well?\n\nHere's a patch that adds make variable ICONV_BREAKS. It avoids the\nbreakage when enabled, by starting over again instead of continuing.\n\nRené\n\n\n---\n Makefile | 6 ++++++\n utf8.c | 13 +++++++++++++\n 2 files changed, 19 insertions(+)\n\ndiff --git a/Makefile b/Makefile\nindex 6fc322ff88..cf8a0d3ee9 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -181,6 +181,9 @@ include shared.mak\n # byte-order mark (BOM) when writing UTF-16 or UTF-32 and always writes in\n # big-endian format.\n #\n+# Define ICONV_BREAKS if your iconv implementation cannot reliably\n+# break a string into valid substrings.\n+#\n # Define NO_DEFLATE_BOUND if your zlib does not have deflateBound. Define\n # ZLIB_NG if you want to use zlib-ng instead of zlib.\n #\n@@ -1836,6 +1839,9 @@ endif\n ifdef ICONV_OMITS_BOM\n \tBASIC_CFLAGS += -DICONV_OMITS_BOM\n endif\n+ifdef ICONV_BREAKS\n+\tBASIC_CFLAGS += -DICONV_BREAKS\n+endif\n ifdef NEEDS_LIBGEN\n \tEXTLIBS += -lgen\n endif\ndiff --git a/utf8.c b/utf8.c\nindex 35a0251939..ff0c541fbc 100644\n--- a/utf8.c\n+++ b/utf8.c\n@@ -515,6 +515,19 @@ char *reencode_string_iconv(const char *in, size_t insz, iconv_t conv,\n \t\t\tout = xrealloc(out, outalloc);\n \t\t\toutpos = out + sofar;\n \t\t\toutsz = outalloc - sofar - 1;\n+#ifdef ICONV_BREAKS\n+\t\t\t/*\n+\t\t\t * If iconv(3) messes up piecemeal conversions\n+\t\t\t * then restore the original pointers, sizes,\n+\t\t\t * and converter state, then retry converting\n+\t\t\t * the full string using the reallocated buffer.\n+\t\t\t */\n+\t\t\tinsz += (char *)cp - in;\n+\t\t\tcp = (iconv_ibp)in;\n+\t\t\toutpos = out + bom_len;\n+\t\t\toutsz = outalloc - bom_len - 1;\n+\t\t\ticonv(conv, NULL, NULL, NULL, NULL);\n+#endif\n \t\t}\n \t\telse {\n \t\t\t*outpos = '\\0';\n-- \n2.52.0\n\n"},{"id":"531882","messageId":"CAOTNsDzmGypKNOg-pFuW45qst+g8=LHQbdNAgtVYJvD8pxa6_Q@mail.gmail.com","threadId":"64599","inReplyTo":"53690064-1c98-40e9-8b9a-7ba6bee63703@web.de","subject":"Re: t3900 failure on macOS, iconv(3) broken?","fromName":"Koji Nakamaru","fromEmail":"koji.nakamaru@gree.net","sentAt":"2025-12-09T03:18:43Z","receivedAt":"2025-12-09T03:18:55Z","isPatch":false,"sender":{"key":"koji.nakamaru@gree.net","avatar":"https://avatars.githubusercontent.com/u/2645978?v=4"},"body":"On Tue, Dec 9, 2025 at 7:59 AM René Scharfe wrote:\n>\n> Hi all,\n>\n> three tests of t3900 fail on macOS 26.1 for me:\n>\n> not ok 17 - ISO-2022-JP should be shown in UTF-8 now\n> not ok 25 - ISO-2022-JP should be shown in UTF-8 now\n> not ok 38 - commit --fixup into ISO-2022-JP from UTF-8\n>\n> Here's the verbose output of the first one:\n>\n> ----- snip! -----\n> expecting success of 3900.17 'ISO-2022-JP should be shown in UTF-8 now':\n> compare_with ISO-2022-JP \"$TEST_DIRECTORY\"/t3900/2-UTF-8.txt\n>\n> --- /Users/x/src/git/t/t3900/2-UTF-8.txt 2024-10-01 19:43:24.605230684 +0000\n> +++ current 2025-12-08 21:52:45.786161909 +0000\n> @@ -1,4 +1,4 @@\n> はれひほふ\n>\n> しているのが、いるので。\n> -濱浜ほれぷりぽれまびぐりろへ。\n> +濱浜ほれぷりぽれまび$0$j$m$X!#\n> not ok 17 - ISO-2022-JP should be shown in UTF-8 now\n> #\n> # compare_with ISO-2022-JP \"$TEST_DIRECTORY\"/t3900/2-UTF-8.txt\n> #\n> 1..17\n> ----- snap! -----\n>\n> compare_with runs git show to display a commit message, which in this\n> case here was encoded using ISO-2022-JP and is supposed to be reencoded\n> to UTF-8, but git show only does that half-way -- the \"$0$j$m$X!#\" part\n> is from the original ISO-2022-JP representation.\n>\n> That botched conversion is done by utf8.c::reencode_string_iconv(). It\n> calls iconv(3) to do the actual work, initially with an output buffer of\n> the same size as the input. If the output needs more space the function\n> enlarges the buffer and calls iconv(3) again.\n>\n> iconv(3) won't tell us how much space it needs, but it will report what\n> part it already managed to convert, so we can increase the buffer and\n> continue from there. ISO-2022-JP has escape codes for switching between\n> character sets, so it's a stateful encoding. I guess the iconv(3) on my\n> machine forgets the state at the end of part one and then messes up part\n> two.\n>\n> I only noticed now because I used to compile with NO_ICONV for some\n> reason.\n>\n> Is anyone else seeing this breakage as well?\n>\n> Here's a patch that adds make variable ICONV_BREAKS. It avoids the\n> breakage when enabled, by starting over again instead of continuing.\n>\n> René\n>\n>\n> ---\n> Makefile | 6 ++++++\n> utf8.c | 13 +++++++++++++\n> 2 files changed, 19 insertions(+)\n>\n> diff --git a/Makefile b/Makefile\n> index 6fc322ff88..cf8a0d3ee9 100644\n> --- a/Makefile\n> +++ b/Makefile\n> @@ -181,6 +181,9 @@ include shared.mak\n> # byte-order mark (BOM) when writing UTF-16 or UTF-32 and always writes in\n> # big-endian format.\n> #\n> +# Define ICONV_BREAKS if your iconv implementation cannot reliably\n> +# break a string into valid substrings.\n> +#\n> # Define NO_DEFLATE_BOUND if your zlib does not have deflateBound. Define\n> # ZLIB_NG if you want to use zlib-ng instead of zlib.\n> #\n> @@ -1836,6 +1839,9 @@ endif\n> ifdef ICONV_OMITS_BOM\n> BASIC_CFLAGS += -DICONV_OMITS_BOM\n> endif\n> +ifdef ICONV_BREAKS\n> + BASIC_CFLAGS += -DICONV_BREAKS\n> +endif\n> ifdef NEEDS_LIBGEN\n> EXTLIBS += -lgen\n> endif\n> diff --git a/utf8.c b/utf8.c\n> index 35a0251939..ff0c541fbc 100644\n> --- a/utf8.c\n> +++ b/utf8.c\n> @@ -515,6 +515,19 @@ char *reencode_string_iconv(const char *in, size_t insz, iconv_t conv,\n> out = xrealloc(out, outalloc);\n> outpos = out + sofar;\n> outsz = outalloc - sofar - 1;\n> +#ifdef ICONV_BREAKS\n> + /*\n> + * If iconv(3) messes up piecemeal conversions\n> + * then restore the original pointers, sizes,\n> + * and converter state, then retry converting\n> + * the full string using the reallocated buffer.\n> + */\n> + insz += (char *)cp - in;\n> + cp = (iconv_ibp)in;\n> + outpos = out + bom_len;\n> + outsz = outalloc - bom_len - 1;\n> + iconv(conv, NULL, NULL, NULL, NULL);\n> +#endif\n> }\n> else {\n> *outpos = '\\0';\n> --\n> 2.52.0\n\nI checked a few cases:\n\n* macOS 15.7.2:\n * These tests fail.\n * These tests pass if your ICONV_BREAKS patch is applied or\n ICONVDIR=/opt/homebrew/Cellar/libiconv/1.18 is specified.\n* macOS 14.8.2\n * These tests pass.\n\nIt looks like the system iconv is broken on macOS 15 or later.\n\n--\nKoji Nakamaru\n"},{"id":"531883","messageId":"CAHTeOx-By55enMxt7YkCd6e=TbE7v+1ipN3wSFQc2n+9F_L7_Q@mail.gmail.com","threadId":"64599","inReplyTo":"CAOTNsDzmGypKNOg-pFuW45qst+g8=LHQbdNAgtVYJvD8pxa6_Q@mail.gmail.com","subject":"Re: t3900 failure on macOS, iconv(3) broken?","fromName":"Yee Cheng Chin","fromEmail":"ychin.macvim@gmail.com","sentAt":"2025-12-09T03:50:42Z","receivedAt":"2025-12-09T03:51:20Z","isPatch":false,"sender":{"key":"ychin.macvim@gmail.com","avatar":null},"body":"> * macOS 14.8.2\n> * These tests pass.\n> It looks like the system iconv is broken on macOS 15 or later.\n\nI'm a little surprised that these tests pass in macOS 14 with native\n(aka not from Homebrew) iconv. Apple replaced GNU iconv with a custom\nversion in macOS 14, which also caused a fair bit of breakages among\nother third-party software. I would have expected this CI test to\nbreak on macOS 14 unless this is a new behavior change / bug\nintroduced in macOS 15.\n\nBut yes, one way to fix it is to just provide the Homebrew GNU iconv\nvia ICONVDIR.\n"},{"id":"531884","messageId":"87sedkjo7w.fsf@gmail.com","threadId":"64599","inReplyTo":"CAHTeOx-By55enMxt7YkCd6e=TbE7v+1ipN3wSFQc2n+9F_L7_Q@mail.gmail.com","subject":"Re: t3900 failure on macOS, iconv(3) broken?","fromName":"Collin Funk","fromEmail":"collin.funk1@gmail.com","sentAt":"2025-12-09T04:03:47Z","receivedAt":"2025-12-09T04:03:49Z","isPatch":false,"sender":{"key":"collin.funk1@gmail.com","avatar":"https://avatars.githubusercontent.com/u/65689063?v=4"},"body":"Yee Cheng Chin writes:\n\n>> * macOS 14.8.2\n>> * These tests pass.\n>> It looks like the system iconv is broken on macOS 15 or later.\n>\n> I'm a little surprised that these tests pass in macOS 14 with native\n> (aka not from Homebrew) iconv. Apple replaced GNU iconv with a custom\n> version in macOS 14, which also caused a fair bit of breakages among\n> other third-party software. I would have expected this CI test to\n> break on macOS 14 unless this is a new behavior change / bug\n> introduced in macOS 15.\n>\n> But yes, one way to fix it is to just provide the Homebrew GNU iconv\n> via ICONVDIR.\n\nFWIW, the GNU iconv maintainer expressed frustration with the buggy\niconv implementation in macOS 14 [1]. He blamed Apple-specific patches\non FreeBSD's implementation.\n\nCollin\n\n[1] https://lists.gnu.org/archive/html/bug-gnulib/2024-05/msg00375.html\n"},{"id":"531900","messageId":"20251209163356.GA5762@tb-raspi4","threadId":"64599","inReplyTo":"53690064-1c98-40e9-8b9a-7ba6bee63703@web.de","subject":"Re: t3900 failure on macOS, iconv(3) broken?","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2025-12-09T16:33:57Z","receivedAt":"2025-12-09T16:34:00Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Mon, Dec 08, 2025 at 11:59:11PM +0100, René Scharfe wrote:\n> Hi all,\n> \n> three tests of t3900 fail on macOS 26.1 for me:\n> \n> not ok 17 - ISO-2022-JP should be shown in UTF-8 now\n> not ok 25 - ISO-2022-JP should be shown in UTF-8 now\n> not ok 38 - commit --fixup into ISO-2022-JP from UTF-8\n> \n> Here's the verbose output of the first one:\n> \n> ----- snip! -----\n> expecting success of 3900.17 'ISO-2022-JP should be shown in UTF-8 now':\n> compare_with ISO-2022-JP \"$TEST_DIRECTORY\"/t3900/2-UTF-8.txt\n> \n> --- /Users/x/src/git/t/t3900/2-UTF-8.txt 2024-10-01 19:43:24.605230684 +0000\n> +++ current 2025-12-08 21:52:45.786161909 +0000\n> @@ -1,4 +1,4 @@\n> はれひほふ\n> \n> しているのが、いるので。\n> -濱浜ほれぷりぽれまびぐりろへ。\n> +濱浜ほれぷりぽれまび$0$j$m$X!#\n> not ok 17 - ISO-2022-JP should be shown in UTF-8 now\n> #\n> # compare_with ISO-2022-JP \"$TEST_DIRECTORY\"/t3900/2-UTF-8.txt\n> #\n> 1..17\n> ----- snap! -----\n> \n> compare_with runs git show to display a commit message, which in this\n> case here was encoded using ISO-2022-JP and is supposed to be reencoded\n> to UTF-8, but git show only does that half-way -- the \"$0$j$m$X!#\" part\n> is from the original ISO-2022-JP representation.\n> \n> That botched conversion is done by utf8.c::reencode_string_iconv(). It\n> calls iconv(3) to do the actual work, initially with an output buffer of\n> the same size as the input. If the output needs more space the function\n> enlarges the buffer and calls iconv(3) again.\n> \n> iconv(3) won't tell us how much space it needs, but it will report what\n> part it already managed to convert, so we can increase the buffer and\n> continue from there. ISO-2022-JP has escape codes for switching between\n> character sets, so it's a stateful encoding. I guess the iconv(3) on my\n> machine forgets the state at the end of part one and then messes up part\n> two.\n> \n> I only noticed now because I used to compile with NO_ICONV for some\n> reason.\n> \n> Is anyone else seeing this breakage as well?\n> \n> Here's a patch that adds make variable ICONV_BREAKS. It avoids the\n> breakage when enabled, by starting over again instead of continuing.\n> \n> René\n> \n> \n> ---\n> Makefile | 6 ++++++\n> utf8.c | 13 +++++++++++++\n> 2 files changed, 19 insertions(+)\n> \n> diff --git a/Makefile b/Makefile\n> index 6fc322ff88..cf8a0d3ee9 100644\n> --- a/Makefile\n> +++ b/Makefile\n> @@ -181,6 +181,9 @@ include shared.mak\n> # byte-order mark (BOM) when writing UTF-16 or UTF-32 and always writes in\n> # big-endian format.\n> #\n> +# Define ICONV_BREAKS if your iconv implementation cannot reliably\n> +# break a string into valid substrings.\n> +#\n> # Define NO_DEFLATE_BOUND if your zlib does not have deflateBound. Define\n> # ZLIB_NG if you want to use zlib-ng instead of zlib.\n> #\n> @@ -1836,6 +1839,9 @@ endif\n> ifdef ICONV_OMITS_BOM\n> \tBASIC_CFLAGS += -DICONV_OMITS_BOM\n> endif\n> +ifdef ICONV_BREAKS\n> +\tBASIC_CFLAGS += -DICONV_BREAKS\n> +endif\n> ifdef NEEDS_LIBGEN\n> \tEXTLIBS += -lgen\n> endif\n> diff --git a/utf8.c b/utf8.c\n> index 35a0251939..ff0c541fbc 100644\n> --- a/utf8.c\n> +++ b/utf8.c\n> @@ -515,6 +515,19 @@ char *reencode_string_iconv(const char *in, size_t insz, iconv_t conv,\n> \t\t\tout = xrealloc(out, outalloc);\n> \t\t\toutpos = out + sofar;\n> \t\t\toutsz = outalloc - sofar - 1;\n> +#ifdef ICONV_BREAKS\n> +\t\t\t/*\n> +\t\t\t * If iconv(3) messes up piecemeal conversions\n> +\t\t\t * then restore the original pointers, sizes,\n> +\t\t\t * and converter state, then retry converting\n> +\t\t\t * the full string using the reallocated buffer.\n> +\t\t\t */\n> +\t\t\tinsz += (char *)cp - in;\n> +\t\t\tcp = (iconv_ibp)in;\n> +\t\t\toutpos = out + bom_len;\n> +\t\t\toutsz = outalloc - bom_len - 1;\n> +\t\t\ticonv(conv, NULL, NULL, NULL, NULL);\n> +#endif\n> \t\t}\n> \t\telse {\n> \t\t\t*outpos = '\\0';\n\n\nI am not sure, if I understand the second call to iconv(NULL....)\nHere is a slightly different patch.\nComments wellcome.\n\n\ndiff --git a/utf8.c b/utf8.c\nindex 35a0251939..b3c1dd2b59 100644\n--- a/utf8.c\n+++ b/utf8.c\n@@ -486,10 +486,11 @@ int utf8_fprintf(FILE *stream, const char *format, ...)\n char *reencode_string_iconv(const char *in, size_t insz, iconv_t conv,\n \t\t\t size_t bom_len, size_t *outsz_p)\n {\n-\tsize_t outsz, outalloc;\n+\tsize_t outsz, outalloc, originsz;\n \tchar *out, *outpos;\n \ticonv_ibp cp;\n \n+\toriginsz = insz;\n \toutsz = insz;\n \toutalloc = st_add(outsz, 1 + bom_len); /* for terminating NUL */\n \tout = xmalloc(outalloc);\n@@ -515,6 +516,17 @@ char *reencode_string_iconv(const char *in, size_t insz, iconv_t conv,\n \t\t\tout = xrealloc(out, outalloc);\n \t\t\toutpos = out + sofar;\n \t\t\toutsz = outalloc - sofar - 1;\n+#ifdef __APPLE__\n+\t\t\t/*\n+\t\t\t * Several version of iconv(3) mess up piecemeal conversions.\n+\t\t\t * Restore the original pointers, sizes,\n+\t\t\t * and converter state, then retry converting\n+\t\t\t * the full string using the reallocated buffer.\n+\t\t\t */\n+ insz = originsz;\n+ outpos = out + bom_len;\n+ cp = (iconv_ibp)in;\n+#endif\n \t\t}\n \t\telse {\n \t\t\t*outpos = '\\0';\n"},{"id":"531912","messageId":"51dc4ca7-61fd-42f7-8e72-a516a870e011@web.de","threadId":"64599","inReplyTo":"20251209163356.GA5762@tb-raspi4","subject":"Re: t3900 failure on macOS, iconv(3) broken?","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2025-12-09T19:35:23Z","receivedAt":"2025-12-09T19:35:32Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"On 12/9/25 5:33 PM, Torsten Bögershausen wrote:\n> On Mon, Dec 08, 2025 at 11:59:11PM +0100, René Scharfe wrote:\n>>\n>> diff --git a/utf8.c b/utf8.c\n>> index 35a0251939..ff0c541fbc 100644\n>> --- a/utf8.c\n>> +++ b/utf8.c\n>> @@ -515,6 +515,19 @@ char *reencode_string_iconv(const char *in, size_t insz, iconv_t conv,\n>> \t\t\tout = xrealloc(out, outalloc);\n>> \t\t\toutpos = out + sofar;\n>> \t\t\toutsz = outalloc - sofar - 1;\n>> +#ifdef ICONV_BREAKS\n>> +\t\t\t/*\n>> +\t\t\t * If iconv(3) messes up piecemeal conversions\n>> +\t\t\t * then restore the original pointers, sizes,\n>> +\t\t\t * and converter state, then retry converting\n>> +\t\t\t * the full string using the reallocated buffer.\n>> +\t\t\t */\n>> +\t\t\tinsz += (char *)cp - in;\n>> +\t\t\tcp = (iconv_ibp)in;\n>> +\t\t\toutpos = out + bom_len;\n>> +\t\t\toutsz = outalloc - bom_len - 1;\n>> +\t\t\ticonv(conv, NULL, NULL, NULL, NULL);\n>> +#endif\n>> \t\t}\n>> \t\telse {\n>> \t\t\t*outpos = '\\0';\n> \n> \n> I am not sure, if I understand the second call to iconv(NULL....)\n\nIt resets the state of the converter, e.g. the current code page of\nencodings that have multiple ones.\n\n> Here is a slightly different patch.\n> Comments wellcome.\n> \n> \n> diff --git a/utf8.c b/utf8.c\n> index 35a0251939..b3c1dd2b59 100644\n> --- a/utf8.c\n> +++ b/utf8.c\n> @@ -486,10 +486,11 @@ int utf8_fprintf(FILE *stream, const char *format, ...)\n> char *reencode_string_iconv(const char *in, size_t insz, iconv_t conv,\n> \t\t\t size_t bom_len, size_t *outsz_p)\n> {\n> -\tsize_t outsz, outalloc;\n> +\tsize_t outsz, outalloc, originsz;\n> \tchar *out, *outpos;\n> \ticonv_ibp cp;\n> \n> +\toriginsz = insz;\n> \toutsz = insz;\n> \toutalloc = st_add(outsz, 1 + bom_len); /* for terminating NUL */\n> \tout = xmalloc(outalloc);\n> @@ -515,6 +516,17 @@ char *reencode_string_iconv(const char *in, size_t insz, iconv_t conv,\n> \t\t\tout = xrealloc(out, outalloc);\n> \t\t\toutpos = out + sofar;\n> \t\t\toutsz = outalloc - sofar - 1;\n> +#ifdef __APPLE__\n> +\t\t\t/*\n> +\t\t\t * Several version of iconv(3) mess up piecemeal conversions.\n> +\t\t\t * Restore the original pointers, sizes,\n> +\t\t\t * and converter state, then retry converting\n> +\t\t\t * the full string using the reallocated buffer.\n> +\t\t\t */\n> + insz = originsz;\n> + outpos = out + bom_len;\n> + cp = (iconv_ibp)in;\n\nThis forgets to reset outsz and the converter state. With this patch\nt0028-working-tree-encoding.sh seems to get stuck in an endless loop.\n\n> +#endif\n> \t\t}\n> \t\telse {\n> \t\t\t*outpos = '\\0';\n\n"},{"id":"531913","messageId":"16efc726-34be-44f5-aa92-4e82b663ab3d@web.de","threadId":"64599","inReplyTo":"53690064-1c98-40e9-8b9a-7ba6bee63703@web.de","subject":"[PATCH] config.mak.uname: use iconv from Homebrew on macOS","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2025-12-09T19:35:34Z","receivedAt":"2025-12-09T19:35:37Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"The library function iconv(3) supplied with macOS versions 15.7.2\n(Sequoia) and 26.1 (Tahoe) is unreliable when doing conversions from\nISO-2022-JP to UTF-8 in multiple steps; t3900 reports this breakage:\n\n not ok 17 - ISO-2022-JP should be shown in UTF-8 now\n not ok 25 - ISO-2022-JP should be shown in UTF-8 now\n not ok 38 - commit --fixup into ISO-2022-JP from UTF-8\n\nAs a workaround, use libiconv from Homebrew, if available.\n\nHelped-by: Koji Nakamaru \nSigned-off-by: René Scharfe \n---\n config.mak.uname | 7 +++++++\n 1 file changed, 7 insertions(+)\n\ndiff --git a/config.mak.uname b/config.mak.uname\nindex 1691c6ae6e..1b305e38c6 100644\n--- a/config.mak.uname\n+++ b/config.mak.uname\n@@ -182,6 +182,13 @@ ifeq ($(uname_S),Darwin)\n endif\n endif\n \n+\tifeq ($(shell test -d /opt/homebrew/opt/libiconv/ && echo y),y)\n+\t\tICONVDIR ?= /opt/homebrew/opt/libiconv\n+\tendif\n+\tifeq ($(shell test -d /usr/local/opt/libiconv/ && echo y),y)\n+\t\tICONVDIR ?= /usr/local/opt/libiconv\n+\tendif\n+\n \tBASIC_LDFLAGS += -framework CoreServices\n endif\n ifeq ($(uname_S),SunOS)\n-- \n2.52.0\n"},{"id":"531917","messageId":"CAHTeOx-LFJVtNXrY-RfVUcAA_SjvK2310_xQ3skUEgKKQ6w57Q@mail.gmail.com","threadId":"64599","inReplyTo":"16efc726-34be-44f5-aa92-4e82b663ab3d@web.de","subject":"Re: [PATCH] config.mak.uname: use iconv from Homebrew on macOS","fromName":"Yee Cheng Chin","fromEmail":"ychin.macvim@gmail.com","sentAt":"2025-12-09T20:39:48Z","receivedAt":"2025-12-09T20:40:26Z","isPatch":true,"sender":{"key":"ychin.macvim@gmail.com","avatar":null},"body":"> + ifeq ($(shell test -d /usr/local/opt/libiconv/ && echo y),y)\n> + ICONVDIR ?= /usr/local/opt/libiconv\n> + endif\n\nOne thing to keep in mind is that x86-64 Homebrew (which is the one\nthat uses the /usr/local/ location) can be installed via Rosetta 2 on\nApple Silicon Macs for testing (I use it myself). In that case you\nwouldn't really want to use the /usr/local/opt/libiconv location. It\nwould be a somewhat niche case (the user has to be using Apple Silicon\nMac, and somehow has Rosetta Homebrew libiconv installed but not\nnative Homebrew libiconv), but could happen.\n"},{"id":"531919","messageId":"20251209212420.GA10149@tb-raspi4","threadId":"64599","inReplyTo":"51dc4ca7-61fd-42f7-8e72-a516a870e011@web.de","subject":"Re: t3900 failure on macOS, iconv(3) broken?","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2025-12-09T21:24:20Z","receivedAt":"2025-12-09T21:24:22Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Tue, Dec 09, 2025 at 08:35:23PM +0100, René Scharfe wrote:\n> On 12/9/25 5:33 PM, Torsten Bögershausen wrote:\n> > On Mon, Dec 08, 2025 at 11:59:11PM +0100, René Scharfe wrote:\n> >>\n[snip]\n> \n> This forgets to reset outsz and the converter state. With this patch\n> t0028-working-tree-encoding.sh seems to get stuck in an endless loop.\n\nThanks for testing.\nI did another test here\n(increase the outbuffer with only one byte per round, old MacOs)\nand yes, we need to reset iconv.\nBack to your patch. I think it is good to go further,\nwith one or 2 remarks, see TB\n \n\t\t\tout = xrealloc(out, outalloc);\n\t\t\t// TB: move into else outpos = out + sofar;\n\t\t\t// TB: move into else outsz = outalloc - sofar - 1;\n// TB: We have seen different breakages of apple iconv. Should we run the same code\n// on all versions of MacOs to be more future proof ?\n// and do we need a Makefile knob, if one, and only one platform is affected ?\n// I don't know\n#ifdef __APPLE__\nor\n#ifdef ICONV_BREAKS\n\t\t\t/*\n\t\t\t * If iconv(3) messes up piecemeal conversions\n\t\t\t * then restore the original pointers, sizes,\n\t\t\t * and converter state, then retry converting\n\t\t\t * the full string using the reallocated buffer.\n\t\t\t */\n\t\t\tinsz += (char *)cp - in; /* TB stumbled here: \"in\" is \"const char *\"\n\t\t\t And I didn't like the fact that insz is destroyed\n\t\t\t\t\t\t and needs to be restored. That is why I had a originsz\n\t\t\t\t\t\t (or szinorig ?)\n\t\t\tcp = (iconv_ibp)in;\n\t\t\toutpos = out + bom_len;\n\t\t\toutsz = outalloc - bom_len - 1;\n\t\t\ticonv(conv, NULL, NULL, NULL, NULL);\n#else\n\t\t\toutpos = out + sofar;\n\t\t\toutsz = outalloc - sofar - 1;\n#endif\n"},{"id":"531920","messageId":"2e9aef63-9da0-4635-90f8-fa3e16dddde5@web.de","threadId":"64599","inReplyTo":"CAHTeOx-LFJVtNXrY-RfVUcAA_SjvK2310_xQ3skUEgKKQ6w57Q@mail.gmail.com","subject":"Re: [PATCH] config.mak.uname: use iconv from Homebrew on macOS","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2025-12-09T21:27:19Z","receivedAt":"2025-12-09T21:27:27Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"On 12/9/25 9:39 PM, Yee Cheng Chin wrote:\n>> + ifeq ($(shell test -d /usr/local/opt/libiconv/ && echo y),y)\n>> + ICONVDIR ?= /usr/local/opt/libiconv\n>> + endif\n> \n> One thing to keep in mind is that x86-64 Homebrew (which is the one\n> that uses the /usr/local/ location) can be installed via Rosetta 2 on\n> Apple Silicon Macs for testing (I use it myself). In that case you\n> wouldn't really want to use the /usr/local/opt/libiconv location. It\n> would be a somewhat niche case (the user has to be using Apple Silicon\n> Mac, and somehow has Rosetta Homebrew libiconv installed but not\n> native Homebrew libiconv), but could happen.\n\nIf you have libiconv from both x86-64 and aarch64 Homebrew, the patch\nwill use the latter. If you only have the one from x86-64, it will\ntry to use that. For gettext we already do the same.\n\nYou can force using the slightly broken system iconv as before by\ncompiling by setting the make variable ICONVDIR manually, e.g. with\n\n$ make ICONVDIR=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr\n\nRené\n\n"},{"id":"531923","messageId":"22b1f482-2012-4ee9-bc12-1b2123ee0101@web.de","threadId":"64599","inReplyTo":"20251209212420.GA10149@tb-raspi4","subject":"Re: t3900 failure on macOS, iconv(3) broken?","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2025-12-09T22:25:32Z","receivedAt":"2025-12-09T22:25:35Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"On 12/9/25 10:24 PM, Torsten Bögershausen wrote:\n> On Tue, Dec 09, 2025 at 08:35:23PM +0100, René Scharfe wrote:\n>> On 12/9/25 5:33 PM, Torsten Bögershausen wrote:\n>>> On Mon, Dec 08, 2025 at 11:59:11PM +0100, René Scharfe wrote:\n>>>>\n> [snip]\n>>\n>> This forgets to reset outsz and the converter state. With this patch\n>> t0028-working-tree-encoding.sh seems to get stuck in an endless loop.\n> \n> Thanks for testing.\n> I did another test here\n> (increase the outbuffer with only one byte per round, old MacOs)\n> and yes, we need to reset iconv.\n> Back to your patch. I think it is good to go further,\n> with one or 2 remarks, see TB\n> \n> \t\t\tout = xrealloc(out, outalloc);\n> \t\t\t// TB: move into else outpos = out + sofar;\n> \t\t\t// TB: move into else outsz = outalloc - sofar - 1;\n> // TB: We have seen different breakages of apple iconv. Should we run the same code\n> // on all versions of MacOs to be more future proof ?\n> // and do we need a Makefile knob, if one, and only one platform is affected ?\n> // I don't know\n> #ifdef __APPLE__\n> or\n> #ifdef ICONV_BREAKS\n\nmacOS 14.8.2 reportedly doesn't have this particular issue, and I can\nonly hope that Apple will eventually fix that bug, so __APPLE__ seems a\nbit too broad.\n\nI'm also not thrilled about adding yet another build flag. The patch I\njust posted sidesteps the issue by using the existing ICONVDIR setting\nto use libiconv from Homebrew. We do that for gettext already, so it\nshould be fine..\n\n> \t\t\t/*\n> \t\t\t * If iconv(3) messes up piecemeal conversions\n> \t\t\t * then restore the original pointers, sizes,\n> \t\t\t * and converter state, then retry converting\n> \t\t\t * the full string using the reallocated buffer.\n> \t\t\t */\n> \t\t\tinsz += (char *)cp - in; /* TB stumbled here: \"in\" is \"const char *\"\n\nWe can add the const qualifier, but it won't affect the pointer\narithmetic. Perhaps casting to iconv_ibp would be more consistent?\n\n> \t\t\t And I didn't like the fact that insz is destroyed\n> \t\t\t\t\t\t and needs to be restored. That is why I had a originsz\n> \t\t\t\t\t\t (or szinorig ?)\n\nSure, storing the original value would work, but is slightly more effort\nthan subtracting the progress made so far. originsz would only be used\nif ICONV_BREAKS is defined, you'd need to declare it conditionally,\nadding yet more overhead.\n\n> \t\t\tcp = (iconv_ibp)in;\n> \t\t\toutpos = out + bom_len;\n> \t\t\toutsz = outalloc - bom_len - 1;\n> \t\t\ticonv(conv, NULL, NULL, NULL, NULL);\n> #else\n> \t\t\toutpos = out + sofar;\n> \t\t\toutsz = outalloc - sofar - 1;\n\nI'd like to keep buffer increase and rollback separate. Perhaps\nsplitting out the output buffer adjustment is worth it, though? Not\nsure. *shrug*\n\ndiff --git a/utf8.c b/utf8.c\nindex 35a0251939..c99243a63b 100644\n--- a/utf8.c\n+++ b/utf8.c\n@@ -513,6 +513,18 @@ char *reencode_string_iconv(const char *in, size_t insz, iconv_t conv,\n \t\t\tsofar = outpos - out;\n \t\t\toutalloc = st_add3(sofar, st_mult(insz, 2), 32);\n \t\t\tout = xrealloc(out, outalloc);\n+#ifdef ICONV_BREAKS\n+\t\t\t/*\n+\t\t\t * If iconv(3) messes up piecemeal conversions\n+\t\t\t * then restore the original pointers, sizes,\n+\t\t\t * and converter state, then retry converting\n+\t\t\t * the full string using the reallocated buffer.\n+\t\t\t */\n+\t\t\tinsz += cp - (iconv_ibp)in;\n+\t\t\tcp = (iconv_ibp)in;\n+\t\t\tsofar = bom_len;\n+\t\t\ticonv(conv, NULL, NULL, NULL, NULL);\n+#endif\n \t\t\toutpos = out + sofar;\n \t\t\toutsz = outalloc - sofar - 1;\n \t\t}\n\n> #endif\n\n"},{"id":"531959","messageId":"qnb77j3b5m6rfbzr3qhmwalo5lha4gqslvzqsfuq6zur74ze7j@wqriu4w7wbzw","threadId":"64599","inReplyTo":"16efc726-34be-44f5-aa92-4e82b663ab3d@web.de","subject":"Re: [PATCH] config.mak.uname: use iconv from Homebrew on macOS","fromName":"Carlo Marcelo Arenas Belón","fromEmail":"carenas@gmail.com","sentAt":"2025-12-10T11:17:59Z","receivedAt":"2025-12-10T11:18:02Z","isPatch":true,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"On Tue, Dec 09, 2025 at 08:35:34PM -0800, René Scharfe wrote:\n> The library function iconv(3) supplied with macOS versions 15.7.2\n> (Sequoia) and 26.1 (Tahoe) is unreliable when doing conversions from\n> ISO-2022-JP to UTF-8 in multiple steps; t3900 reports this breakage:\n> \n> not ok 17 - ISO-2022-JP should be shown in UTF-8 now\n> not ok 25 - ISO-2022-JP should be shown in UTF-8 now\n> not ok 38 - commit --fixup into ISO-2022-JP from UTF-8\n> \n> As a workaround, use libiconv from Homebrew, if available.\n\nWhile I think Homebrew libraries are usually better than the ones that\ncome with the system, there are reasons why you would prefer not linking\nwith them and therefore forcing Homebrew as a dependency of your binaries.\n\nOne particularly good reason is that if you are building a fat binary (\nuseful if you target recent macOS which still supports x86_64 but don't\nwant to distribute different versions per CPU type) then the system\nlibrary (even if broken) might be preferred.\n\nSlightly off topic, but should another patch that adds a `NO_HOMEBREW`\nMakefile flag similar to `NO_FINK` or `NO_APPLE_PORTS` be added to help\ndrive this?\n\nCarlo\n"},{"id":"531993","messageId":"20251210164256.GA30949@tb-raspi4","threadId":"64599","inReplyTo":"16efc726-34be-44f5-aa92-4e82b663ab3d@web.de","subject":"Re: [PATCH] config.mak.uname: use iconv from Homebrew on macOS","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2025-12-10T16:42:56Z","receivedAt":"2025-12-10T16:43:04Z","isPatch":true,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Tue, Dec 09, 2025 at 08:35:34PM +0100, René Scharfe wrote:\n> The library function iconv(3) supplied with macOS versions 15.7.2\n> (Sequoia) and 26.1 (Tahoe) is unreliable when doing conversions from\n> ISO-2022-JP to UTF-8 in multiple steps; t3900 reports this breakage:\n> \n> not ok 17 - ISO-2022-JP should be shown in UTF-8 now\n> not ok 25 - ISO-2022-JP should be shown in UTF-8 now\n> not ok 38 - commit --fixup into ISO-2022-JP from UTF-8\n> \n> As a workaround, use libiconv from Homebrew, if available.\n> \n> Helped-by: Koji Nakamaru \n> Signed-off-by: René Scharfe \n> ---\n> config.mak.uname | 7 +++++++\n> 1 file changed, 7 insertions(+)\n> \n> diff --git a/config.mak.uname b/config.mak.uname\n> index 1691c6ae6e..1b305e38c6 100644\n> --- a/config.mak.uname\n> +++ b/config.mak.uname\n> @@ -182,6 +182,13 @@ ifeq ($(uname_S),Darwin)\n> endif\n> endif\n> \n> +\tifeq ($(shell test -d /opt/homebrew/opt/libiconv/ && echo y),y)\n> +\t\tICONVDIR ?= /opt/homebrew/opt/libiconv\n> +\tendif\n> +\tifeq ($(shell test -d /usr/local/opt/libiconv/ && echo y),y)\n> +\t\tICONVDIR ?= /usr/local/opt/libiconv\n> +\tendif\n> +\n> \tBASIC_LDFLAGS += -framework CoreServices\n> endif\n> ifeq ($(uname_S),SunOS)\n> -- \n> 2.52.0\n> \n\n(Probaly a stupid question:) Does libiconv from homebrew provide UTF-8-MAC ?\nAnd does t3910 pass ?\n\nI just realized that I am building against libiconv from mac ports,\nsince years.\nDigging into the Makefile shows that we have a switch:\nNO_DARWIN_PORTS\n(and another one for FINK)\nDoes it make sense to have a switch here as well ?\n\n"},{"id":"531996","messageId":"3d756e59-ccbc-4f7e-8724-293a57c02028@web.de","threadId":"64599","inReplyTo":"20251210164256.GA30949@tb-raspi4","subject":"Re: [PATCH] config.mak.uname: use iconv from Homebrew on macOS","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2025-12-10T17:56:34Z","receivedAt":"2025-12-10T17:56:37Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"On 12/10/25 5:42 PM, Torsten Bögershausen wrote:\n> \n> (Probaly a stupid question:) Does libiconv from homebrew provide UTF-8-MAC ?\n\nIt has. Curiously it also has the alias UTF8-MAC, while it doesn't have\nUTF8 (but of course it has UTF-8).\n\n> And does t3910 pass ?\n\nYes, except for:\n\nnot ok 23 - handle existing decomposed filenames # TODO known breakage\n\n> I just realized that I am building against libiconv from mac ports,\n> since years.\n> Digging into the Makefile shows that we have a switch:\n> NO_DARWIN_PORTS\n> (and another one for FINK)\n> Does it make sense to have a switch here as well ?\nCarlo brought this up in the other thread as well, will reply there.\n\nRené\n\n"},{"id":"531997","messageId":"1b3509d7-e421-4136-a62c-de86213d65b2@web.de","threadId":"64599","inReplyTo":"qnb77j3b5m6rfbzr3qhmwalo5lha4gqslvzqsfuq6zur74ze7j@wqriu4w7wbzw","subject":"Re: [PATCH] config.mak.uname: use iconv from Homebrew on macOS","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2025-12-10T17:56:35Z","receivedAt":"2025-12-10T18:01:50Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"On 12/10/25 12:17 PM, Carlo Marcelo Arenas Belón wrote:\n> On Tue, Dec 09, 2025 at 08:35:34PM -0800, René Scharfe wrote:\n>> The library function iconv(3) supplied with macOS versions 15.7.2\n>> (Sequoia) and 26.1 (Tahoe) is unreliable when doing conversions from\n>> ISO-2022-JP to UTF-8 in multiple steps; t3900 reports this breakage:\n>>\n>> not ok 17 - ISO-2022-JP should be shown in UTF-8 now\n>> not ok 25 - ISO-2022-JP should be shown in UTF-8 now\n>> not ok 38 - commit --fixup into ISO-2022-JP from UTF-8\n>>\n>> As a workaround, use libiconv from Homebrew, if available.\n> \n> While I think Homebrew libraries are usually better than the ones that\n> come with the system, there are reasons why you would prefer not linking\n> with them and therefore forcing Homebrew as a dependency of your binaries.\n\nThe patch doesn't force, it just changes the default. You can overrule\nit by setting ICONVDIR explicitly, e.g. this will use the system's\nlibiconv:\n\n$ make ICONVDIR=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr\n\n> One particularly good reason is that if you are building a fat binary (\n> useful if you target recent macOS which still supports x86_64 but don't\n> want to distribute different versions per CPU type) then the system\n> library (even if broken) might be preferred.\n\nHow do you do that? By calling clang(1) with -arch x86_64 and -arch\narm64 and using lipo(1) on the results? Is this possible with the\ncurrent make files?\n\n> Slightly off topic, but should another patch that adds a `NO_HOMEBREW`\n> Makefile flag similar to `NO_FINK` or `NO_APPLE_PORTS` be added to help\n> drive this?\n\nSounds like a it could be useful to someone.\n\nI'm a bit puzzled that they are implemented in a Darwin section of\nMakefile. config.mak.uname would be a better place, no?\n\nRené\n\n"},{"id":"532006","messageId":"aTn92yqtSDyVoLgh@fruit.crustytoothpaste.net","threadId":"64599","inReplyTo":"16efc726-34be-44f5-aa92-4e82b663ab3d@web.de","subject":"Re: [PATCH] config.mak.uname: use iconv from Homebrew on macOS","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-12-10T23:10:19Z","receivedAt":"2025-12-10T23:10:21Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2025-12-09 at 19:35:34, René Scharfe wrote:\n> The library function iconv(3) supplied with macOS versions 15.7.2\n> (Sequoia) and 26.1 (Tahoe) is unreliable when doing conversions from\n> ISO-2022-JP to UTF-8 in multiple steps; t3900 reports this breakage:\n> \n> not ok 17 - ISO-2022-JP should be shown in UTF-8 now\n> not ok 25 - ISO-2022-JP should be shown in UTF-8 now\n> not ok 38 - commit --fixup into ISO-2022-JP from UTF-8\n> \n> As a workaround, use libiconv from Homebrew, if available.\n\nI like this solution, since it means when Apple ships their own Git\n(which doesn't use Homebrew), they will be incentivized to fix the\nproblem since the test fails.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"532008","messageId":"xmqqecp1hhi7.fsf@gitster.g","threadId":"64599","inReplyTo":"aTn92yqtSDyVoLgh@fruit.crustytoothpaste.net","subject":"Re: [PATCH] config.mak.uname: use iconv from Homebrew on macOS","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-12-11T02:36:16Z","receivedAt":"2025-12-11T02:36:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" writes:\n\n> On 2025-12-09 at 19:35:34, René Scharfe wrote:\n>> The library function iconv(3) supplied with macOS versions 15.7.2\n>> (Sequoia) and 26.1 (Tahoe) is unreliable when doing conversions from\n>> ISO-2022-JP to UTF-8 in multiple steps; t3900 reports this breakage:\n>> \n>> not ok 17 - ISO-2022-JP should be shown in UTF-8 now\n>> not ok 25 - ISO-2022-JP should be shown in UTF-8 now\n>> not ok 38 - commit --fixup into ISO-2022-JP from UTF-8\n>> \n>> As a workaround, use libiconv from Homebrew, if available.\n>\n> I like this solution, since it means when Apple ships their own Git\n> (which doesn't use Homebrew), they will be incentivized to fix the\n> problem since the test fails.\n\nWell, their build without Homebrew would fail with or without this\npatch, no? It is a good thing either way ;-)\n\nWill queue. Thanks.\n"},{"id":"532009","messageId":"xmqq7buthgq4.fsf@gitster.g","threadId":"64599","inReplyTo":"1b3509d7-e421-4136-a62c-de86213d65b2@web.de","subject":"Re: [PATCH] config.mak.uname: use iconv from Homebrew on macOS","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-12-11T02:53:07Z","receivedAt":"2025-12-11T02:53:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"René Scharfe writes:\n\n>> Slightly off topic, but should another patch that adds a `NO_HOMEBREW`\n>> Makefile flag similar to `NO_FINK` or `NO_APPLE_PORTS` be added to help\n>> drive this?\n>\n> Sounds like a it could be useful to someone.\n\nHmph, how? When you personally use fink or homebrew or whatever,\nbut are building binaries for others?\n\nI am looking at relevant parts of Makefile\n\n# Define NO_FINK if you are building on Darwin/Mac OS X, have Fink\n# installed in /sw, but don't want GIT to link against any libraries\n# installed there. If defined you may specify your own (or Fink's)\n# include directories and library directories by defining CFLAGS\n# and LDFLAGS appropriately.\n#\n# Define NO_DARWIN_PORTS if you are building on Darwin/Mac OS X,\n# have DarwinPorts installed in /opt/local, but don't want GIT to\n# link against any libraries installed there. If defined you may\n# specify your own (or DarwinPort's) include directories and\n# library directories by defining CFLAGS and LDFLAGS appropriately.\n\nand notice that /opt/local/ is mentioned for DarwinPorts. The patch\nthat started this thread talks about defaulting ICONVDIR to that of\nHomebrew if available, but the new code checks /opt/homebrew and\nthen /usr/local/ (and let it override it). Should the log message\nbe talking about DarwinPorts as well?\n\n\n As a workaround, set the default libiconv location to\n /opt/homebrew when the user has one from Homebrew, or\n to /opt/local when the user has one from MacPorts.\n\nor something along the line?\n\nBy the way, for macOS newbies (like me), I wonder if a patch like\nthe attached may help?\n\nThanks.\n\n\n----- >8 -----\nSubject: [PATCH] Makefile: help macOS novices by mentioning MacPorts\n\nSince Aug 2006, the DarwinPorts project renamed themselves as\nMacPorts. Those who are not intimately familiar with the Opensource\necosystem around macOS from olden days, the name DarwinPorts may not\nring a bell, even when they are using MacPorts.\n\nSigned-off-by: Junio C Hamano \n---\n Makefile | 3 ++-\n 1 file changed, 2 insertions(+), 1 deletion(-)\n\ndiff --git c/Makefile w/Makefile\nindex 7e0f77e298..be027218a5 100644\n--- c/Makefile\n+++ w/Makefile\n@@ -95,7 +95,8 @@ include shared.mak\n # and LDFLAGS appropriately.\n #\n # Define NO_DARWIN_PORTS if you are building on Darwin/Mac OS X,\n-# have DarwinPorts installed in /opt/local, but don't want GIT to\n+# have DarwinPorts (which is an old name for MacPorts) installed\n+# in /opt/local, but don't want GIT to\n # link against any libraries installed there. If defined you may\n # specify your own (or DarwinPort's) include directories and\n # library directories by defining CFLAGS and LDFLAGS appropriately.\n\n\n \n\n"},{"id":"532039","messageId":"xmqqfr9he3v7.fsf@gitster.g","threadId":"64599","inReplyTo":"xmqqecp1hhi7.fsf@gitster.g","subject":"Re: [PATCH] config.mak.uname: use iconv from Homebrew on macOS","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-12-11T09:59:08Z","receivedAt":"2025-12-11T09:59:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> \"brian m. carlson\" writes:\n>\n>> On 2025-12-09 at 19:35:34, René Scharfe wrote:\n>>> The library function iconv(3) supplied with macOS versions 15.7.2\n>>> (Sequoia) and 26.1 (Tahoe) is unreliable when doing conversions from\n>>> ISO-2022-JP to UTF-8 in multiple steps; t3900 reports this breakage:\n>>> \n>>> not ok 17 - ISO-2022-JP should be shown in UTF-8 now\n>>> not ok 25 - ISO-2022-JP should be shown in UTF-8 now\n>>> not ok 38 - commit --fixup into ISO-2022-JP from UTF-8\n>>> \n>>> As a workaround, use libiconv from Homebrew, if available.\n>>\n>> I like this solution, since it means when Apple ships their own Git\n>> (which doesn't use Homebrew), they will be incentivized to fix the\n>> problem since the test fails.\n>\n> Well, their build without Homebrew would fail with or without this\n> patch, no? It is a good thing either way ;-)\n\nDoes anybody know if a purely vanilla installation of macOS, without\nany third-party software collection like homebrewk, is supposed to\nbe even serviceable? That is, if somebody at Apple builds a version\nof Git that they ship themselves (they do, don't they?), can they\nuntar the latest tarball on a vanilla macOS box, type \"make test\",\nand expect it to pass?\n\nAre there folks in the audience, with stakes in having such a thing\nworking, whether working for Apple or not, listening? Can you\nperhaps help us to get to that point? The effort would involve (1)\nfixing bugs in their own system, like this iconv issue, (2) marking\nsome part of the expectation unachievable by sprinkling !macOS\nprerequisite in our tests, if bugs in their system like iconv cannot\nbe fixed for some reason, and (3) once we get to the point of\npassing all tests, have a CI job to make sure we will stay clean.\n\nOr do folks in macOS ecosystem already do something similar but\noutside this mailing list, and it is useless for me to attempt to\nhelp them?\n\n"},{"id":"532042","messageId":"vxi7g67b322sre7ylkcfwujf3n34j3f5vtpl62zhrj4ds6f675@hyyh2rxhaib6","threadId":"64599","inReplyTo":"xmqq7buthgq4.fsf@gitster.g","subject":"Re: [PATCH] config.mak.uname: use iconv from Homebrew on macOS","fromName":"Carlo Marcelo Arenas Belón","fromEmail":"carenas@gmail.com","sentAt":"2025-12-11T11:17:03Z","receivedAt":"2025-12-11T11:17:06Z","isPatch":true,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"On Thu, Dec 11, 2025 at 11:53:07AM -0800, Junio C Hamano wrote:\n> René Scharfe writes:\n> \n> >> Slightly off topic, but should another patch that adds a `NO_HOMEBREW`\n> >> Makefile flag similar to `NO_FINK` or `NO_APPLE_PORTS` be added to help\n> >> drive this?\n> >\n> > Sounds like a it could be useful to someone.\n> \n> Hmph, how? When you personally use fink or homebrew or whatever,\n> but are building binaries for others?\n\ncorrect; I think microsoft's git keeps a patch to do something like\nthat for other dependencies already.\n\nthe OS (at least up to the point were they drop support for Intel)\nhas EVERYTHING compiled as a fat binary.\n\n% file /bin/ls\n/bin/ls: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]\n/bin/ls (for architecture x86_64):\tMach-O 64-bit executable x86_64\n/bin/ls (for architecture arm64e):\tMach-O 64-bit executable arm64e\n\nit gets even more interesting when you look at the older releases\nthat also include support for 32-bit Intel/ARM/PowerPC.\n\n> I am looking at relevant parts of Makefile\n> \n> # Define NO_FINK if you are building on Darwin/Mac OS X, have Fink\n> # installed in /sw, but don't want GIT to link against any libraries\n> # installed there. If defined you may specify your own (or Fink's)\n> # include directories and library directories by defining CFLAGS\n> # and LDFLAGS appropriately.\n> #\n> # Define NO_DARWIN_PORTS if you are building on Darwin/Mac OS X,\n> # have DarwinPorts installed in /opt/local, but don't want GIT to\n> # link against any libraries installed there. If defined you may\n> # specify your own (or DarwinPort's) include directories and\n> # library directories by defining CFLAGS and LDFLAGS appropriately.\n> \n> and notice that /opt/local/ is mentioned for DarwinPorts. The patch\n> that started this thread talks about defaulting ICONVDIR to that of\n> Homebrew if available, but the new code checks /opt/homebrew and\n> then /usr/local/ (and let it override it). Should the log message\n> be talking about DarwinPorts as well?\n> \n> \n> As a workaround, set the default libiconv location to\n> /opt/homebrew when the user has one from Homebrew, or\n> to /opt/local when the user has one from MacPorts.\n> \n> or something along the line?\n\nSince the original patch was only meant to help with Homebrew it\nmight not be worth mentioning the OTHER package managers IMHO.\n\nI am hoping also there might be someone else that might be using\nPKGSRC (usually in NetBSD) or even gentoo's portage for that.\n\nBut I agree with you that the way we assume Homebrew is THE user\npackage manager that the OS uses might be problematic long term.\n\n> By the way, for macOS newbies (like me), I wonder if a patch like\n> the attached may help?\n\nDid I read that correctly and you had found yourself forced into\nrunning macOS at least somewhere?\n\n> ----- >8 -----\n> Subject: [PATCH] Makefile: help macOS novices by mentioning MacPorts\n> \n> Since Aug 2006, the DarwinPorts project renamed themselves as\n> MacPorts. Those who are not intimately familiar with the Opensource\n> ecosystem around macOS from olden days, the name DarwinPorts may not\n> ring a bell, even when they are using MacPorts.\n> \n> Signed-off-by: Junio C Hamano \n> ---\n> Makefile | 3 ++-\n> 1 file changed, 2 insertions(+), 1 deletion(-)\n> \n> diff --git c/Makefile w/Makefile\n> index 7e0f77e298..be027218a5 100644\n> --- c/Makefile\n> +++ w/Makefile\n> @@ -95,7 +95,8 @@ include shared.mak\n> # and LDFLAGS appropriately.\n> #\n> # Define NO_DARWIN_PORTS if you are building on Darwin/Mac OS X,\n> -# have DarwinPorts installed in /opt/local, but don't want GIT to\n> +# have DarwinPorts (which is an old name for MacPorts) installed\n> +# in /opt/local, but don't want GIT to\n> # link against any libraries installed there. If defined you may\n> # specify your own (or DarwinPort's) include directories and\n> # library directories by defining CFLAGS and LDFLAGS appropriately.\n> \n\nIt took years, but I woukd be honoured to provide a:\n\nReviewed-by: Carlo Marcelo Arenas Belon \n\nCarlo\n\nPS. Sorry about the mispelling of my own name, but had yet to figure\nout how to configure UTF-8 correctly in my latest setup.\n"},{"id":"532047","messageId":"5308d067-6c3c-4694-a30d-86a561704e6c@web.de","threadId":"64599","inReplyTo":"xmqqfr9he3v7.fsf@gitster.g","subject":"Re: [PATCH] config.mak.uname: use iconv from Homebrew on macOS","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2025-12-11T14:34:00Z","receivedAt":"2025-12-11T14:34:11Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"On 12/11/25 10:59 AM, Junio C Hamano wrote:\n> \n> Does anybody know if a purely vanilla installation of macOS, without\n> any third-party software collection like homebrewk, is supposed to\n> be even serviceable? That is, if somebody at Apple builds a version\n> of Git that they ship themselves (they do, don't they?), can they\n> untar the latest tarball on a vanilla macOS box, type \"make test\",\n> and expect it to pass?\n\nIt seems so. https://opensource.apple.com/releases/ points to\nhttps://github.com/apple-oss-distributions/Git. The latest tag is close\nto v2.50.1:\n\n$ git diff --stat -w v2.50.1 Git-155:src/git ':(exclude)*.git*'\n Documentation/fsck-msgids.adoc | 12 ------------\n Makefile | 1 +\n attr.c | 11 +++++++++++\n builtin/help.c | 3 +--\n config.c | 13 +++++++++++++\n config.h | 3 +++\n generate-python.sh | 2 ++\n git-mergetool--lib.sh | 6 ++++--\n git-svn.perl | 30 ++++++++++++++++++++++++++++++\n http.c | 2 ++\n perl/header_templates/runtime_prefix.template.pl | 25 +++++++++++++++++++++++++\n sha1collisiondetection | 1 -\n t/t4014-format-patch.sh | 3 +--\n t/test-lib.sh | 3 +++\n usage.c | 20 ++++++++++++++++++++\n 15 files changed, 116 insertions(+), 19 deletions(-)\n\nTheir top-level Makefile sets NO_GETTEXT, NO_FINK and NO_DARWIN_PORTS.\n\nRené\n\n"},{"id":"532055","messageId":"xmqq7buse906.fsf@gitster.g","threadId":"64599","inReplyTo":"vxi7g67b322sre7ylkcfwujf3n34j3f5vtpl62zhrj4ds6f675@hyyh2rxhaib6","subject":"Re: [PATCH] config.mak.uname: use iconv from Homebrew on macOS","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-12-12T02:20:25Z","receivedAt":"2025-12-12T02:20:28Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carlo Marcelo Arenas Belón writes:\n\n>> I am looking at relevant parts of Makefile\n>> \n>> # Define NO_FINK if you are building on Darwin/Mac OS X, have Fink\n>> # installed in /sw, but don't want GIT to link against any libraries\n>> # installed there. If defined you may specify your own (or Fink's)\n>> # include directories and library directories by defining CFLAGS\n>> # and LDFLAGS appropriately.\n>> #\n>> # Define NO_DARWIN_PORTS if you are building on Darwin/Mac OS X,\n>> # have DarwinPorts installed in /opt/local, but don't want GIT to\n>> # link against any libraries installed there. If defined you may\n>> # specify your own (or DarwinPort's) include directories and\n>> # library directories by defining CFLAGS and LDFLAGS appropriately.\n>> \n>> and notice that /opt/local/ is mentioned for DarwinPorts. The patch\n>> that started this thread talks about defaulting ICONVDIR to that of\n>> Homebrew if available, but the new code checks /opt/homebrew and\n>> then /usr/local/ (and let it override it). Should the log message\n>> be talking about DarwinPorts as well?\n>> \n>> As a workaround, set the default libiconv location to\n>> /opt/homebrew when the user has one from Homebrew, or\n>> to /opt/local when the user has one from MacPorts.\n>> \n>> or something along the line?\n>\n> Since the original patch was only meant to help with Homebrew it\n> might not be worth mentioning the OTHER package managers IMHO.\n\nMeaing that the original patch should have included only\n/opt/homebrew and we should drop the part about /opt/local?\n\nOr do you mean Homebrew may use /opt/local instead of /opt/homebrew\nand both parts of the original patch are needed to give coverage to\ndifferent Homebrew installations?\n\nIf the latter, perhaps we can say something in the proposed commit\nlog message to explain having both /opt/{homebrew,local}/ is\nnecessary (and why)?\n\n>> By the way, for macOS newbies (like me), I wonder if a patch like\n>> the attached may help?\n>\n> Did I read that correctly and you had found yourself forced into\n> running macOS at least somewhere?\n\nNo, but I do look at CI output that includes macOS jobs every day.\n"},{"id":"532057","messageId":"xmqqv7iccqy3.fsf@gitster.g","threadId":"64599","inReplyTo":"5308d067-6c3c-4694-a30d-86a561704e6c@web.de","subject":"Re: [PATCH] config.mak.uname: use iconv from Homebrew on macOS","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-12-12T03:35:48Z","receivedAt":"2025-12-12T03:35:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"René Scharfe writes:\n\n> On 12/11/25 10:59 AM, Junio C Hamano wrote:\n>> \n>> Does anybody know if a purely vanilla installation of macOS, without\n>> any third-party software collection like homebrewk, is supposed to\n>> be even serviceable? That is, if somebody at Apple builds a version\n>> of Git that they ship themselves (they do, don't they?), can they\n>> untar the latest tarball on a vanilla macOS box, type \"make test\",\n>> and expect it to pass?\n>\n> It seems so. https://opensource.apple.com/releases/ points to\n> https://github.com/apple-oss-distributions/Git. The latest tag is close\n> to v2.50.1:\n>\n> $ git diff --stat -w v2.50.1 Git-155:src/git ':(exclude)*.git*'\n> Documentation/fsck-msgids.adoc | 12 ------------\n> Makefile | 1 +\n> attr.c | 11 +++++++++++\n> builtin/help.c | 3 +--\n> config.c | 13 +++++++++++++\n> config.h | 3 +++\n> generate-python.sh | 2 ++\n> git-mergetool--lib.sh | 6 ++++--\n> git-svn.perl | 30 ++++++++++++++++++++++++++++++\n> http.c | 2 ++\n> perl/header_templates/runtime_prefix.template.pl | 25 +++++++++++++++++++++++++\n> sha1collisiondetection | 1 -\n> t/t4014-format-patch.sh | 3 +--\n> t/test-lib.sh | 3 +++\n> usage.c | 20 ++++++++++++++++++++\n> 15 files changed, 116 insertions(+), 19 deletions(-)\n>\n> Their top-level Makefile sets NO_GETTEXT, NO_FINK and NO_DARWIN_PORTS.\n\nThanks.\n"},{"id":"532063","messageId":"3ac57efd-a0c6-49da-b63d-825d97b3821c@web.de","threadId":"64599","inReplyTo":"xmqq7buse906.fsf@gitster.g","subject":"Re: [PATCH] config.mak.uname: use iconv from Homebrew on macOS","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2025-12-12T09:16:02Z","receivedAt":"2025-12-12T09:16:11Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"On 12/12/25 3:20 AM, Junio C Hamano wrote:\n> Carlo Marcelo Arenas Belón writes:\n> \n>>> I am looking at relevant parts of Makefile\n>>>\n>>> # Define NO_FINK if you are building on Darwin/Mac OS X, have Fink\n>>> # installed in /sw, but don't want GIT to link against any libraries\n>>> # installed there. If defined you may specify your own (or Fink's)\n>>> # include directories and library directories by defining CFLAGS\n>>> # and LDFLAGS appropriately.\n>>> #\n>>> # Define NO_DARWIN_PORTS if you are building on Darwin/Mac OS X,\n>>> # have DarwinPorts installed in /opt/local, but don't want GIT to\n>>> # link against any libraries installed there. If defined you may\n>>> # specify your own (or DarwinPort's) include directories and\n>>> # library directories by defining CFLAGS and LDFLAGS appropriately.\n>>>\n>>> and notice that /opt/local/ is mentioned for DarwinPorts. The patch\n>>> that started this thread talks about defaulting ICONVDIR to that of\n>>> Homebrew if available, but the new code checks /opt/homebrew and\n>>> then /usr/local/ (and let it override it). Should the log message\n>>> be talking about DarwinPorts as well?\n>>>\n>>> As a workaround, set the default libiconv location to\n>>> /opt/homebrew when the user has one from Homebrew, or\n>>> to /opt/local when the user has one from MacPorts.\n>>>\n>>> or something along the line?\n>>\n>> Since the original patch was only meant to help with Homebrew it\n>> might not be worth mentioning the OTHER package managers IMHO.\n> \n> Meaing that the original patch should have included only\n> /opt/homebrew and we should drop the part about /opt/local?\n> \n> Or do you mean Homebrew may use /opt/local instead of /opt/homebrew\n> and both parts of the original patch are needed to give coverage to\n> different Homebrew installations?\n> \n> If the latter, perhaps we can say something in the proposed commit\n> log message to explain having both /opt/{homebrew,local}/ is\n> necessary (and why)?\n\nHomebrew uses /opt/homebrew for Apple Silicon and /usr/local for macOS\nIntel (https://docs.brew.sh/Installation).\n\nMacPorts née DarwinPorts uses /opt/local\n(https://trac.macports.org/wiki/FAQ#defaultprefix).\n\nFink uses /opt/sw\n(https://www.finkproject.org/faq/general.php?phpLang=en#why-sw).\n\nThe patch tries both Homebrew directories, the newer Apple Silicon\none first.\n\nRené\n\n"},{"id":"532064","messageId":"mmbxugkhxhioxdx46yz47syj2cvj6cfukmzfxtdx5yqolmsc65@ftfrd26tenco","threadId":"64599","inReplyTo":"3ac57efd-a0c6-49da-b63d-825d97b3821c@web.de","subject":"Re: [PATCH] config.mak.uname: use iconv from Homebrew on macOS","fromName":"Carlo Marcelo Arenas Belón","fromEmail":"carenas@gmail.com","sentAt":"2025-12-12T10:02:12Z","receivedAt":"2025-12-12T10:02:14Z","isPatch":true,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"On Fri, Dec 12, 2025 at 10:16:02AM -0800, René Scharfe wrote:\n> On 12/12/25 3:20 AM, Junio C Hamano wrote:\n> > Carlo Marcelo Arenas Belón writes:\n> > \n> >>> I am looking at relevant parts of Makefile\n> >>>\n> >>> # Define NO_FINK if you are building on Darwin/Mac OS X, have Fink\n> >>> # installed in /sw, but don't want GIT to link against any libraries\n> >>> # installed there. If defined you may specify your own (or Fink's)\n> >>> # include directories and library directories by defining CFLAGS\n> >>> # and LDFLAGS appropriately.\n> >>> #\n> >>> # Define NO_DARWIN_PORTS if you are building on Darwin/Mac OS X,\n> >>> # have DarwinPorts installed in /opt/local, but don't want GIT to\n> >>> # link against any libraries installed there. If defined you may\n> >>> # specify your own (or DarwinPort's) include directories and\n> >>> # library directories by defining CFLAGS and LDFLAGS appropriately.\n> >>>\n> >>> and notice that /opt/local/ is mentioned for DarwinPorts. The patch\n> >>> that started this thread talks about defaulting ICONVDIR to that of\n> >>> Homebrew if available, but the new code checks /opt/homebrew and\n> >>> then /usr/local/ (and let it override it). Should the log message\n> >>> be talking about DarwinPorts as well?\n> >>>\n> >>> As a workaround, set the default libiconv location to\n> >>> /opt/homebrew when the user has one from Homebrew, or\n> >>> to /opt/local when the user has one from MacPorts.\n> >>>\n> >>> or something along the line?\n> >>\n> >> Since the original patch was only meant to help with Homebrew it\n> >> might not be worth mentioning the OTHER package managers IMHO.\n> > \n> > Meaing that the original patch should have included only\n> > /opt/homebrew and we should drop the part about /opt/local?\n> > \n> > Or do you mean Homebrew may use /opt/local instead of /opt/homebrew\n> > and both parts of the original patch are needed to give coverage to\n> > different Homebrew installations?\n> > \n> > If the latter, perhaps we can say something in the proposed commit\n> > log message to explain having both /opt/{homebrew,local}/ is\n> > necessary (and why)?\n> \n> Homebrew uses /opt/homebrew for Apple Silicon and /usr/local for macOS\n> Intel (https://docs.brew.sh/Installation).\n\nnot always; you can install it anywhere you want, and indeed you might\nneed to (like I do) when given access to a remote instance of macOS\nthat you have no root on.\n\nas you mentioned too, these settings are in the wrong Makefile (mainly\nbecause they predate the split and creation of config.mak.uname) but\nalso because they are TOO peculiar of a case to be inside the latter\nand because changing that might break some setups.\n\nFWIW the use of \"user\" package managers is not unique to macOS. all\nother UNIX have them as well, but luckily they are far less popular\nand their use is declining (ex: AIX and Solaris the main two that remain\nonce HPUX is sunset, and not counting NONSTOP which we support directly)\n\nCarlo\n"},{"id":"532066","messageId":"422eb238-5c75-4629-86d4-1a3c1ba2521c@web.de","threadId":"64599","inReplyTo":"53690064-1c98-40e9-8b9a-7ba6bee63703@web.de","subject":"Re: t3900 failure on macOS, iconv(3) broken?","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2025-12-12T10:40:41Z","receivedAt":"2025-12-12T10:40:48Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"On 12/8/25 11:59 PM, René Scharfe wrote:\n> \n> I only noticed now because I used to compile with NO_ICONV for some\n> reason.\nNope, NO_ICONV does not work on macOS because compat/precompose_utf8.c\nreferences reencode_string_iconv() and there's no (easy) way to disable\nPRECOMPOSE_UNICODE. I actually used ICONVDIR before, had forgotten\nabout it, got confused about it after deleting my config.mak and my\nbackup copy didn't set ICONVDIR, either. Odd. Anyway, just wanted to\ncorrect the false impression that compiling with NO_ICONV on macOS would\nbe possible without source changes.\n\nRené\n\n"},{"id":"532070","messageId":"xmqqms3nc0mj.fsf_-_@gitster.g","threadId":"64599","inReplyTo":"3ac57efd-a0c6-49da-b63d-825d97b3821c@web.de","subject":"Re* [PATCH] config.mak.uname: use iconv from Homebrew on macOS","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-12-12T13:04:20Z","receivedAt":"2025-12-12T13:04:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"René Scharfe writes:\n\n>> If the latter, perhaps we can say something in the proposed commit\n>> log message to explain having both /opt/{homebrew,local}/ is\n>> necessary (and why)?\n>\n> Homebrew uses /opt/homebrew for Apple Silicon and /usr/local for macOS\n> Intel (https://docs.brew.sh/Installation).\n\nYup, that would be perfect. Concisely explains why /opt/homebrew\nand /usr/local are used in the patch.\n\nI presume these are the default for homebrew and users could change\nthem to what suit their needs, but even then, what you did in your\npatch is good; we are merely setting the appropriate defaults, and\nthose who customize these paths know that they must customize these\npaths not just when they install homebrew but when building other\nsoftware packages like ours.\n\n> Fink uses /opt/sw\n> (https://www.finkproject.org/faq/general.php?phpLang=en#why-sw).\n\nPerhaps they have a symlink or something from /sw to /opt/sw, then,\nas our Makefile only talks about /sw and /opt/sw\n\nThanks.\n"},{"id":"532073","messageId":"4b752020-036e-4f1b-9963-a54f361ef0fd@web.de","threadId":"64599","inReplyTo":"xmqqms3nc0mj.fsf_-_@gitster.g","subject":"Re: [PATCH] config.mak.uname: use iconv from Homebrew on macOS","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2025-12-12T13:48:04Z","receivedAt":"2025-12-12T13:48:15Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"On 12/12/25 2:04 PM, Junio C Hamano wrote:\n> René Scharfe writes:\n> \n>> Fink uses /opt/sw\n>> (https://www.finkproject.org/faq/general.php?phpLang=en#why-sw).\n> \n> Perhaps they have a symlink or something from /sw to /opt/sw, then,\n> as our Makefile only talks about /sw and /opt/sw\nHmm, they changed that in https://github.com/fink/fink/commit/db958e12bf\nsix years ago. Apparently we didn't get the memo.\n\nRené\n\n"},{"id":"532105","messageId":"xmqqikebb77n.fsf@gitster.g","threadId":"64599","inReplyTo":"4b752020-036e-4f1b-9963-a54f361ef0fd@web.de","subject":"Re: [PATCH] config.mak.uname: use iconv from Homebrew on macOS","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-12-12T23:39:40Z","receivedAt":"2025-12-12T23:39:43Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"René Scharfe writes:\n\n> On 12/12/25 2:04 PM, Junio C Hamano wrote:\n>> René Scharfe writes:\n>> \n>>> Fink uses /opt/sw\n>>> (https://www.finkproject.org/faq/general.php?phpLang=en#why-sw).\n>> \n>> Perhaps they have a symlink or something from /sw to /opt/sw, then,\n>> as our Makefile only talks about /sw and /opt/sw\n> Hmm, they changed that in https://github.com/fink/fink/commit/db958e12bf\n> six years ago. Apparently we didn't get the memo.\n\nAnd apparently at least to us upstream Git, they do not matter;\notherwise we would have heard from their users.\n\n"},{"id":"532136","messageId":"5153f701-cc22-4b36-9f88-7187809cbeb8@web.de","threadId":"64599","inReplyTo":"53690064-1c98-40e9-8b9a-7ba6bee63703@web.de","subject":"[PATCH v2 2/2] config.mak.uname: use iconv from Homebrew on macOS","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2025-12-13T18:42:42Z","receivedAt":"2025-12-13T18:42:44Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"The library function iconv(3) supplied with macOS versions 15.7.2\n(Sequoia) and 26.1 (Tahoe) is unreliable when doing conversions from\nISO-2022-JP to UTF-8 in multiple steps; t3900 reports this breakage:\n\n not ok 17 - ISO-2022-JP should be shown in UTF-8 now\n not ok 25 - ISO-2022-JP should be shown in UTF-8 now\n not ok 38 - commit --fixup into ISO-2022-JP from UTF-8\n\nAs a workaround, use libiconv from Homebrew, if available. Search it in\nits default locations: /opt/homebrew for Apple Silicon and /usr/local\nfor macOS Intel, with the former taking precedence. Respect ICONVDIR if\nalready set by the user, though.\n\nHelped-by: Koji Nakamaru \nSigned-off-by: René Scharfe \n---\n Makefile | 3 +++\n config.mak.uname | 7 +++++++\n 2 files changed, 10 insertions(+)\n\ndiff --git a/Makefile b/Makefile\nindex dbd2760d18..80af832529 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -1707,6 +1707,9 @@ ifndef NO_HOMEBREW\n ifdef HOMEBREW_MSGFMT\n \t\tMSGFMT = $(HOMEBREW_MSGFMT)\n endif\n+ ifdef HOMEBREW_ICONVDIR\n+\t\tICONVDIR ?= $(HOMEBREW_ICONVDIR)\n+ endif\n endif\n \n ifdef NO_LIBGEN_H\ndiff --git a/config.mak.uname b/config.mak.uname\nindex a6521575ee..a926943141 100644\n--- a/config.mak.uname\n+++ b/config.mak.uname\n@@ -172,6 +172,13 @@ ifeq ($(uname_S),Darwin)\n endif\n endif\n \n+ ifeq ($(shell test -d /usr/local/opt/libiconv/ && echo y),y)\n+\t\tHOMEBREW_ICONVDIR = /usr/local/opt/libiconv\n+ endif\n+ ifeq ($(shell test -d /opt/homebrew/opt/libiconv/ && echo y),y)\n+\t\tHOMEBREW_ICONVDIR = /opt/homebrew/opt/libiconv\n+ endif\n+\n \t# The builtin FSMonitor on MacOS builds upon Simple-IPC. Both require\n \t# Unix domain sockets and PThreads.\n ifndef NO_PTHREADS\n-- \n2.52.0\n"},{"id":"532137","messageId":"fe00aa37-e929-4ca6-ac23-84a693a48bc6@web.de","threadId":"64599","inReplyTo":"53690064-1c98-40e9-8b9a-7ba6bee63703@web.de","subject":"[PATCH v2 1/2] Makefile: add NO_HOMEBREW","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2025-12-13T18:42:38Z","receivedAt":"2025-12-13T18:42:53Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Allow disabling the use of Homebrew on macOS, or Linux for that matter,\nlike we already do for other package sources, MacPorts and Fink in\nparticular. This is useful for packagers, or anyone else who wants to\ncontrol dependencies.\n\nSuggested-by: Carlo Marcelo Arenas Belón \nSuggested-by: Torsten Bögershausen \nSigned-off-by: René Scharfe \n---\n Makefile | 17 +++++++++++++++++\n config.mak.uname | 11 +++++------\n 2 files changed, 22 insertions(+), 6 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex 6fc322ff88..dbd2760d18 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -100,6 +100,9 @@ include shared.mak\n # specify your own (or DarwinPort's) include directories and\n # library directories by defining CFLAGS and LDFLAGS appropriately.\n #\n+# Define NO_HOMEBREW if you have Homebrew and don't want Git to link\n+# against libraries installed by it.\n+#\n # Define NO_APPLE_COMMON_CRYPTO if you are building on Darwin/Mac OS X\n # and do not want to use Apple's CommonCrypto library. This allows you\n # to provide your own OpenSSL library, for example from MacPorts.\n@@ -1692,6 +1695,20 @@ ifeq ($(uname_S),Darwin)\n \tPTHREAD_LIBS =\n endif\n \n+ifndef NO_HOMEBREW\n+ ifdef HOMEBREW_PREFIX\n+\t\tBASIC_CFLAGS += -I$(HOMEBREW_PREFIX)/include\n+\t\tBASIC_LDFLAGS += -L$(HOMEBREW_PREFIX)/lib\n+ endif\n+ ifdef HOMEBREW_GETTEXT_PREFIX\n+\t\tBASIC_CFLAGS += -I$(HOMEBREW_GETTEXT_PREFIX)/include\n+\t\tBASIC_LDFLAGS += -L$(HOMEBREW_GETTEXT_PREFIX)/lib\n+ endif\n+ ifdef HOMEBREW_MSGFMT\n+\t\tMSGFMT = $(HOMEBREW_MSGFMT)\n+ endif\n+endif\n+\n ifdef NO_LIBGEN_H\n \tCOMPAT_CFLAGS += -DNO_LIBGEN_H\n \tCOMPAT_OBJS += compat/basename.o\ndiff --git a/config.mak.uname b/config.mak.uname\nindex 1691c6ae6e..a6521575ee 100644\n--- a/config.mak.uname\n+++ b/config.mak.uname\n@@ -153,10 +153,10 @@ ifeq ($(uname_S),Darwin)\n \t# `brew link --force gettext`, should be obsolete as of\n \t# https://github.com/Homebrew/homebrew-core/pull/53489\n ifeq ($(shell test -d /usr/local/opt/gettext/ && echo y),y)\n-\t\tBASIC_CFLAGS += -I/usr/local/include -I/usr/local/opt/gettext/include\n-\t\tBASIC_LDFLAGS += -L/usr/local/lib -L/usr/local/opt/gettext/lib\n+\t\tHOMEBREW_PREFIX = /usr/local\n+\t\tHOMEBREW_GETTEXT_PREFIX = /usr/local/opt/gettext\n ifeq ($(shell test -x /usr/local/opt/gettext/bin/msgfmt && echo y),y)\n-\t\t\tMSGFMT = /usr/local/opt/gettext/bin/msgfmt\n+\t\t\tHOMEBREW_MSGFMT = /usr/local/opt/gettext/bin/msgfmt\n endif\n \t# On newer ARM-based machines the default installation path has changed to\n \t# /opt/homebrew. Include it in our search paths so that the user does not\n@@ -166,10 +166,9 @@ ifeq ($(uname_S),Darwin)\n \t# add gettext. The issue was fixed more than three years ago by now, and at\n \t# that point there haven't been any ARM-based Macs yet.\n else ifeq ($(shell test -d /opt/homebrew/ && echo y),y)\n-\t\tBASIC_CFLAGS += -I/opt/homebrew/include\n-\t\tBASIC_LDFLAGS += -L/opt/homebrew/lib\n+\t\tHOMEBREW_PREFIX = /opt/homebrew\n ifeq ($(shell test -x /opt/homebrew/bin/msgfmt && echo y),y)\n-\t\t\tMSGFMT = /opt/homebrew/bin/msgfmt\n+\t\t\tHOMEBREW_MSGFMT = /opt/homebrew/bin/msgfmt\n endif\n endif\n \n-- \n2.52.0\n"},{"id":"532139","messageId":"20251214064544.GA26358@tb-raspi4","threadId":"64599","inReplyTo":"fe00aa37-e929-4ca6-ac23-84a693a48bc6@web.de","subject":"Re: [PATCH v2 1/2] Makefile: add NO_HOMEBREW","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2025-12-14T06:45:44Z","receivedAt":"2025-12-14T06:45:56Z","isPatch":true,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Sat, Dec 13, 2025 at 07:42:38PM +0100, René Scharfe wrote:\n> Allow disabling the use of Homebrew on macOS, or Linux for that matter,\n> like we already do for other package sources, MacPorts and Fink in\n> particular. This is useful for packagers, or anyone else who wants to\n> control dependencies.\n\nGood.\n> \n> Suggested-by: Carlo Marcelo Arenas Belón \n> Suggested-by: Torsten Bögershausen \n> Signed-off-by: René Scharfe \n> ---\n> Makefile | 17 +++++++++++++++++\n> config.mak.uname | 11 +++++------\n> 2 files changed, 22 insertions(+), 6 deletions(-)\n> \n> diff --git a/Makefile b/Makefile\n> index 6fc322ff88..dbd2760d18 100644\n> --- a/Makefile\n> +++ b/Makefile\n> @@ -100,6 +100,9 @@ include shared.mak\n> # specify your own (or DarwinPort's) include directories and\n> # library directories by defining CFLAGS and LDFLAGS appropriately.\n> #\n> +# Define NO_HOMEBREW if you have Homebrew and don't want Git to link\n> +# against libraries installed by it.\n> +#\nGood\n> # Define NO_APPLE_COMMON_CRYPTO if you are building on Darwin/Mac OS X\n> # and do not want to use Apple's CommonCrypto library. This allows you\n> # to provide your own OpenSSL library, for example from MacPorts.\n> @@ -1692,6 +1695,20 @@ ifeq ($(uname_S),Darwin)\n> \tPTHREAD_LIBS =\n> endif\n> \n> +ifndef NO_HOMEBREW\n> + ifdef HOMEBREW_PREFIX\n\nQuestion from a homebrew newbie, kind of:\nWhere do the HOMEBREW_PREFIX (and other HOMEBREW...) come from,\nand what do they do ?\n\nRunning\ngit grep HOMEBREW\ngives\nci/install-dependencies.sh: export HOMEBREW_NO_AUTO_UPDATE=1 HOMEBREW_NO_INSTALL_CLEANUP=1\n\nWhould it make sense to have a few words here as a comment ?\n\n> +\t\tBASIC_CFLAGS += -I$(HOMEBREW_PREFIX)/include\n> +\t\tBASIC_LDFLAGS += -L$(HOMEBREW_PREFIX)/lib\n> + endif\n> + ifdef HOMEBREW_GETTEXT_PREFIX\n> +\t\tBASIC_CFLAGS += -I$(HOMEBREW_GETTEXT_PREFIX)/include\n> +\t\tBASIC_LDFLAGS += -L$(HOMEBREW_GETTEXT_PREFIX)/lib\n> + endif\n> + ifdef HOMEBREW_MSGFMT\n> +\t\tMSGFMT = $(HOMEBREW_MSGFMT)\n> + endif\n> +endif\n> +\n> ifdef NO_LIBGEN_H\n> \tCOMPAT_CFLAGS += -DNO_LIBGEN_H\n> \tCOMPAT_OBJS += compat/basename.o\n> diff --git a/config.mak.uname b/config.mak.uname\n> index 1691c6ae6e..a6521575ee 100644\n> --- a/config.mak.uname\n> +++ b/config.mak.uname\n> @@ -153,10 +153,10 @@ ifeq ($(uname_S),Darwin)\n> \t# `brew link --force gettext`, should be obsolete as of\n> \t# https://github.com/Homebrew/homebrew-core/pull/53489\n> ifeq ($(shell test -d /usr/local/opt/gettext/ && echo y),y)\n> -\t\tBASIC_CFLAGS += -I/usr/local/include -I/usr/local/opt/gettext/include\n> -\t\tBASIC_LDFLAGS += -L/usr/local/lib -L/usr/local/opt/gettext/lib\n> +\t\tHOMEBREW_PREFIX = /usr/local\n> +\t\tHOMEBREW_GETTEXT_PREFIX = /usr/local/opt/gettext\n> ifeq ($(shell test -x /usr/local/opt/gettext/bin/msgfmt && echo y),y)\n> -\t\t\tMSGFMT = /usr/local/opt/gettext/bin/msgfmt\n> +\t\t\tHOMEBREW_MSGFMT = /usr/local/opt/gettext/bin/msgfmt\n> endif\n> \t# On newer ARM-based machines the default installation path has changed to\n> \t# /opt/homebrew. Include it in our search paths so that the user does not\n> @@ -166,10 +166,9 @@ ifeq ($(uname_S),Darwin)\n> \t# add gettext. The issue was fixed more than three years ago by now, and at\n> \t# that point there haven't been any ARM-based Macs yet.\n> else ifeq ($(shell test -d /opt/homebrew/ && echo y),y)\n> -\t\tBASIC_CFLAGS += -I/opt/homebrew/include\n> -\t\tBASIC_LDFLAGS += -L/opt/homebrew/lib\n> +\t\tHOMEBREW_PREFIX = /opt/homebrew\n> ifeq ($(shell test -x /opt/homebrew/bin/msgfmt && echo y),y)\n> -\t\t\tMSGFMT = /opt/homebrew/bin/msgfmt\n> +\t\t\tHOMEBREW_MSGFMT = /opt/homebrew/bin/msgfmt\n> endif\n> endif\n> \n> -- \n> 2.52.0\n> \n"},{"id":"532140","messageId":"xmqqecoxa645.fsf@gitster.g","threadId":"64599","inReplyTo":"20251214064544.GA26358@tb-raspi4","subject":"Re: [PATCH v2 1/2] Makefile: add NO_HOMEBREW","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-12-14T07:13:14Z","receivedAt":"2025-12-14T07:13:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Torsten Bögershausen writes:\n\n> On Sat, Dec 13, 2025 at 07:42:38PM +0100, René Scharfe wrote:\n>> Allow disabling the use of Homebrew on macOS, or Linux for that matter,\n>> like we already do for other package sources, MacPorts and Fink in\n>> particular. This is useful for packagers, or anyone else who wants to\n>> control dependencies.\n>\n> Good.\n>> \n>> Suggested-by: Carlo Marcelo Arenas Belón \n>> Suggested-by: Torsten Bögershausen \n>> Signed-off-by: René Scharfe \n>> ---\n>> Makefile | 17 +++++++++++++++++\n>> config.mak.uname | 11 +++++------\n>> 2 files changed, 22 insertions(+), 6 deletions(-)\n>> \n>> diff --git a/Makefile b/Makefile\n>> index 6fc322ff88..dbd2760d18 100644\n>> --- a/Makefile\n>> +++ b/Makefile\n>> @@ -100,6 +100,9 @@ include shared.mak\n>> # specify your own (or DarwinPort's) include directories and\n>> # library directories by defining CFLAGS and LDFLAGS appropriately.\n>> #\n>> +# Define NO_HOMEBREW if you have Homebrew and don't want Git to link\n>> +# against libraries installed by it.\n>> +#\n> Good\n>> # Define NO_APPLE_COMMON_CRYPTO if you are building on Darwin/Mac OS X\n>> # and do not want to use Apple's CommonCrypto library. This allows you\n>> # to provide your own OpenSSL library, for example from MacPorts.\n>> @@ -1692,6 +1695,20 @@ ifeq ($(uname_S),Darwin)\n>> \tPTHREAD_LIBS =\n>> endif\n>> \n>> +ifndef NO_HOMEBREW\n>> + ifdef HOMEBREW_PREFIX\n>\n> Question from a homebrew newbie, kind of:\n> Where do the HOMEBREW_PREFIX (and other HOMEBREW...) come from,\n> and what do they do ?\n\nI understand these are purely _our_ thing. HOMEBREW_PREFIX and\nHOMEBREW_GETTEXT_PREFIX are set in config.mak.uname (added in this\npatch). I presume that those who installed homebrew at non-default\nlocation and want to use homebrew would not set NO_HOMEBREW and set\nHOMEBREW_PREFIX to the location they installed their homebrew which\nwould be different from the default set in config.mak.uname. Those\nwho have homebrew installed at default location.\n\n> Running\n> git grep HOMEBREW\n> gives\n> ci/install-dependencies.sh: export HOMEBREW_NO_AUTO_UPDATE=1 HOMEBREW_NO_INSTALL_CLEANUP=1\n>\n> Whould it make sense to have a few words here as a comment ?\n\nYeah, like \n\n# Define HOMEBREW_PREFIX to point at an appropriate directory, iff\n# you want to use homebrew installed at a non-standard location.\n# /opt/homebrew on Apple Silicon macOS and at /usr/local on Intel\n# macOS are the standard locations (and you do not have to define\n# this variable yourself).\n\nperhaps? Similarly for other variables.\n"},{"id":"532141","messageId":"20251214090209.GA28723@tb-raspi4","threadId":"64599","inReplyTo":"xmqqecoxa645.fsf@gitster.g","subject":"Re: [PATCH v2 1/2] Makefile: add NO_HOMEBREW","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2025-12-14T09:02:09Z","receivedAt":"2025-12-14T09:02:18Z","isPatch":true,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Sun, Dec 14, 2025 at 04:13:14PM +0900, Junio C Hamano wrote:\n> Torsten Bögershausen writes:\n> \n> > On Sat, Dec 13, 2025 at 07:42:38PM +0100, René Scharfe wrote:\n> >> Allow disabling the use of Homebrew on macOS, or Linux for that matter,\n> >> like we already do for other package sources, MacPorts and Fink in\n> >> particular. This is useful for packagers, or anyone else who wants to\n> >> control dependencies.\n> >\n> > Good.\n> >> \n> >> Suggested-by: Carlo Marcelo Arenas Belón \n> >> Suggested-by: Torsten Bögershausen \n> >> Signed-off-by: René Scharfe \n> >> ---\n> >> Makefile | 17 +++++++++++++++++\n> >> config.mak.uname | 11 +++++------\n> >> 2 files changed, 22 insertions(+), 6 deletions(-)\n> >> \n> >> diff --git a/Makefile b/Makefile\n> >> index 6fc322ff88..dbd2760d18 100644\n> >> --- a/Makefile\n> >> +++ b/Makefile\n> >> @@ -100,6 +100,9 @@ include shared.mak\n> >> # specify your own (or DarwinPort's) include directories and\n> >> # library directories by defining CFLAGS and LDFLAGS appropriately.\n> >> #\n> >> +# Define NO_HOMEBREW if you have Homebrew and don't want Git to link\n> >> +# against libraries installed by it.\n> >> +#\n> > Good\n> >> # Define NO_APPLE_COMMON_CRYPTO if you are building on Darwin/Mac OS X\n> >> # and do not want to use Apple's CommonCrypto library. This allows you\n> >> # to provide your own OpenSSL library, for example from MacPorts.\n> >> @@ -1692,6 +1695,20 @@ ifeq ($(uname_S),Darwin)\n> >> \tPTHREAD_LIBS =\n> >> endif\n> >> \n> >> +ifndef NO_HOMEBREW\n> >> + ifdef HOMEBREW_PREFIX\n> >\n> > Question from a homebrew newbie, kind of:\n> > Where do the HOMEBREW_PREFIX (and other HOMEBREW...) come from,\n> > and what do they do ?\n> \n> I understand these are purely _our_ thing. HOMEBREW_PREFIX and\n> HOMEBREW_GETTEXT_PREFIX are set in config.mak.uname (added in this\n> patch). I presume that those who installed homebrew at non-default\n> location and want to use homebrew would not set NO_HOMEBREW and set\n> HOMEBREW_PREFIX to the location they installed their homebrew which\n> would be different from the default set in config.mak.uname. Those\n> who have homebrew installed at default location.\n> \n> > Running\n> > git grep HOMEBREW\n> > gives\n> > ci/install-dependencies.sh: export HOMEBREW_NO_AUTO_UPDATE=1 HOMEBREW_NO_INSTALL_CLEANUP=1\n> >\n> > Whould it make sense to have a few words here as a comment ?\n> \n> Yeah, like \n> \n> # Define HOMEBREW_PREFIX to point at an appropriate directory, iff\n> # you want to use homebrew installed at a non-standard location.\n> # /opt/homebrew on Apple Silicon macOS and at /usr/local on Intel\n> # macOS are the standard locations (and you do not have to define\n> # this variable yourself).\n> \n> perhaps? Similarly for other variables.\n\nThe main question is still, where the HOMEBREW_XXX variables\nare used ?\nI see that we define them in config.mak.uname\n...I understand these are purely _our_ thing\nThat is what I don't get. It seems as if these are used when\ncompiling under/with homebrew ?\n\n\n"},{"id":"532142","messageId":"xmqq7bup9vah.fsf@gitster.g","threadId":"64599","inReplyTo":"20251214090209.GA28723@tb-raspi4","subject":"Re: [PATCH v2 1/2] Makefile: add NO_HOMEBREW","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-12-14T11:07:02Z","receivedAt":"2025-12-14T11:07:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Torsten Bögershausen writes:\n\n> The main question is still, where the HOMEBREW_XXX variables\n> are used ?\n> I see that we define them in config.mak.uname\n> ...I understand these are purely _our_ thing\n> That is what I don't get. It seems as if these are used when\n> compiling under/with homebrew ?\n\nIn a part I did not quote from your message I was responding to, to\nwhich you are responding to in the message I am responding to, there\nis this gem.\n\n>> +ifndef NO_HOMEBREW\n>> + ifdef HOMEBREW_PREFIX\n>\n>Question from a homebrew newbie, kind of:\n>Where do the HOMEBREW_PREFIX (and other HOMEBREW...) come from,\n>and what do they do ?\n>\n>Running\n>git grep HOMEBREW\n>gives\n>ci/install-dependencies.sh: export HOMEBREW_NO_AUTO_UPDATE=1 HOMEBREW_NO_INSTALL_CLEANUP=1\n>\n>Whould it make sense to have a few words here as a comment ?\n>\n>> +\t\tBASIC_CFLAGS += -I$(HOMEBREW_PREFIX)/include\n>> +\t\tBASIC_LDFLAGS += -L$(HOMEBREW_PREFIX)/lib\n>> + endif\n>> + ifdef HOMEBREW_GETTEXT_PREFIX\n>> +\t\tBASIC_CFLAGS += -I$(HOMEBREW_GETTEXT_PREFIX)/include\n>> +\t\tBASIC_LDFLAGS += -L$(HOMEBREW_GETTEXT_PREFIX)/lib\n>> + endif\n>> + ifdef HOMEBREW_MSGFMT\n>> +\t\tMSGFMT = $(HOMEBREW_MSGFMT)\n>> + endif\n>> +endif\n>> +\n\nSo, unless NO_HOMEBREW is set, HOMEBREW_PREFIX can be set by the\nbuilder, or from config.mak.uname (when homebrew is installed in the\ndefault location), and is added to BASIC_CFLAGS etc., which is how\nthese are used, IIUC.\n\n"},{"id":"532143","messageId":"435e4190-6c46-4404-b769-234f704f608a@web.de","threadId":"64599","inReplyTo":"xmqqecoxa645.fsf@gitster.g","subject":"Re: [PATCH v2 1/2] Makefile: add NO_HOMEBREW","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2025-12-14T11:13:45Z","receivedAt":"2025-12-14T11:13:48Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"On 12/14/25 8:13 AM, Junio C Hamano wrote:\n> Torsten Bögershausen writes:\n> \n>> On Sat, Dec 13, 2025 at 07:42:38PM +0100, René Scharfe wrote:\n>>> Allow disabling the use of Homebrew on macOS, or Linux for that matter,\n>>> like we already do for other package sources, MacPorts and Fink in\n>>> particular. This is useful for packagers, or anyone else who wants to\n>>> control dependencies.\n>>\n>> Good.\n>>>\n>>> Suggested-by: Carlo Marcelo Arenas Belón \n>>> Suggested-by: Torsten Bögershausen \n>>> Signed-off-by: René Scharfe \n>>> ---\n>>> Makefile | 17 +++++++++++++++++\n>>> config.mak.uname | 11 +++++------\n>>> 2 files changed, 22 insertions(+), 6 deletions(-)\n>>>\n>>> diff --git a/Makefile b/Makefile\n>>> index 6fc322ff88..dbd2760d18 100644\n>>> --- a/Makefile\n>>> +++ b/Makefile\n>>> @@ -100,6 +100,9 @@ include shared.mak\n>>> # specify your own (or DarwinPort's) include directories and\n>>> # library directories by defining CFLAGS and LDFLAGS appropriately.\n>>> #\n>>> +# Define NO_HOMEBREW if you have Homebrew and don't want Git to link\n>>> +# against libraries installed by it.\n>>> +#\n>> Good\n>>> # Define NO_APPLE_COMMON_CRYPTO if you are building on Darwin/Mac OS X\n>>> # and do not want to use Apple's CommonCrypto library. This allows you\n>>> # to provide your own OpenSSL library, for example from MacPorts.\n>>> @@ -1692,6 +1695,20 @@ ifeq ($(uname_S),Darwin)\n>>> \tPTHREAD_LIBS =\n>>> endif\n>>> \n>>> +ifndef NO_HOMEBREW\n>>> + ifdef HOMEBREW_PREFIX\n>>\n>> Question from a homebrew newbie, kind of:\n>> Where do the HOMEBREW_PREFIX (and other HOMEBREW...) come from,\n>> and what do they do ?\n> \n> I understand these are purely _our_ thing. HOMEBREW_PREFIX and\n> HOMEBREW_GETTEXT_PREFIX are set in config.mak.uname (added in this\n> patch).\n\nRight.\n\n> I presume that those who installed homebrew at non-default\n> location and want to use homebrew would not set NO_HOMEBREW and set\n> HOMEBREW_PREFIX to the location they installed their homebrew which\n> would be different from the default set in config.mak.uname. Those\n> who have homebrew installed at default location.\n> \n>> Running\n>> git grep HOMEBREW\n>> gives\n>> ci/install-dependencies.sh: export HOMEBREW_NO_AUTO_UPDATE=1 HOMEBREW_NO_INSTALL_CLEANUP=1\n>>\n>> Whould it make sense to have a few words here as a comment ?\n> \n> Yeah, like \n> \n> # Define HOMEBREW_PREFIX to point at an appropriate directory, iff\n> # you want to use homebrew installed at a non-standard location.\n> # /opt/homebrew on Apple Silicon macOS and at /usr/local on Intel\n> # macOS are the standard locations (and you do not have to define\n> # this variable yourself).\n> \n> perhaps? Similarly for other variables.\n\nSounds useful, but before this can become a documented feature it\ndeserves more research and refinement. The current code uses what it\ncan find in an ad-hoc manner, and the patches just extend this behavior\nto libiconv. A user-settable HOMEBREW_PREFIX would require a more\nprincipled approach, so that overriding it affects the search for\ngettext and libiconv.\n\nI guess that would look like this in config.mak.uname:\n\nifeq ($(uname_S),Darwin)\nifeq ($(uname_M),arm64)\n\tHOMEBREW_PREFIX = /opt/homebrew\nelse\n\tHOMEBREW_PREFIX = /usr/local\nendif\n\tUSE_HOMEBREW_GETTEXT = IfAvailable\n\tUSE_HOMEBREW_MSGFMT = IfAvailable\n\tUSE_HOMEBREW_LIBICONV = IfAvailable\nendif\n\n... and in Makefile:\n\nifndef NO_HOMEBREW\nifdef HOMEBREW_PREFIX\nifdef USE_HOMEBREW_GETTEXT\n\t# magic!\nendif\nifdef USE_HOMEBREW_MSGFMT\n\t# more magic!\nendif\nifdef USE_HOMEBREW_LIBICONV\nifeq ($(shell test -d $(HOMEBREW_PREFIX)/opt/libiconv && echo y),y)\n\tICONVDIR ?= $(HOMEBREW_PREFIX)/opt/libiconv\nendif\nendif\nendif\n\nPerhaps the magic parts just need to check for the existence of\n$(HOMEBREW_PREFIX)/opt/gettext and use that, but the current code is\nmore complicated for some reason.\n\nRené\n\n"},{"id":"532153","messageId":"xmqq1pkwabxe.fsf@gitster.g","threadId":"64599","inReplyTo":"435e4190-6c46-4404-b769-234f704f608a@web.de","subject":"Re: [PATCH v2 1/2] Makefile: add NO_HOMEBREW","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-12-14T23:19:57Z","receivedAt":"2025-12-14T23:20:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"René Scharfe writes:\n\n> Sounds useful, but before this can become a documented feature it\n> deserves more research and refinement. The current code uses what it\n> can find in an ad-hoc manner, and the patches just extend this behavior\n> to libiconv. A user-settable HOMEBREW_PREFIX would require a more\n> principled approach, so that overriding it affects the search for\n> gettext and libiconv.\n\nOh, that is so true (but the specifics in macOS details is a bit\nbeyond my depth :/).\n\n> I guess that would look like this in config.mak.uname:\n>\n> ifeq ($(uname_S),Darwin)\n> ifeq ($(uname_M),arm64)\n> \tHOMEBREW_PREFIX = /opt/homebrew\n> else\n> \tHOMEBREW_PREFIX = /usr/local\n> endif\n> \tUSE_HOMEBREW_GETTEXT = IfAvailable\n> \tUSE_HOMEBREW_MSGFMT = IfAvailable\n> \tUSE_HOMEBREW_LIBICONV = IfAvailable\n> endif\n>\n> ... and in Makefile:\n>\n> ifndef NO_HOMEBREW\n> ifdef HOMEBREW_PREFIX\n> ifdef USE_HOMEBREW_GETTEXT\n> \t# magic!\n> endif\n> ifdef USE_HOMEBREW_MSGFMT\n> \t# more magic!\n> endif\n> ifdef USE_HOMEBREW_LIBICONV\n> ifeq ($(shell test -d $(HOMEBREW_PREFIX)/opt/libiconv && echo y),y)\n> \tICONVDIR ?= $(HOMEBREW_PREFIX)/opt/libiconv\n> endif\n> endif\n> endif\n>\n> Perhaps the magic parts just need to check for the existence of\n> $(HOMEBREW_PREFIX)/opt/gettext and use that, but the current code is\n> more complicated for some reason.\n>\n> René\n"},{"id":"532299","messageId":"ac1d3f6f-d95d-477e-9536-7d7903c10553@web.de","threadId":"64599","inReplyTo":"xmqq1pkwabxe.fsf@gitster.g","subject":"Re: [PATCH v2 1/2] Makefile: add NO_HOMEBREW","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2025-12-16T18:53:25Z","receivedAt":"2025-12-16T18:53:37Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"On 12/15/25 12:19 AM, Junio C Hamano wrote:\n> René Scharfe writes:\n> \n>> Sounds useful, but before this can become a documented feature it\n>> deserves more research and refinement. The current code uses what it\n>> can find in an ad-hoc manner, and the patches just extend this behavior\n>> to libiconv. A user-settable HOMEBREW_PREFIX would require a more\n>> principled approach, so that overriding it affects the search for\n>> gettext and libiconv.\n> \n> Oh, that is so true (but the specifics in macOS details is a bit\n> beyond my depth :/).\nSimilar for me, but how hard can it be? :-P. v3 coming, but needs\nthorough review and testing.\n\nRené\n\n"},{"id":"532300","messageId":"98695ef0-b6bc-4929-8581-2ecb894cd604@web.de","threadId":"64599","inReplyTo":"53690064-1c98-40e9-8b9a-7ba6bee63703@web.de","subject":"[PATCH v3 1/2] macOS: make Homebrew use configurable","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2025-12-16T18:53:37Z","receivedAt":"2025-12-16T18:53:39Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"On macOS we opportunistically use Homebrew-installed versions of\ngettext(3) and msgfmt(1). Make that behavior configurable by providing\nmake variables to disable Homebrew usage (NO_HOMEBREW), to allow using a\nnon-default installation location (HOMEBREW_PREFIX), and to control the\nuse of the individual items (USE_HOMEBREW_GETTEXT, USE_HOMEBREW_MSGFMT).\n\nPrecisely Link the gettext keg (the opt/gettext subdirectory) instead of\nrisking to link random other Homebrew-installed libraries as well.\n\nSigned-off-by: René Scharfe \n---\n Makefile | 28 ++++++++++++++++++++++++++++\n config.mak.uname | 28 ++++++----------------------\n 2 files changed, 34 insertions(+), 22 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex cf3f4b585f..a97e9e4d7d 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -100,6 +100,18 @@ include shared.mak\n # specify your own (or DarwinPort's) include directories and\n # library directories by defining CFLAGS and LDFLAGS appropriately.\n #\n+# Define NO_HOMEBREW if you don't want to use libraries and commands\n+# installed by Homebrew.\n+#\n+# Define HOMEBREW_PREFIX if you have Homebrew installed in a non-default\n+# location on macOS or on Linux and want to use it.\n+#\n+# Define USE_HOMEBREW_GETTEXT to link against the gettext library\n+# installed by Homebrew, if present.\n+#\n+# Define USE_HOMEBREW_MSGFMT to use the msgfmt command installed by\n+# Homebrew to compile message catalogs during build, if present.\n+#\n # Define NO_APPLE_COMMON_CRYPTO if you are building on Darwin/Mac OS X\n # and do not want to use Apple's CommonCrypto library. This allows you\n # to provide your own OpenSSL library, for example from MacPorts.\n@@ -1692,6 +1704,22 @@ ifeq ($(uname_S),Darwin)\n \tPTHREAD_LIBS =\n endif\n \n+ifndef NO_HOMEBREW\n+ifdef HOMEBREW_PREFIX\n+ifdef USE_HOMEBREW_GETTEXT\n+ifeq ($(shell test -d $(HOMEBREW_PREFIX)/opt/gettext && echo y),y)\n+\tBASIC_CFLAGS += -I$(HOMEBREW_PREFIX)/opt/gettext/include\n+\tBASIC_LDFLAGS += -L$(HOMEBREW_PREFIX)/opt/gettext/lib\n+endif\n+endif\n+ifdef USE_HOMEBREW_MSGFMT\n+ifeq ($(shell test -x $(HOMEBREW_PREFIX)/opt/gettext/msgfmt && echo y),y)\n+\tMSGFMT = $(HOMEBREW_PREFIX)/opt/gettext/msgfmt\n+endif\n+endif\n+endif\n+endif\n+\n ifdef NO_LIBGEN_H\n \tCOMPAT_CFLAGS += -DNO_LIBGEN_H\n \tCOMPAT_OBJS += compat/basename.o\ndiff --git a/config.mak.uname b/config.mak.uname\nindex 1691c6ae6e..54e3a26649 100644\n--- a/config.mak.uname\n+++ b/config.mak.uname\n@@ -149,29 +149,13 @@ ifeq ($(uname_S),Darwin)\n \tCSPRNG_METHOD = arc4random\n \tUSE_ENHANCED_BASIC_REGULAR_EXPRESSIONS = YesPlease\n \n-\t# Workaround for `gettext` being keg-only and not even being linked via\n-\t# `brew link --force gettext`, should be obsolete as of\n-\t# https://github.com/Homebrew/homebrew-core/pull/53489\n- ifeq ($(shell test -d /usr/local/opt/gettext/ && echo y),y)\n-\t\tBASIC_CFLAGS += -I/usr/local/include -I/usr/local/opt/gettext/include\n-\t\tBASIC_LDFLAGS += -L/usr/local/lib -L/usr/local/opt/gettext/lib\n- ifeq ($(shell test -x /usr/local/opt/gettext/bin/msgfmt && echo y),y)\n-\t\t\tMSGFMT = /usr/local/opt/gettext/bin/msgfmt\n- endif\n-\t# On newer ARM-based machines the default installation path has changed to\n-\t# /opt/homebrew. Include it in our search paths so that the user does not\n-\t# have to configure this manually.\n-\t#\n-\t# Note that we do not employ the same workaround as above where we manually\n-\t# add gettext. The issue was fixed more than three years ago by now, and at\n-\t# that point there haven't been any ARM-based Macs yet.\n- else ifeq ($(shell test -d /opt/homebrew/ && echo y),y)\n-\t\tBASIC_CFLAGS += -I/opt/homebrew/include\n-\t\tBASIC_LDFLAGS += -L/opt/homebrew/lib\n- ifeq ($(shell test -x /opt/homebrew/bin/msgfmt && echo y),y)\n-\t\t\tMSGFMT = /opt/homebrew/bin/msgfmt\n- endif\n+ ifeq ($(uname_M),arm64)\n+\t\tHOMEBREW_PREFIX = /opt/homebrew\n+ else\n+\t\tHOMEBREW_PREFIX = /usr/local\n endif\n+\tUSE_HOMEBREW_GETTEXT = YesPlease\n+\tUSE_HOMEBREW_MSGFMT = YesPlease\n \n \t# The builtin FSMonitor on MacOS builds upon Simple-IPC. Both require\n \t# Unix domain sockets and PThreads.\n-- \n2.52.0\n"},{"id":"532301","messageId":"3c85cab3-1e05-4d61-82b0-79659b03d282@web.de","threadId":"64599","inReplyTo":"53690064-1c98-40e9-8b9a-7ba6bee63703@web.de","subject":"[PATCH v3 2/2] macOS: use iconv from Homebrew if present","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2025-12-16T18:53:53Z","receivedAt":"2025-12-16T18:54:00Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"The library function iconv(3) supplied with macOS versions 15.7.2\n(Sequoia) and 26.1 (Tahoe) is unreliable when doing conversions from\nISO-2022-JP to UTF-8 in multiple steps; t3900 reports this breakage:\n\n not ok 17 - ISO-2022-JP should be shown in UTF-8 now\n not ok 25 - ISO-2022-JP should be shown in UTF-8 now\n not ok 38 - commit --fixup into ISO-2022-JP from UTF-8\n\nAs a workaround, use libiconv from Homebrew, if available. Search it in\nits default locations: /opt/homebrew for Apple Silicon and /usr/local\nfor macOS Intel, with the former taking precedence. Respect ICONVDIR if\nalready set by the user, though.\n\nHelped-by: Koji Nakamaru \nSigned-off-by: René Scharfe \n---\n Makefile | 8 ++++++++\n config.mak.uname | 1 +\n 2 files changed, 9 insertions(+)\n\ndiff --git a/Makefile b/Makefile\nindex a97e9e4d7d..307dac3c03 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -112,6 +112,9 @@ include shared.mak\n # Define USE_HOMEBREW_MSGFMT to use the msgfmt command installed by\n # Homebrew to compile message catalogs during build, if present.\n #\n+# Define USE_HOMEBREW_LIBICONV to link against libiconv installed by\n+# Homebrew, if present.\n+#\n # Define NO_APPLE_COMMON_CRYPTO if you are building on Darwin/Mac OS X\n # and do not want to use Apple's CommonCrypto library. This allows you\n # to provide your own OpenSSL library, for example from MacPorts.\n@@ -1717,6 +1720,11 @@ ifeq ($(shell test -x $(HOMEBREW_PREFIX)/opt/gettext/msgfmt && echo y),y)\n \tMSGFMT = $(HOMEBREW_PREFIX)/opt/gettext/msgfmt\n endif\n endif\n+ifdef USE_HOMEBREW_LIBICONV\n+ifeq ($(shell test -d $(HOMEBREW_PREFIX)/opt/libiconv && echo y),y)\n+\tICONVDIR ?= $(HOMEBREW_PREFIX)/opt/libiconv\n+endif\n+endif\n endif\n endif\n \ndiff --git a/config.mak.uname b/config.mak.uname\nindex 54e3a26649..e2e93e9dc5 100644\n--- a/config.mak.uname\n+++ b/config.mak.uname\n@@ -156,6 +156,7 @@ ifeq ($(uname_S),Darwin)\n endif\n \tUSE_HOMEBREW_GETTEXT = YesPlease\n \tUSE_HOMEBREW_MSGFMT = YesPlease\n+\tUSE_HOMEBREW_LIBICONV = YesPlease\n \n \t# The builtin FSMonitor on MacOS builds upon Simple-IPC. Both require\n \t# Unix domain sockets and PThreads.\n-- \n2.52.0\n"},{"id":"532304","messageId":"d2f033fc-222a-4fe8-8d24-6501e6f7a4c3@web.de","threadId":"64599","inReplyTo":"98695ef0-b6bc-4929-8581-2ecb894cd604@web.de","subject":"Re: [PATCH v3 1/2] macOS: make Homebrew use configurable","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2025-12-16T19:11:59Z","receivedAt":"2025-12-16T19:12:02Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"On 12/16/25 7:53 PM, René Scharfe wrote:\n> On macOS we opportunistically use Homebrew-installed versions of\n> gettext(3) and msgfmt(1). Make that behavior configurable by providing\n> make variables to disable Homebrew usage (NO_HOMEBREW), to allow using a\n> non-default installation location (HOMEBREW_PREFIX), and to control the\n> use of the individual items (USE_HOMEBREW_GETTEXT, USE_HOMEBREW_MSGFMT).\n> \n> Precisely Link the gettext keg (the opt/gettext subdirectory) instead of\n> risking to link random other Homebrew-installed libraries as well.\n> \n> Signed-off-by: René Scharfe \n> ---\n> Makefile | 28 ++++++++++++++++++++++++++++\n> config.mak.uname | 28 ++++++----------------------\n> 2 files changed, 34 insertions(+), 22 deletions(-)\n> \n> diff --git a/Makefile b/Makefile\n> index cf3f4b585f..a97e9e4d7d 100644\n> --- a/Makefile\n> +++ b/Makefile\n> @@ -100,6 +100,18 @@ include shared.mak\n> # specify your own (or DarwinPort's) include directories and\n> # library directories by defining CFLAGS and LDFLAGS appropriately.\n> #\n> +# Define NO_HOMEBREW if you don't want to use libraries and commands\n> +# installed by Homebrew.\n> +#\n> +# Define HOMEBREW_PREFIX if you have Homebrew installed in a non-default\n> +# location on macOS or on Linux and want to use it.\n> +#\n> +# Define USE_HOMEBREW_GETTEXT to link against the gettext library\n> +# installed by Homebrew, if present.\n> +#\n> +# Define USE_HOMEBREW_MSGFMT to use the msgfmt command installed by\n> +# Homebrew to compile message catalogs during build, if present.\n\nDo we even need these fine-grained USE_ variables?\n\nRené\n\n"},{"id":"532310","messageId":"20251216214943.GA31390@tb-raspi4","threadId":"64599","inReplyTo":"d2f033fc-222a-4fe8-8d24-6501e6f7a4c3@web.de","subject":"Re: [PATCH v3 1/2] macOS: make Homebrew use configurable","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2025-12-16T21:49:43Z","receivedAt":"2025-12-16T21:49:53Z","isPatch":true,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"> > +#\n> > +# Define USE_HOMEBREW_GETTEXT to link against the gettext library\n> > +# installed by Homebrew, if present.\n> > +#\n> > +# Define USE_HOMEBREW_MSGFMT to use the msgfmt command installed by\n> > +# Homebrew to compile message catalogs during build, if present.\n> \n> Do we even need these fine-grained USE_ variables?\n\nIf someone asks me: Probably not.\n\n> \n> René\n> \n> \n"},{"id":"532686","messageId":"ce030c90-f635-42b5-82e1-814cd4c29505@web.de","threadId":"64599","inReplyTo":"53690064-1c98-40e9-8b9a-7ba6bee63703@web.de","subject":"[PATCH v4 0/2] macOS: use iconv from Homebrew if needed and present","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2025-12-24T07:52:04Z","receivedAt":"2025-12-24T07:57:32Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Changes since v3:\n- Removed unnecessary USE_HOMEBREW_GETTEXT and USE_HOMEBREW_MSGFMT.\n- Set USE_HOMEBREW_LIBICONV only on known-broken OS versions.\n\nChanges since v2:\n- Added HOMEBREW_PREFIX.\n- Added USE_HOMEBREW_GETTEXT, USE_HOMEBREW_MSGFMT and USE_HOMEBREW_LIBICONV.\n\nChanges since v1:\n- Added NO_HOMEBREW.\n\n macOS: make Homebrew use configurable\n macOS: use iconv from Homebrew if needed and present\n\n Makefile | 26 ++++++++++++++++++++++++++\n config.mak.uname | 30 ++++++++----------------------\n 2 files changed, 34 insertions(+), 22 deletions(-)\n\n-- \n2.52.0\n"},{"id":"532687","messageId":"33d65e54-4f02-4167-bc4e-ec0ee36fc786@web.de","threadId":"64599","inReplyTo":"ce030c90-f635-42b5-82e1-814cd4c29505@web.de","subject":"[PATCH v4 2/2] macOS: use iconv from Homebrew if needed and present","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2025-12-24T08:03:01Z","receivedAt":"2025-12-24T08:03:09Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"The library function iconv(3) supplied with macOS versions 15.7.2\n(Sequoia) and 26.1 (Tahoe) is unreliable when doing conversions from\nISO-2022-JP to UTF-8 in multiple steps; t3900 reports this breakage:\n\n not ok 17 - ISO-2022-JP should be shown in UTF-8 now\n not ok 25 - ISO-2022-JP should be shown in UTF-8 now\n not ok 38 - commit --fixup into ISO-2022-JP from UTF-8\n\nAs a workaround, use libiconv from Homebrew, if available. Search it in\nits default locations: /opt/homebrew for Apple Silicon and /usr/local\nfor macOS Intel, with the former taking precedence. Respect ICONVDIR if\nalready set by the user, though.\n\nHelped-by: Koji Nakamaru \nSigned-off-by: René Scharfe \n---\n Makefile | 12 ++++++++++--\n config.mak.uname | 4 ++++\n 2 files changed, 14 insertions(+), 2 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex 9aef22c032..b7eba509c6 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -101,12 +101,15 @@ include shared.mak\n # specify your own (or DarwinPort's) include directories and\n # library directories by defining CFLAGS and LDFLAGS appropriately.\n #\n-# Define NO_HOMEBREW if you don't want to use gettext and msgfmt\n-# installed by Homebrew.\n+# Define NO_HOMEBREW if you don't want to use gettext, libiconv and\n+# msgfmt installed by Homebrew.\n #\n # Define HOMEBREW_PREFIX if you have Homebrew installed in a non-default\n # location on macOS or on Linux and want to use it.\n #\n+# Define USE_HOMEBREW_LIBICONV to link against libiconv installed by\n+# Homebrew, if present.\n+#\n # Define NO_APPLE_COMMON_CRYPTO if you are building on Darwin/Mac OS X\n # and do not want to use Apple's CommonCrypto library. This allows you\n # to provide your own OpenSSL library, for example from MacPorts.\n@@ -1708,6 +1711,11 @@ endif\n ifeq ($(shell test -x $(HOMEBREW_PREFIX)/opt/gettext/msgfmt && echo y),y)\n \tMSGFMT = $(HOMEBREW_PREFIX)/opt/gettext/msgfmt\n endif\n+ifdef USE_HOMEBREW_LIBICONV\n+ifeq ($(shell test -d $(HOMEBREW_PREFIX)/opt/libiconv && echo y),y)\n+\tICONVDIR ?= $(HOMEBREW_PREFIX)/opt/libiconv\n+endif\n+endif\n endif\n endif\n \ndiff --git a/config.mak.uname b/config.mak.uname\nindex db2a922751..38b35af366 100644\n--- a/config.mak.uname\n+++ b/config.mak.uname\n@@ -124,6 +124,7 @@ ifeq ($(uname_S),Darwin)\n \t# - MacOS 10.0.* and MacOS 10.1.0 = Darwin 1.*\n \t# - MacOS 10.x.* = Darwin (x+4).* for (1 <= x)\n \t# i.e. \"begins with [15678] and a dot\" means \"10.4.* or older\".\n+\tDARWIN_MAJOR_VERSION = $(shell expr \"$(uname_R)\" : '\\([0-9]*\\)\\.')\n ifeq ($(shell expr \"$(uname_R)\" : '[15678]\\.'),2)\n \t\tOLD_ICONV = UnfortunatelyYes\n \t\tNO_APPLE_COMMON_CRYPTO = YesPlease\n@@ -154,6 +155,9 @@ ifeq ($(uname_S),Darwin)\n else\n \t\tHOMEBREW_PREFIX = /usr/local\n endif\n+ ifeq ($(shell test \"$(DARWIN_MAJOR_VERSION)\" -ge 24 && echo 1),1)\n+\t\tUSE_HOMEBREW_LIBICONV = UnfortunatelyYes\n+ endif\n \n \t# The builtin FSMonitor on MacOS builds upon Simple-IPC. Both require\n \t# Unix domain sockets and PThreads.\n-- \n2.52.0\n"},{"id":"532688","messageId":"1c91caa0-c785-4448-90bd-d09de66dd553@web.de","threadId":"64599","inReplyTo":"ce030c90-f635-42b5-82e1-814cd4c29505@web.de","subject":"[PATCH v4 1/2] macOS: make Homebrew use configurable","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2025-12-24T08:02:45Z","receivedAt":"2025-12-24T08:08:18Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"On macOS we opportunistically use Homebrew-installed versions of\ngettext(3) and msgfmt(1). Make that behavior configurable by providing\nmake variables to disable Homebrew usage (NO_HOMEBREW) and to allow\nusing a non-default installation location (HOMEBREW_PREFIX).\n\nInclude and link only the gettext keg via the symlink opt/gettext\npointing to its installed version instead of using the Homebrew prefix.\nThis is simpler and prevents accidentally including other libraries.\n\nSuggested-by: Carlo Marcelo Arenas Belón \nSuggested-by: Torsten Bögershausen \nSigned-off-by: René Scharfe \n---\n Makefile | 18 ++++++++++++++++++\n config.mak.uname | 26 ++++----------------------\n 2 files changed, 22 insertions(+), 22 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex 89d8d73ec0..9aef22c032 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -101,6 +101,12 @@ include shared.mak\n # specify your own (or DarwinPort's) include directories and\n # library directories by defining CFLAGS and LDFLAGS appropriately.\n #\n+# Define NO_HOMEBREW if you don't want to use gettext and msgfmt\n+# installed by Homebrew.\n+#\n+# Define HOMEBREW_PREFIX if you have Homebrew installed in a non-default\n+# location on macOS or on Linux and want to use it.\n+#\n # Define NO_APPLE_COMMON_CRYPTO if you are building on Darwin/Mac OS X\n # and do not want to use Apple's CommonCrypto library. This allows you\n # to provide your own OpenSSL library, for example from MacPorts.\n@@ -1693,6 +1699,18 @@ ifeq ($(uname_S),Darwin)\n \tPTHREAD_LIBS =\n endif\n \n+ifndef NO_HOMEBREW\n+ifdef HOMEBREW_PREFIX\n+ifeq ($(shell test -d $(HOMEBREW_PREFIX)/opt/gettext && echo y),y)\n+\tBASIC_CFLAGS += -I$(HOMEBREW_PREFIX)/opt/gettext/include\n+\tBASIC_LDFLAGS += -L$(HOMEBREW_PREFIX)/opt/gettext/lib\n+endif\n+ifeq ($(shell test -x $(HOMEBREW_PREFIX)/opt/gettext/msgfmt && echo y),y)\n+\tMSGFMT = $(HOMEBREW_PREFIX)/opt/gettext/msgfmt\n+endif\n+endif\n+endif\n+\n ifdef NO_LIBGEN_H\n \tCOMPAT_CFLAGS += -DNO_LIBGEN_H\n \tCOMPAT_OBJS += compat/basename.o\ndiff --git a/config.mak.uname b/config.mak.uname\nindex 1691c6ae6e..db2a922751 100644\n--- a/config.mak.uname\n+++ b/config.mak.uname\n@@ -149,28 +149,10 @@ ifeq ($(uname_S),Darwin)\n \tCSPRNG_METHOD = arc4random\n \tUSE_ENHANCED_BASIC_REGULAR_EXPRESSIONS = YesPlease\n \n-\t# Workaround for `gettext` being keg-only and not even being linked via\n-\t# `brew link --force gettext`, should be obsolete as of\n-\t# https://github.com/Homebrew/homebrew-core/pull/53489\n- ifeq ($(shell test -d /usr/local/opt/gettext/ && echo y),y)\n-\t\tBASIC_CFLAGS += -I/usr/local/include -I/usr/local/opt/gettext/include\n-\t\tBASIC_LDFLAGS += -L/usr/local/lib -L/usr/local/opt/gettext/lib\n- ifeq ($(shell test -x /usr/local/opt/gettext/bin/msgfmt && echo y),y)\n-\t\t\tMSGFMT = /usr/local/opt/gettext/bin/msgfmt\n- endif\n-\t# On newer ARM-based machines the default installation path has changed to\n-\t# /opt/homebrew. Include it in our search paths so that the user does not\n-\t# have to configure this manually.\n-\t#\n-\t# Note that we do not employ the same workaround as above where we manually\n-\t# add gettext. The issue was fixed more than three years ago by now, and at\n-\t# that point there haven't been any ARM-based Macs yet.\n- else ifeq ($(shell test -d /opt/homebrew/ && echo y),y)\n-\t\tBASIC_CFLAGS += -I/opt/homebrew/include\n-\t\tBASIC_LDFLAGS += -L/opt/homebrew/lib\n- ifeq ($(shell test -x /opt/homebrew/bin/msgfmt && echo y),y)\n-\t\t\tMSGFMT = /opt/homebrew/bin/msgfmt\n- endif\n+ ifeq ($(uname_M),arm64)\n+\t\tHOMEBREW_PREFIX = /opt/homebrew\n+ else\n+\t\tHOMEBREW_PREFIX = /usr/local\n endif\n \n \t# The builtin FSMonitor on MacOS builds upon Simple-IPC. Both require\n-- \n2.52.0\n"}]}