public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: "René Scharfe" <l.s.r@web•de>
To: tboegi@web•de, git@vger•kernel.org
Subject: Re: [PATCH v1 2/2] utf8.c: Enable workaround for iconv under macOS 14/15
Date: Fri, 9 Jan 2026 19:01:10 +0100	[thread overview]
Message-ID: <0a5c058c-e5cb-41c9-8788-6dc6354f9119@web.de> (raw)
In-Reply-To: <20260108174012.471706-1-tboegi@web.de>

On 1/8/26 6:40 PM, tboegi@web•de wrote:
> From: Torsten Bögershausen <tboegi@web•de>
> 
> The previous commit introduced a workaround in utf8.c to deal
> with broken iconv implementations.
> 
> It is enabled when
>   A MacOS version is used that has a buggy iconv library and
>   there is no external library provided (and linked against)
>   from neither MacPorts nor Homebrew.

Odd style.  Make "A" lowercase, remove the line break after "when" and
unindent?

> Signed-off-by: Torsten Bögershausen <tboegi@web•de>
> ---
>  Makefile         | 7 +++++++
>  config.mak.uname | 1 +
>  2 files changed, 8 insertions(+)
> 
> diff --git a/Makefile b/Makefile
> index b7eba509c6..5a3823bb67 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1692,6 +1692,7 @@ ifeq ($(uname_S),Darwin)
>                  ifeq ($(shell test -d /opt/local/lib && echo y),y)
>  			BASIC_CFLAGS += -I/opt/local/include
>  			BASIC_LDFLAGS += -L/opt/local/lib
> +			HAS_GOOD_LIBICONV = Yes

This doesn't check whether libiconv was actually installed via MacPorts,
so technically that's more of a "Maybe?", no?

>                  endif
>          endif
>          ifndef NO_APPLE_COMMON_CRYPTO
> @@ -1714,6 +1715,7 @@ endif
>  ifdef USE_HOMEBREW_LIBICONV
>  ifeq ($(shell test -d $(HOMEBREW_PREFIX)/opt/libiconv && echo y),y)
>  	ICONVDIR ?= $(HOMEBREW_PREFIX)/opt/libiconv
> +	HAS_GOOD_LIBICONV = Yes

Looks good.

>  endif
>  endif
>  endif
> @@ -1859,6 +1861,11 @@ ifndef NO_ICONV
>                  endif
>  		EXTLIBS += $(ICONV_LINK) -liconv
>          endif
> +        ifdef NEEDS_GOOD_LIBICONV
> +        ifndef HAS_GOOD_LIBICONV

"GOOD" is quite vague.  There's already ICONV_OMITS_BOM, and I wouldn't
be surprised if we discover the need for some other workarounds soon.
How about naming the make variables after the C macro to be more clear
and specific?

Can we get away with a single make variable?  Set it in config.mak.uname
on affected systems and set it to empty if we detect that a 3rd party
libiconv is used?

> +                BASIC_CFLAGS += -DICONV_RESTART_RESET
> +        endif
> +        endif
>  endif
>  ifdef ICONV_OMITS_BOM
>  	BASIC_CFLAGS += -DICONV_OMITS_BOM
> diff --git a/config.mak.uname b/config.mak.uname
> index 38b35af366..3c35ae33a3 100644
> --- a/config.mak.uname
> +++ b/config.mak.uname
> @@ -157,6 +157,7 @@ ifeq ($(uname_S),Darwin)
>          endif
>          ifeq ($(shell test "$(DARWIN_MAJOR_VERSION)" -ge 24 && echo 1),1)
>  		USE_HOMEBREW_LIBICONV = UnfortunatelyYes
> +		NEEDS_GOOD_LIBICONV = UnfortunatelyYes
>          endif
>  
>  	# The builtin FSMonitor on MacOS builds upon Simple-IPC.  Both require


  reply	other threads:[~2026-01-09 18:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-08 17:40 [PATCH v1 2/2] utf8.c: Enable workaround for iconv under macOS 14/15 tboegi
2026-01-09 18:01 ` René Scharfe [this message]
  -- strict thread matches above, loose matches on Subject: below --
2026-01-08 17:23 tboegi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0a5c058c-e5cb-41c9-8788-6dc6354f9119@web.de \
    --to=l.s.r@web$(echo .)de \
    --cc=git@vger$(echo .)kernel.org \
    --cc=tboegi@web$(echo .)de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox