Re: [PATCH] build.sh: Fix perl complaints about locale

[Henning Schild <henning.schild@siemens.com>]

Am Tue, 21 Nov 2017 21:12:35 +0300
schrieb Alexander Smirnov <asmirnov@ilbers.de>:

> Hi,
> 
> On 11/21/2017 09:04 PM, Henning Schild wrote:
> > Am Tue, 21 Nov 2017 11:56:57 +0300
> > schrieb Alexander Smirnov <asmirnov@ilbers.de>:
> >   
> >> On 11/21/2017 11:42 AM, Henning Schild wrote:  
> >>> Am Fri, 17 Nov 2017 13:42:05 +0300
> >>> schrieb Alexander Smirnov <asmirnov@ilbers.de>:
> >>>      
> >>>> Hi,
> >>>>
> >>>> On 11/13/2017 03:21 PM, Christian Storm wrote:  
> >>>>> The log.do_build is flooded by perl's locale complaints:
> >>>>>
> >>>>>        perl: warning: Setting locale failed.
> >>>>>        perl: warning: Please check that your locale settings:
> >>>>>                LANGUAGE = (unset),
> >>>>>                LC_ALL = "en_US.UTF-8",
> >>>>>                LANG = (unset)
> >>>>>            are supported and installed on your system.
> >>>>>        perl: warning: Falling back to the standard locale ("C").
> >>>>>
> >>>>> Make perl happy by explicitly giving it the C locale.
> >>>>>
> >>>>> Signed-off-by: Christian Storm <christian.storm@siemens.com>
> >>>>> ---
> >>>>>     meta/recipes-devtools/buildchroot/files/build.sh | 2 +-
> >>>>>     1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/meta/recipes-devtools/buildchroot/files/build.sh
> >>>>> b/meta/recipes-devtools/buildchroot/files/build.sh index
> >>>>> 19d554e..e53d359 100644 ---
> >>>>> a/meta/recipes-devtools/buildchroot/files/build.sh +++
> >>>>> b/meta/recipes-devtools/buildchroot/files/build.sh @@ -23,4
> >>>>> +23,4 @@ for i in configure aclocal.m4 Makefile.am Makefile.in;
> >>>>> do done 
> >>>>>     # Build the package
> >>>>> -dpkg-buildpackage
> >>>>> +LC_ALL=C LANGUAGE=C LANG=C dpkg-buildpackage
> >>>>>         
> >>>>
> >>>> short question, does LC_ALL override LANG value?  
> >>>
> >>> No. Try "LC_ALL=C locale", as the name says it overrides LC_*. But
> >>> you are right LC_ALL might be enough to get rid of the warnings.  
> >>
> >> I'm asking because it's not so clear for me. What I've got from
> >> various links, LC_ALL overrides LANG:
> >>
> >> https://docs.oracle.com/cd/E23824_01/html/E26033/glmbx.html
> >>
> >> ...
> >>    If the LC_ALL environment variable is set, it overrides LANG and
> >> all the separate locale categories.
> >> ...
> >>
> >> https://www.gnu.org/software/gettext/manual/html_node/Locale-Environment-Variables.html
> >>
> >> ...
> >> LC_ALL is an environment variable that overrides all of these...
> >> As a user, you therefore have to unset this variable if you want
> >> to set LANG and optionally some of the other LC_xxx variables.
> >> ...
> >>
> >> https://wiki.archlinux.org/index.php/locale#LC_ALL:_troubleshooting
> >>
> >> ...
> >> The locale set for this variable will always override LANG and all
> >> the other LC_* variables, whether they are set or not.
> >> ...
> >>
> >> And so on...
> >>
> >> I wonder if there is some reference place where it's strictly
> >> defined whether or not LC_ALL overrides LAND.  
> > 
> > Ah sorry i read it wrong. LC_ALL sets the others, not sure which
> > one is the strongest. But why does it matter? You control all 3 and
> > likely setting LC_ALL will mute the warning.  
> 
> The problem is that all variables come from your host environment to 
> chroot. So if host LC_*/LANG variable differs from en_US.UTF-8 - it 
> could be a problem in chroot. So we should override everything that
> goes from the host.

Does not bitbake clear the env except for a few well-known variables?
Or are those on BB_ENV_WHITELIST or otherwise leaking into bitbake?

> So I'm in doubts whether LC_ALL stronger than LANG or not,
> documentation frustrates me :-) For sure, I propose to use both LANG
> and LC_ALL in the patch.

Even if bitbake inherits them from the host, just set them all to the
same value. Who cares which "C" wins.

Henning
 
> Alex