From: Ingo Schwarze <schwarze@usta.de>
Subject: Re: Set LC_ALL to C.UTF-8 in qt6.port.mk
To: Rafael Sadowski <rafael@sizeofvoid.org>
Cc: ports@openbsd.org
Date: Tue, 5 Aug 2025 05:19:29 +0200

Hello Rafael,

Rafael Sadowski wrote on Sat, Aug 02, 2025 at 09:30:48PM +0200:

> I would like to suggest adding LC_ALL=C.UTF-8 in qt6.port.mk.
> The reason for this is to get rid of the following warning during
> the build:
> 
> # Detected locale "C" with character encoding "US-ASCII", which is not UTF-8.
> # Qt depends on a UTF-8 locale, and has switched to "C.UTF-8" instead.
> 
> In the end we have C.UTF-8 anyway.

I'm not terribly worried about having LC_ALL at build time, because
the build environment does not seem likely to leak to the end user.
Then again, if setting just LC_CTYPE is sufficient, i'd regard that
as likely preferable because the other LC_* variables (intentionally!)
don't do anything on OpenBSD, so setting them can't create any real
benefit, but seems likely to mislead the build system into thinking
that we supported various stuff that we neither support nor want.
I think the bogus variable LC_ALL should only be set if the build
absolutely insists that it *must* be set (and forces it anyway even
if it is not set).

But apart from what the build infrastructure needs, i worry what
the implications are *at run time*.  I mean, the whole point of
a locale(1) is that it is a *user setting* and not a system
configuration setting.  So that a build system requires any
particular locale(1) to be set seems so insane to me that i
wonder what the run time time consequences might be.

For example, does this imply that any program using any Qt6
library only works correctly when the user sets LC_CTYPE=something.UTF-8
in the environment before starting the program?  Or even LC_ALL?
What are the consequences when users start Qt6 programs with
the default locale, i.e. with no LC_* variable set?  Does it
crash?  Does it refuse to start?  Does it silently misbehave?
Does it silently ignore the user locale(1) and use C.UTF-8
regardless?  That would be a serious problem if output from
some Qt6 program could end up in a terminal, because printing
UTF-8 to a terminal or to a device not expecting UTF-8 is not safe.
Does anything need to be documented in that respect, and where?

I see that port-modules(5) just says

  x11/qt5 and x11/qt6
    The modules add to CONFIGURE_ENV, MAKE_ENV and MAKE_FLAGS.

Without saying which environment variables are set, let alone
to which values, and looking at qt6.port.mk itself, there is
a lot of indirection, not making it easy to understand what
is going on, and even less so why.  Anyway, end users are
not going to look at port-modules(5)...

> OK?

I'm not the best person to review and OK such a ports infrastructure
diff, and i do not object to it, but i worry that your proposal
focusses very narrowly on silencing a build warning without
even mentioning what the practical consequences for end users
are.  Isn't the benfit of warnings that they indicate a potential
problem that should be investigated and understood, rather than
simply silencing it?

Yours,
  Ingo


> Index: qt6.port.mk
> ===================================================================
> RCS file: /cvs/ports/x11/qt6/qt6.port.mk,v
> diff -u -p -r1.12 qt6.port.mk
> --- qt6.port.mk	22 May 2025 08:52:31 -0000	1.12
> +++ qt6.port.mk	2 Aug 2025 19:24:21 -0000
> @@ -61,6 +61,11 @@ COMPILER ?= base-clang ports-gcc
>  ONLY_FOR_ARCHS ?= ${CXX11_ARCHS}
>  .endif
>  
> +# Detected locale "C" with character encoding "US-ASCII", which is not UTF-8.
> +# Qt depends on a UTF-8 locale, and has switched to "C.UTF-8" instead.
> +CONFIGURE_ENV +=	LC_ALL=C.UTF-8
> +MAKE_ENV +=		LC_ALL=C.UTF-8
> +
>  .include "Makefile.version"
>  
>  MODQT6_VERSION =	${QT6_VERSION}