[Qemu-devel] [Patch 0/2] Fix QEMU configure / make with Turkish (and maybe other) locale

[Qemu-devel] [Patch 0/2] Fix QEMU configure / make with Turkish (and maybe other) locale

[Stefan Weil]

These two patches override the user specific locale settings which
can break QEMU builds. They set the default locale C for configure
and make:

[PATCH v2 1/2] Makefile: Set default locale C
[PATCH 2/2] configure: Set default locale C (fix build for Turkish

A side effect is that all messages which are produced during configure
and make also use the default locale, so for example compiler messages
are no longer localized.

I don't know whether this is a problem for anybody. If it is, setting
LANGUAGE (which is unset at least in Debian installations) might help.

Regards,
Stefan Weil

[Qemu-devel] [PATCH v2 1/2] Makefile: Set default locale C

[Stefan Weil]

Some locale settings let make fail or create wrong results,
so set always the C locale.

* Conversion from lower to upper case with tr does not convert
  lower case 'i' to 'I' with locale tr_TR.UTF-8. This results in
  wrong entries in config-host.h like these ones:

  #define CONFIG_QEMU_PREFiX "/usr/local"
  #define CONFIG_QEMU_BiNDiR "/usr/local/bin"

  This problem was reported by Emre Ersin.

* The html files created from texi input contain non english
  titles like "Anhang" with locale de_DE.UTF-8.

The locale variables are not explicitly exported here to avoid
possible problems with the 'export' keyword. Either they are
already environment variables when make is called - then the
new values are passed to child processes, or there are no such
environment variables - then the default value C is used.

v2:
Enhanced commit message.

Signed-off-by: Stefan Weil <sw@weilnetz.de>
---
 Makefile |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/Makefile b/Makefile
index 8d6b558..3f899e2 100644
--- a/Makefile
+++ b/Makefile
@@ -37,6 +37,11 @@ $(call set-vpath, $(SRC_PATH):$(SRC_PATH)/hw)
 
 LIBS+=-lz $(LIBS_TOOLS)
 
+# Set default locale for commands like tr and others.
+LANG=C
+LC_ALL=C
+LC_CTYPE=C
+
 HELPERS-$(CONFIG_LINUX) = qemu-bridge-helper$(EXESUF)
 
 ifdef BUILD_DOCS
-- 
1.7.9

[Qemu-devel] [PATCH 2/2] configure: Set default locale C (fix build for Turkish locale)

[Stefan Weil]

Some locales don't work with QEMU's configure because they
don't convert lower case to upper case as expected.

With the Turkish locale tr_TR.UTF-8 for example the command 'tr'
does not convert lower case 'i' which results in wrong definitions
in some target specific config-target.mak files:

TARGET_CRiS=y
TARGET_i386=y
TARGET_MiCROBLAZE=y
TARGET_MiPS64=y
TARGET_MiPS=y
TARGET_UNiCORE32=y

Setting the default locale C in configure avoids this problem.

Signed-off-by: Stefan Weil <sw@weilnetz.de>
---
 configure |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index 14ef738..2eab795 100755
--- a/configure
+++ b/configure
@@ -2,6 +2,11 @@
 #
 # qemu configure script (c) 2003 Fabrice Bellard
 #
+# Set locale to C (needed for tr).
+export LANG=C
+export LC_ALL=C
+export LC_CTYPE=C
+
 # set temporary file name
 if test ! -z "$TMPDIR" ; then
     TMPDIR1="${TMPDIR}"
-- 
1.7.9

Re: [Qemu-devel] [Patch 0/2] Fix QEMU configure / make with Turkish (and maybe other) locale

[Andreas Färber]

Am 25.03.2012 21:11, schrieb Stefan Weil:
> These two patches override the user specific locale settings which
> can break QEMU builds. They set the default locale C for configure
> and make:
> 
> [PATCH v2 1/2] Makefile: Set default locale C
> [PATCH 2/2] configure: Set default locale C (fix build for Turkish
> 
> A side effect is that all messages which are produced during configure
> and make also use the default locale, so for example compiler messages
> are no longer localized.

Reading the patches I thought of that issue, too, and don't think a
sledge hammer is the best solution here. The issue reported was tr (a
user-invisible invokation) misbehaving so why not fix just that? That
way user-directed output would still be in the language of the user's
choice.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [Patch 0/2] Fix QEMU configure / make with Turkish (and maybe other) locale

[Stefan Weil]

Am 25.03.2012 21:27, schrieb Andreas Färber:
> Am 25.03.2012 21:11, schrieb Stefan Weil:
>> These two patches override the user specific locale settings which
>> can break QEMU builds. They set the default locale C for configure
>> and make:
>>
>> [PATCH v2 1/2] Makefile: Set default locale C
>> [PATCH 2/2] configure: Set default locale C (fix build for Turkish
>>
>> A side effect is that all messages which are produced during configure
>> and make also use the default locale, so for example compiler messages
>> are no longer localized.
>
> Reading the patches I thought of that issue, too, and don't think a
> sledge hammer is the best solution here. The issue reported was tr (a
> user-invisible invokation) misbehaving so why not fix just that? That
> way user-directed output would still be in the language of the user's
> choice.
>
> Andreas

The answer is quite simple: there are lots of places where tr
is already used which would have to be modified (in configure
and several other scripts), and it's not only tr but also
the process which creates the html documentation which depends
on the locale (see commit message of patch 1).

As you see in my patch, I had to override three environment
variables to (hopefully) handle all cases which lead to wrong
results, so adding these overrides to each invocation of tr
or other programs which need it would result in rather long
command lines.

Of course many different solutions are possible. We could also
add a tr wrapper script, but I still prefer my solution because
it is easy and clean (only two locations which set the environment)
and safe (also works for problems which might exist and which we
still don't know, no problem when more scripts and external
programs like tr are added by future modifications).

Regards,
Stefan

Re: [Qemu-devel] [Patch 0/2] Fix QEMU configure / make with Turkish (and maybe other) locale

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 466 bytes --]

On 03/25/2012 01:48 PM, Stefan Weil wrote:
> As you see in my patch, I had to override three environment
> variables to (hopefully) handle all cases which lead to wrong
> results,

Technically, you only have to modify LC_ALL.  Modifications to LANG and
LC_CTYPE are pointless once LC_ALL is set, at least on any
standards-compliant i18n platform.

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 620 bytes --]

Re: [Qemu-devel] [Patch 0/2] Fix QEMU configure / make with Turkish (and maybe other) locale

[Peter Maydell]

On 25 March 2012 20:27, Andreas Färber <afaerber@suse.de> wrote:
> Am 25.03.2012 21:11, schrieb Stefan Weil:
>> These two patches override the user specific locale settings which
>> can break QEMU builds. They set the default locale C for configure
>> and make:
>>
>> [PATCH v2 1/2] Makefile: Set default locale C
>> [PATCH 2/2] configure: Set default locale C (fix build for Turkish
>>
>> A side effect is that all messages which are produced during configure
>> and make also use the default locale, so for example compiler messages
>> are no longer localized.
>
> Reading the patches I thought of that issue, too, and don't think a
> sledge hammer is the best solution here. The issue reported was tr (a
> user-invisible invokation) misbehaving so why not fix just that? That
> way user-directed output would still be in the language of the user's
> choice.

Well, configure should just set the locale to C, I think. This is how
autoconf-generated configure scripts behave, for example. The rationale
here is that configure shouldn't be outputting anything except (a) output
to log files etc and (b) messages we control [and which we don't localise
anyway!]. So we should favour not making it easy to accidentally
introduce obscure bugs in some locales.

For make itself the argument is less clear-cut because as you say
compiler messages go to the user.

-- PMM

Re: [Qemu-devel] [Patch 0/2] Fix QEMU configure / make with Turkish (and maybe other) locale

[Stefan Weil]

Am 25.03.2012 21:52, schrieb Peter Maydell:
> On 25 March 2012 20:27, Andreas Färber <afaerber@suse.de> wrote:
>> Am 25.03.2012 21:11, schrieb Stefan Weil:
>>> These two patches override the user specific locale settings which
>>> can break QEMU builds. They set the default locale C for configure
>>> and make:
>>>
>>> [PATCH v2 1/2] Makefile: Set default locale C
>>> [PATCH 2/2] configure: Set default locale C (fix build for Turkish
>>>
>>> A side effect is that all messages which are produced during configure
>>> and make also use the default locale, so for example compiler messages
>>> are no longer localized.
>>
>> Reading the patches I thought of that issue, too, and don't think a
>> sledge hammer is the best solution here. The issue reported was tr (a
>> user-invisible invokation) misbehaving so why not fix just that? That
>> way user-directed output would still be in the language of the user's
>> choice.
>
> Well, configure should just set the locale to C, I think. This is how
> autoconf-generated configure scripts behave, for example. The rationale
> here is that configure shouldn't be outputting anything except (a) output
> to log files etc and (b) messages we control [and which we don't localise
> anyway!]. So we should favour not making it easy to accidentally
> introduce obscure bugs in some locales.

I fully agree.

>
> For make itself the argument is less clear-cut because as you say
> compiler messages go to the user.
>
> -- PMM

For make, it is still possible to set LANGUAGE.
I don't know whether it works with gcc (none of my native and
cross gcc installations has localized messages installed),
but I tested setting LANGUAGE with 'ls --help' where it works.

And compiler messages go first to the user, but sometimes also
to other developers (bug reports!), so even there are good
arguments for the C locale.

Regards,
Stefan W.