If OpenJDK requires en-us environment, then nothing needs to be changed. Please 
ignore this thread.

________________________________
发件人: David Holmes <david.hol...@oracle.com>
发送时间: 2023年11月3日 13:13
收件人: 吴 国璋 <zcxsythe...@outlook.com>; build-dev@openjdk.org 
<build-dev@openjdk.org>
主题: Re: Cannot configure on Windows in Chinese Environment

Notwithstanding what was done in 2013 to try and be more locale tolerant
with cl.exe:

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openjdk.org%2Fpipermail%2Fbuild-dev%2F2013-October%2F010444.html&data=05%7C01%7C%7Cb4e7e71693064ce44a6808dbdc2bb17e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638345852459562317%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HA7Es%2BMQGUbtrkVNFlawOr26%2FMy48Qi1Fc%2FnUdFTkws%3D&reserved=0<https://mail.openjdk.org/pipermail/build-dev/2013-October/010444.html>

I think the basic position is that supported building of OpenJDK
requires a US-English locale and toolchain. For some reason this never
made it into the build documentation though.

I suspect that even if you fix the version check in configure, you will
then run into further locale issues.

Cheers,
David

On 3/11/2023 7:50 am, 吴 国璋 wrote:
> Thanks, I will take a look.
>
> Because I am new here, according to the developer's guide, I need to
> find a sponsor, who helps me create an issue in jira, before I can
> submit a pull request. Is there anyone who wants to help me?
> ------------------------------------------------------------------------
> *发件人:* Robbin Ehn <r...@rivosinc.com>
> *发送时间:* 2023年11月2日 23:06
> *收件人:* 吴 国璋 <zcxsythe...@outlook.com>; build-dev@openjdk.org
> <build-dev@openjdk.org>
> *抄送:* jdk-...@openjdk.org <jdk-...@openjdk.org>
> *主题:* Re: Cannot configure on Windows in Chinese Environment
> Hi,
>
> You should not need to add any simple C files.
> You should be able to use: AC_LANG_CONTEST, AC_LANG_PROGRAM and
> friends to check those defines.
>
> Also build-dev@openjdk.org is your friend, added.
>
> /Robbin
>
> On Thu, Nov 2, 2023 at 3:07 PM 吴 国璋 <zcxsythe...@outlook.com> wrote:
>>
>> Hi team,
>>
>>
>>
>> I discovered a problem while running `bash configure` on Windows platform in 
>> Chinese environment. The command fails, complaining CPU mismatch.
>>
>>
>>
>> > configure: error: Target CPU mismatch. We are building for x86_64 but CL 
>> > is for "版"; expected "x64".
>>
>>
>>
>> There is also a warning complaining version mismatch:
>>
>>
>>
>> > configure: WARNING: You are using microsoft 用于 x64 的 Microsoft (R) C/C++ 
>> > 优化编译器 19.37.32825 版 which is older than 19.28.0.0. This is not a supported 
>> > configuration.
>>
>>
>>
>> The line "用于 x64 的 Microsoft (R) C/C++ 优化编译器 19.37.32825 版" is output by 
>> `cl.exe`. In English environment, it should be "Microsoft (R) C/C++ 
>> Optimizing Compiler Version 19.37.32825 for x64".
>>
>>
>>
>> Therefore, several questions arise, and I will try to answer them below.
>>
>>
>>
>> 1. Does JDK welcome localized Visual Studio?
>>
>>
>>
>> I read the file `make/autoconf/toolchains.m4` and found the following 
>> comment:
>>
>>
>>
>> >   elif test  "x$TOOLCHAIN_TYPE" = xmicrosoft; then
>>
>> >     # There is no specific version flag, but all output starts with a 
>> > version string.
>>
>> >     # First line typically looks something like:
>>
>> >     # Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 
>> > 16.00.40219.01 for 80x86
>>
>> >     # but the compiler name may vary depending on locale.
>>
>> >     COMPILER_VERSION_OUTPUT=`$COMPILER 2>&1 1>/dev/null | $HEAD -n 1 | $TR 
>> > -d '\r'`
>>
>>
>>
>> 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.
>>
>>
>>
>> 2. How can the problem be solved?
>>
>>
>>
>> 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
> then the issue can be solved.
>>
>>
>>
>> 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?)
>>
>>
>>
>> 3. What is the best solution?
>>
>>
>>
>> According to MSVC reference, a solid way to get the MSVC version and the 
>> target CPU is via predefined macros.
>>
>>
>>
>> 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.
>>
>>
>>
>> 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.
>>
>>
>>
>> The reference page is at 
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flearn.microsoft.com%2Fen-us%2Fcpp%2Fpreprocessor%2Fpredefined-macros%3Fview%3Dmsvc-170&data=05%7C01%7C%7Cb4e7e71693064ce44a6808dbdc2bb17e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638345852459562317%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ZCq81ekKfgLcB3ctwQXfqu03bWgalRB%2BuGEkcJZAnMg%3D&reserved=0<https://learn.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-170>
>>  
>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flearn.microsoft.com%2Fen-us%2Fcpp%2Fpreprocessor%2Fpredefined-macros%3Fview%3Dmsvc-170&data=05%7C01%7C%7Cb4e7e71693064ce44a6808dbdc2bb17e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638345852459562317%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ZCq81ekKfgLcB3ctwQXfqu03bWgalRB%2BuGEkcJZAnMg%3D&reserved=0<https://learn.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-170>>
>>  .
>>
>>
>>
>> To use these macros, we may need to add 4 .c files. For example, if we need 
>> to get the MSVC version, let's create a file `get_msvc_version.c`. This file 
>> is absolutely simple and it just contains eight characters:
>>
>>
>>
>> _MSC_VER
>>
>>
>>
>> Then we can use cl.exe to prepocess this .c file:
>>
>>
>>
>> > $ cl /EP get_msvc_version.c
>>
>> > 用于 x64 的 Microsoft (R) C/C++ 优化编译器 19.37.32825 版
>>
>> > 版权所有(C) Microsoft Corporation。保留所有权利。
>>
>> >
>>
>> > get_msvc_version.c
>>
>> >
>>
>> > 1937
>>
>>
>>
>> The last line `1937` contains the MSVC version, a pure number which will not 
>> be impacted by localizations. We may use `tail` command to get it.
>>
>>
>>
>> We can use similar methods to get the target CPU.
>>
>>
>>
>> 4. How many changes need to be made?
>>
>>
>>
>> - Four new simple .c files (which do not contain any "real" C code). Maybe a 
>> new folder to place them.
>>
>> - `make/autoconf/toolchain.m4`, Lines 425 to 441 and 983 to 997.
>>
>> - No change needed in any API or implementation of Java.
>>
>>
>>
>> Guozhang Wu (吴国璋)
>>
>> GitHub: zcxsythenew
>>
>> GitHub anonymous email: 30565051+zcxsythe...@users.noreply.github.com

Reply via email to