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 problem. 2. Personally I use virtual box and virtual image. It allows me to have clean window in one click when its behaviour become strange. -Dmitry On 2013-10-04 22:04, Francis ANDRE wrote: > 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 English with the decimal point as '.' instead of the > ',' for France... The setup of the language for WS Studio is just the > one you choose at download time -- much like the JDK of Sun for Japanese > or Chinese --; The point here is that I succeed in downloading the ENU > VS2010 version but after the installation, it is the French version that > runs.... > > Anyhow, I think that for this specific case of VS C++ which is not a > compiler that follows the Linux/Cygwin rules --ie LANG=en_US, one should > provide a way to support non en_US VS C++ compiler for computing the > vervion used. > > Francis > Le 04/10/2013 19:16, Naoto Sato a écrit : >> 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 each locale which resulted in build errors. >> >> Naoto >> >> On 10/4/13 9:42 AM, Magnus Ihse Bursie wrote: >>> 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 the English version to French users. >>> Hence this fix. >>> >>> /Magnus >>> >>> 4 okt 2013 kl. 18:18 skrev Naoto Sato <naoto.s...@oracle.com>: >>> >>>> 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 AM, Magnus Ihse Bursie wrote: >>>>> 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++ Optimizing Compiler Version 16.00.30319.01 >>>>> for 80x86 >>>>> >>>>> With a simple fix we can handle this in configure as well. >>>>> >>>>> WebRev: >>>>> http://cr.openjdk.java.net/~ihse/JDK-8025933-configure-support-french-cl.exe/webrev.01 >>>>> >>>>> >>>>> >>>>> /Magnus >>>> >> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.
