RFR: 8263028: Windows build fails due to several treat-warning-as-errors
Yi Yang
yyang at openjdk.java.net
Mon Mar 29 14:44:28 UTC 2021
On Mon, 29 Mar 2021 09:56:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:
>> @kelthuzadx Hi Yang,
>>
>> Setting locale to US English used to be documented as a build requirement. When the "new" build-infra system was introduced several years ago, we thought that all locale-dependent issues were solved, and removed that requirement. Later on, issues crept in on non-Windows platforms, but these were handled by setting LC_ALL=C in the build system itself while building.
>>
>> The problem with requiring US English as locale on Windows is that you cannot set that for a single process, but must change the entire system locale for the user (which also often requires a reboot). Otoh, if we do *not* require US English, the test matrix grows almost without bounds, and we might run into a lot of weird problems (like this one!).
>>
>> So I'm not really comfortable with just patching around this issue, since:
>> a) it does not occur in what is at least the "recommended" locale, and
>> b) more issues are likely to creep up in the future (in fact, there might already be testing issues as Jorn says)
>>
>> On the other hand, I am not really comfortable either with just stating in the build document that US English is the only supported Windows locale, since it has such far-reaching consequences for the individual developers.
>>
>> In short, I'm torn between two bad solutions, but I'm definitely leaning towards the latter. If only there were some way of setting the locale just for cl.exe! :-(
>
> I searched the net once more for setting the locale, and this time I found some creative workarounds on superuser. The suggestion is to create a *secondary* user account, and set US English as locale for that account. Then you can go back to your main account, and us the "Run as..." functionality to execute an arbitrary command as that user.
>
> This could be done by: `%comspec% runas /profile /user:yourotheruser "the_application_you_want_ to_run_in_english"` or using the GUI (shift+right click on the icon, select `Run as different user`).
>
> I assume you would be able to start a cygwin shell like this, and have all processes started in that shell belonging to this US English user.
>
> @kelthuzadx Can you please verify if this method works? If so, I believe it is convenient enough for us to be able to require US English locale for building on Windows.
Hi Magnus,
> I searched the net once more for setting the locale, and this time I found some creative workarounds on superuser. The suggestion is to create a secondary user account, and set US English as locale for that account. Then you can go back to your main account, and us the "Run as..." functionality to execute an arbitrary command as that user.
> This could be done by: %comspec% runas /profile /user:yourotheruser "the_application_you_want_ to_run_in_english" or using the GUI (shift+right click on the icon, select Run as different user).
Thanks for your investigations and kind suggestions. It is more troublesome to add new a user to the Chinese system and set its system locale to English. Instead of doing this, I prefer to directly change the system locale to English.
When I set the system locale to English(`Control Panel->Change date, time,...->Administrative->Change System locale->English`), and it indeed works for building! No warnings were generated. All works fine.
> a) it does not occur in what is at least the "recommended" locale, and
> b) more issues are likely to creep up in the future (in fact, there might already be testing issues as Jorn says)
> On the other hand, I am not really comfortable either with just stating in the build document that US English is the only supported Windows locale, since it has such far-reaching consequences for the individual developers.
You convinced me, I agree with you that stating these has far-reaching consequences and your internal test matrix will become incredibly heavy. However, I think we can add a section in the FAQ or other places in the building document to give a solution for such problems as much as possible, e.g.
Q: Why I can not build JDK on a non-English system? What should I do next?
A: Maybe you can change your system locale to English and try again
Just IMHO, :-)
Best Regards,
Yang
-------------
PR: https://git.openjdk.java.net/jdk/pull/3107
More information about the hotspot-runtime-dev
mailing list