On 8/10/2013 2:28 AM, Francis ANDRE wrote:
Le 07/10/2013 11:32, Magnus Ihse Bursie a écrit :
On 2013-10-06 05:19, David Holmes wrote:
Magnus,
Echoing Naoto's comments I don't agree that we should be supporting
this. In the original email a workaround was mentioned using an
environment variabl
Hi Magnus,
I think we need to make it clear that the locale we support for building
the JDK is US English, which is proven to work, and it should be
documented in README-builds.html or similar. Your change in configure
script looks good, in order for passing non-English CL.EXE through, but
I
Le 07/10/2013 11:32, Magnus Ihse Bursie a écrit :
On 2013-10-06 05:19, David Holmes wrote:
Magnus,
Echoing Naoto's comments I don't agree that we should be supporting this. In
the original email a workaround was mentioned using an environment variable -
if that is the case then I don't think
On 2013-10-06 05:19, David Holmes wrote:
Magnus,
Echoing Naoto's comments I don't agree that we should be supporting
this. In the original email a workaround was mentioned using an
environment variable - if that is the case then I don't think we need
to do anything here. Even if not, who know
Magnus,
Echoing Naoto's comments I don't agree that we should be supporting
this. In the original email a workaround was mentioned using an
environment variable - if that is the case then I don't think we need to
do anything here. Even if not, who knows how many other languages we
might have
Magnus,
Besides general discussion of multi-language locale
fix looks good for me,
but I would prefer to have more generic comments there like
"support for different formats of msvc version output"
because the fix isn't french specific.
-Dmitry
On 2013-10-04 17:12, Magnus Ihse Bursie wrote:
Francis,
We have exactly the same (or may be ever worse) problems in russia but I
still think it's good to stay with english locale during build.
1. Try applocale -
http://www.microsoft.com/en-us/download/details.aspx?id=13209
not sure it works for modern windows, for windowsXP it solved the pr
It's true that Microsoft VS follows the settings in the Control Panel (I
doubt it looks at LANG/LC_ALL, as they are POSIX env vars), I think we
will have to live with it, as that's the way Microsoft does their
internationalization.
Naoto
On 10/4/13 11:04 AM, Francis ANDRE wrote:
Changing the
Changing the LANG to C or en_US does not work neither. The VS C++ compiler does
not use the LANG variable for providing messages. I know that on WXP, there are
options to setup the language of work like English but I cannot turn my PC to
English because others tools like Excel will work in Engli
The issue here (and the reason why the rule is to run build in en_US) is
that the build would be error prone if we allow running builds in
locales other than US English. In the past, we had several build errors
related to this, e.g., 'date' command produced differently formatted
date string for
I agree that the general rule is to build in an English environment.
Unfortunately, on Windows, it is not as trivial, nor often possible to get
tools to produce different output by setting a locale. It is not the case with
cl.exe, anyway. And in this case, Microsoft apparently does not provide t
Hi Magnus,
Well, it would work for Latin languages, but not for others, e.g., CJK.
I thought that the general rule was to run the build in English
environment. I would think that French CL.EXE would produce English
version string on Windows configured for en_US locale.
Naoto
On 10/4/13 6:12
Bug: https://bugs.openjdk.java.net/browse/JDK-8025933
In France, it's not possible to download the English version of Visual
Studio; hence CL.EXE presents itself as:
Compilateur d'optimisation Microsoft (R) 32 bits C/C++ version
16.00.30319.01 pour 80x86
instead of
Microsoft (R) 32-bit C/C++ O
13 matches
Mail list logo
