On Thu, 4 Jan 2024 17:26:37 GMT, Naoto Sato wrote:
> 8322647: Short name for the `Europe/Lisbon` time zone is incorrect
This pull request has now been integrated.
Changeset: a72afb38
Author:Naoto Sato
URL:
https://git.openjdk.org/jdk22/commit/a72afb3845a7d245d462904e75b9368efefc0d39
On Thu, 4 Jan 2024 17:26:37 GMT, Naoto Sato wrote:
> 8322647: Short name for the `Europe/Lisbon` time zone is incorrect
Marked as reviewed by joehw (Reviewer).
-
PR Review: https://git.openjdk.org/jdk22/pull/30#pullrequestreview-1804685583
8322647: Short name for the `Europe/Lisbon` time zone is incorrect
-
Commit messages:
- Backport ad31ec5c5f120082cedd7b9ece45b6b44147c0c5
Changes: https://git.openjdk.org/jdk22/pull/30/files
Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=30&range=00
Issue: https://bugs.openjd
>>
>> It looks like there is code to attempt to deal with that sort of thing in our
>> build system. See TOOLCHAIN_POST_DETECTION in make/autoconf/toolchain.m4.
>> That
>> dates back to JDK 9. However, that only deals with CFLAGS and CXXFLAGS. The
>> AC_PROG_CC/CXX feature affects the CC/CXX varia
Btw. Is there already something at make/autoconf that does similar filtering
of unwanted flags ?
The mentioned TOOLCHAIN_POST_DETECTION seems just to reset some variables
like CXX_CFLAGS to old values , not sure if this is what we want here ?
>Hi Erik, I created :
>
>https://bugs.openjdk.
On 1/3/24 13:03, Kim Barrett wrote:
On Jan 3, 2024, at 7:16 AM, Baesken, Matthias wrote:
Btw. I found this rather recent discussion about reverting the forcing
of setting -std=gnu++11 in autoconf :
https://urldefense.com/v3/__https://mail.gnu.org/archive/html/bug-autoconf/2023-12/msg0
>So autoconf forcibly selects a -std= option, possibly overriding either an
>explicit option or the compiler's default. Who thought that was a good idea?
>There are even comments from the time that question that "feature".
>
>It looks like there is code to attempt to deal with that sort of thing
On Thu, 4 Jan 2024 07:15:32 GMT, Martin Buchholz wrote:
> Thanks ... now I see ...
FWIW, @jddarcy thinks we can still improve `Modifier.toString(int)`. See this
comment and its parent thread:
https://github.com/openjdk/jdk/pull/17239#discussion_r1441050656
-
PR Review Comment: ht
