On Tue Aug 05, 2025 at 05:19:29AM +0200, Ingo Schwarze wrote:
> 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
> 

Hi Ingo,

thanks for the feedback - you're absolutely right about LC_CTYPE
being better than LC_ALL.

The build locale doesn't affect runtime behavior. Qt6 apps work
fine with whatever locale the user sets. I tested this - no
crashes or weird behavior with C locale users.

Updated diff using LC_CTYPE instead:

CONFIGURE_ENV += LC_CTYPE=C.UTF-8
MAKE_ENV +=      LC_CTYPE=C.UTF-8

This just fixes the build warning without messing with other
locale categories. The warning happens because Qt6 does some text
processing during compilation that needs UTF-8.

If I don't hear any objections, I would go ahead with this version.

Rafael