<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 2023-11-14 15:41, Magnus Ihse Bursie
wrote:<br>
</div>
<blockquote type="cite" cite="mid:57db7f21-42e9-437e-8fe9-cf49257d5428@oracle.com">
<p>On 2023-11-06 15:56, 吴国璋 wrote:</p>
<blockquote type="cite" cite="mid:SJ0PR14MB662647ACC1BF903DA542C779B2AAA@SJ0PR14MB6626.namprd14.prod.outlook.com">
<div dir="auto">Thanks Magnus for your opionion. Just one thing
to point out: reaching out to Microsoft is not needed. Here is
the reason:
<div dir="auto"><br>
</div>
<div dir="auto">If Visual Studio is installed with both
English and another language pack, cl.exe will present
itself in English while running configure.</div>
<div dir="auto"><br>
</div>
<div dir="auto">If Visual Studio is installed without English
language pack, cl.exe will present itself in an installed
language.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Therefore now the issue is that the
documentation needs to be improved.</div>
</div>
</blockquote>
<p>That is great news! While I'm still slightly worried that there
can be other issues lurking around the corner with a non-en-US
locale, if the Microsoft toolchain is in English it would at
least take care of the majority of the problems. There are two
other broad categories of tools we're running in the build, java
tools and "unix" (cygwin) tools. The former are already using
the proper locale using -Duser.language=en -Duser.country=US,
and the latter using LC_ALL=C. Apart from this, the compiler
toolchain is the major source of issues.</p>
<p>However, I'd like to have some more investigation into how
cl.exe picks the language. <br>
</p>
</blockquote>
<p>I googled this a bit, and found the following reference:</p>
<p><a class="moz-txt-link-freetext" href="https://learn.microsoft.com/en-us/visualstudio/install/install-visual-studio?view=vs-2022#step-6---install-language-packs-optional">https://learn.microsoft.com/en-us/visualstudio/install/install-visual-studio?view=vs-2022#step-6---install-language-packs-optional</a></p>
<p>It claims:</p>
<blockquote type="cite">
<p>Another way that you can change the default language is by
running the installer from the command line.
For example, you can force the installer to run in English by
using the following command:</p>
<code class="lang-shell" data-author-content="vs_installer.exe --locale en-US
"><span>vs_installer.exe --locale en-US</span></code>
</blockquote>
<p><br>
</p>
<p>but it is not clear to me if that changes the default language
for just the GUI of the installer, or the default language of the
installed tools. If it is the latter, we should document this
command, or even try to have the build system run it
automatically.</p>
<p>Can you help me check this out?<br>
</p>
<p>/Magnus<br>
</p>
<p><br>
</p>
<blockquote type="cite" cite="mid:57db7f21-42e9-437e-8fe9-cf49257d5428@oracle.com">
<p>Is it a hard-coded behavior that it always picks English if it
is installed? If so, it does not really make sense to have more
than one language pack installed. Or is there some way to tell
cl.exe which language to pick? Perhaps we send those signals
without realizing it, like if it happens to look at LC_ALL. If
that is the case, we need to know about this, so we don't
inadvertently break it.</p>
<p>I have never installed a VS language pack. Is it installed like
other VS components?</p>
<p>/Magnus<br>
</p>
<p><br>
</p>
<p><br>
</p>
<blockquote type="cite" cite="mid:SJ0PR14MB662647ACC1BF903DA542C779B2AAA@SJ0PR14MB6626.namprd14.prod.outlook.com">
<div dir="auto">
<div dir="auto"><br>
</div>
<div dir="auto">Before I sent the original email, I tried to
find out whether JDK welcomes other languages, and I found
in the code that JDK did pay some effort for supporting
them, so I assumed that an en-us environment is not
required. Since it is not the case, then the documentation
needs improvement.</div>
<div dir="auto"><br>
</div>
<div dir="auto">In details, the documentation needs the
following modification:</div>
<div dir="auto"><br>
</div>
<div dir="auto">- It needs to advice developers to install
Visual Studio English language pack, if they speak another
language as their mother tongue;</div>
<div dir="auto">- Switching the Windows system to English is
not required (I tried it several times, just installing the
language pack can solve)</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2023年11月6日 21:00，Magnus Ihse Bursie <a class="moz-txt-link-rfc2396E" href="mailto:magnus.ihse.bursie@oracle.com" moz-do-not-send="true"><magnus.ihse.bursie@oracle.com></a>写道：<br type="attribution">
<blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<p>Let me expand a bit on what Erik says, and also
somewhat contradict him. :-)</p>
<p>There is an open bug for documenting that en-US
locale is needed to build the JDK on Windows: <a href="https://bugs.openjdk.org/browse/JDK-8264425" moz-do-not-send="true" class="moz-txt-link-freetext">https://bugs.openjdk.org/browse/JDK-8264425</a></p>
<p>Unfortunately I have never gotten around to actually
write this down in the docs. I'll try to prioritize
it, since it's a simple fix and can help others in
your position.</p>
<p>To expand on what Erik says: Yes, we have no
principal opinion discriminating against non en-US
locale support, and in general we accept patches that
help users build in different scenarios. For
non-Windows platforms, all user locales are supported,
since we can set LC_ALL=C in the build and run with an
international locale.</p>
<p>Unfortunately, this or any other method of
temporarily changing the locale is not supported on
Windows. :-( There have been several attempts over the
year to overcome this problem, none of which has been
successful. (You can search the archives of this
mailing list for examples.) Therefore the conclusion,
after the last such effort, was that we can only ever
support building on en-US on Windows.<br>
</p>
<p>The problem on supporting the JDK on a different
locale is that there are so many small things that can
go wrong. Just to give an example on the top of my
mind: a few weeks ago, the code that set the en-US
locale to jtreg testing went AWOL. This caused some
jtreg test runs to fail on a Swiss (iirc) locale,
since that used a quote (´) as thousands separator,
which caused parse errors.</p>
<p>Getting stuck on the version parsing of the compiler
is just the very first steps on a road filled with
pain and suffering.</p>
<p>So, to contradict with what Erik says: No, I don't
think we should accept a patch that changes version
determination for cl.exe from string parsing to
compiling macros. </p>
<p>There are several reasons: compiling code in
configure is always tricky. This would be done before
we have even determined what compiler we have or what
version it is. We used to have a binary "fixpath" tool
that was compiled early on, it was a constant source
of trouble, and have now been removed due to those
problems.<br>
</p>
<p>This would also add complexity to the configure
script, since a trivial method (read and parse the
output of running with --version or similar) that is
shared by all compilers, now need to be replaced with
a different method for cl.exe only.</p>
<p>If this was guaranteed to be the only things needed
to make the JDK build and test on non-en-US locales,
then I could probably consider it. But it is highly
unlikely to be. And even if the build passes without
error, I would be pretty wary about assuming that the
build is actually identical to one built on the
"official" locale.</p>
<p>I encourage you to get in touch with Microsoft and
request them to add a solution similar to LC_ALL, so
processes can run in a different locale than the
default user locale. I realize a single voice does not
convince them, but if the message is repeated over and
over from all kinds of developers, it might have some
effect.</p>
<p>/Magnus<br>
</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<div>On 2023-11-04 13:12, 吴 国璋 wrote:<br>
</div>
<blockquote>
<div>
<p>If making the build work on different locales is
accepted, then we can further discuss on this
topic.</p>
<p> </p>
<p>I would like to implement this with C macros
instead of parsing the output, because the MSVC
reference includes the C predefined macros, but
does not include the output format.</p>
<p> </p>
<p>In fact, Visual Studio supports 14 language
packs, and I only know how cl.exe presents itself
in English and Chinese, maybe also French. Maybe
the sentence structure is also different in Korean
or Japanese, I am not sure. With C macros the
implementation will be less impacted by locale and
more stable.<span style="font-size:12pt"></span></p>
<p> </p>
<div style="border:none;border-top:solid #e1e1e1 1pt;padding:3pt 0cm 0cm 0cm">
<p style="border:none;padding:0cm"><b>From: </b><a href="mailto:erik.joelsson@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">erik.joelsson@oracle.com</a><br>
<b>Sent: </b>2023年11月3日 21:04<br>
<b>To: </b><a href="mailto:zcxsythenew@outlook.com" moz-do-not-send="true">吴 国璋</a>; <a href="mailto:david.holmes@oracle.com" moz-do-not-send="true"> David Holmes</a>; <a href="mailto:build-dev@openjdk.org" moz-do-not-send="true" class="moz-txt-link-freetext">build-dev@openjdk.org</a><br>
<b>Subject: </b>Re: Cannot configure on Windows
in Chinese Environment</p>
</div>
<p><span style="font-size:12pt;font-family:'simsun'"> </span></p>
<div>
<p>On 11/2/23 22:18, 吴 国璋 wrote:<span style="font-size:12pt"></span></p>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<p>If OpenJDK requires en-us environment, then
nothing needs to be changed. Please ignore
this thread.</p>
</div>
</blockquote>
<p>I should clarify this a bit. We aren't against
making the build work on different locales, but
most of us are unable to verify that it keeps
working on anything by US-English. If you are
willing to put in the work to make it work in a
Chinese environment, and the set of changes
required seem reasonable, we would accept that
contribution. Just be prepared to maintain that
support over time, as it's quite likely that
future changes may break it.</p>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<p>>> </p>
<div>
<div>
<p>>> 1. Does JDK welcome localized
Visual Studio?<br>
>> I read the file
`make/autoconf/toolchains.m4` and found the
following comment:<br>
>> > elif test
"x$TOOLCHAIN_TYPE" = xmicrosoft; then<br>
>> > # There is no specific
version flag, but all output starts with a
version string.<br>
>> > # First line typically
looks something like:<br>
>> > # Microsoft (R) 32-bit
C/C++ Optimizing Compiler Version
16.00.40219.01 for 80x86<br>
>> > # but the compiler name
may vary depending on locale.<br>
>> >
COMPILER_VERSION_OUTPUT=`$COMPILER
2>&1 1>/dev/null | $HEAD -n 1 |
$TR -d '\r'`<br>
>><br>
>> Therefore, it can be inferred that
JDK knows that there are different
localizations of Visual Studio and is ready
for them. JDK thinks that maybe there will
be different names of "Optimizing Compiler"
or others. However, in some languages, the
whole structure of the sentence is
completely different, not just the names.</p>
</div>
</div>
</blockquote>
<p>So far we have only received contributions for
different western type languages, so the current
parsing logic has only been adapted for that.<br>
<br>
<span style="font-size:12pt"></span></p>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<div>
<p>>> 2. How can the problem be solved?<br>
>> One solution is to change the way
to parse the output of `cl.exe`. For
example, JDK treat the last word separated
by a blank as the target CPU, which is "x64"
in English environment but "版" in Chinese
environment. (`make/autoconf/toolchain.m4`,
Lines 983 to 997.) We may use `grep`
command to search for "x64" directly, and <br>
> then the issue can be solved.<br>
>> However, this solution is not good
enough, because it is also based on parsing
the output, which is intended to be read by
human, not by scripts. (What if "x64" is
changed into "64-bit" or "64 位" in a future
version?)</p>
</div>
</div>
</blockquote>
<p>If the output changes, we adapt the regex. We
need explicit changes to support a new major
version of Visual Studio anyway, so it would be
done as part of those changes. The likelihood of
it changing in a minor update is basically non
existent.<br>
<br>
<span style="font-size:12pt"></span></p>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<div>
<p>>> 3. What is the best solution?<br>
>> According to MSVC reference, a
solid way to get the MSVC version and the
target CPU is via predefined macros.<br>
>> To get the MSVC version, we can use
`_MSC_VER`. When Visual Studio 2019 is used,
the macro evaluates between 1920 and 1929.
When Visual Studio 2022 is used, the macro
evaluates above 1930.<br>
>> To get the target CPU, we can use
`_M_X64`, `_M_IX86`, `_M_ARM` and
`_M_ARM64`. For example, if the target CPU
is x64, `_M_X64` will be evaluated to 100,
and the other three macros are undefined.</p>
</div>
</div>
</blockquote>
<p>Using the C preprocessor may work, but as Robbin
pointed out, we would prefer if you used one of
the Autoconf macros for generating the input files
and running it if you were to go that route.
However, I think I would prefer if you could just
adapt the current logic for parsing the compiler
version output.</p>
<p>/Erik</p>
<p><span style="font-size:12pt;font-family:'simsun'"> </span></p>
</div>
</blockquote>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
</blockquote>
</body>
</html>