From: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
To: "mmarek@suse.com" <mmarek@suse.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-kbuild@vger.kernel.org" <linux-kbuild@vger.kernel.org>,
"yamada.masahiro@socionext.com" <yamada.masahiro@socionext.com>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>,
"Vineet.Gupta1@synopsys.com" <Vineet.Gupta1@synopsys.com>
Subject: Re: [PATCH] Unexport LANG env variable
Date: Wed, 14 Jun 2017 13:11:07 +0000 [thread overview]
Message-ID: <1497445867.6424.36.camel@synopsys.com> (raw)
In-Reply-To: <51f658dc-215a-6c0c-0ab9-d1164812a56d@suse.com>
Hi Michal,
On Wed, 2017-06-14 at 15:02 +0200, Michal Marek wrote:
> Dne 14.6.2017 v 14:40 Alexey Brodkin napsal(a):
> >
> > In those cases when we parse output of standard utilities like readelf
> > etc we rely on a particular sentences. For example for ARC we extract
> > an entry-point from vmlinux like that:
> > ---------------------->8--------------------
> > readelf -h vmlinux | grep "Entry point address" | grep -o 0x.*
> > ---------------------->8--------------------
> >
> > And in case LANG is set to anything other than en_XX we're getting
> > nothing and subsequent execution of mkimage utility fails.
> >
> > Probably there're more cases like that but given people rarely
> > use non-English locales on their dev machines problems like the one
> > above are not very visible.
>
> I'm all for this change but the *.po files in the gcc tree must have
> been created for a reason:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_gcc-2Dmirror_gcc_tree_master_gcc_po&d=DwICBA&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes
> 0GFDDl656eViXO7breS55ytWkhpk5R81I&m=v2ilYYv6Z0WzVaIys3sCQdK3QBI9gqH7hUmoTGPpJ44&s=S3B79SHovtt1-wLRtngTUM0dKWMiokGE75HIrfgkbbc&e=
That's for sure.
But then how may we have a predictable environment for our machinery?
I do realize that with that change in place people will start seeing
non-translated messages from other tools like compiler etc.
But probably that's not the worst idea as well because it helps googling :)
-Alexey
next prev parent reply other threads:[~2017-06-14 13:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-14 12:40 [PATCH] Unexport LANG env variable Alexey Brodkin
2017-06-14 13:02 ` Michal Marek
2017-06-14 13:11 ` Alexey Brodkin [this message]
2017-06-16 0:29 ` Masahiro Yamada
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=1497445867.6424.36.camel@synopsys.com \
--to=alexey.brodkin@synopsys.com \
--cc=Vineet.Gupta1@synopsys.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=mmarek@suse.com \
--cc=yamada.masahiro@socionext.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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