RFR: 8263028: Windows build fails due to several treat-warning-as-errors

[Magnus Ihse Bursie]

On Mon, 29 Mar 2021 09:44:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>>> Based on Ioi's suggestion I decided to try with a different locale as well. I tried setting my system locale to something else and with that I was able to reproduce the warnings you report, so it _could_ be an issue with locale settings. AFAIK only `en-us` is supported. Maybe you could confirm/check your locale settings as well? (can run `systeminfo` to get the current setting)
>>> 
>>> I've had problems in the past as well because I had the wrong locale set, and some of the tests were failing because of that. So, maybe rather than disabling the warnings, it might be more prudent to change the system locale of the used build systems to prevent similar issues in the future (FWIW, the display language doesn't seem to affect `cl` so that could still be whatever is convenient).
>> 
>> Hi Jorn,
>> 
>> Sorry for the delayed response. I set the locale of my Cygwin environment to en-us via  `export LC_ALL="en_US.UTF-8"`, these warnings are generated when compiling as well as before. Should I change this setting globally instead of just changing it in Cygwin?
>> 
>> Anyway, it seems that this problem is caused by the locale setting because as you mentioned, this problem appears when you change the locale setting to Chinese. Setting the locale to English does not have this problem. I checked the building document, but there is no mention of the need to set the locale option to en-us before building JDK. If this is really a necessary step for building, I think we should add this step in the building document, otherwise, I think we should fix this problem in HotSpot.
>> 
>> Best Regards
>> Yang
>
> @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.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3107