On Fri, 19 Jan 2024 23:50:46 GMT, Sam James wrote:
>> The LFS64 symbols provided by glibc are not part of any standard and were
>> gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5).
>> This commit replaces the usage of LFS64 symbols with their regular
>> counterparts an
On Fri, 19 Jan 2024 23:50:46 GMT, Sam James wrote:
>> The LFS64 symbols provided by glibc are not part of any standard and were
>> gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5).
>> This commit replaces the usage of LFS64 symbols with their regular
>> counterparts an
On Thu, 11 Jan 2024 08:24:42 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less acceptin
> The LFS64 symbols provided by glibc are not part of any standard and were
> gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5).
> This commit replaces the usage of LFS64 symbols with their regular
> counterparts and defines -D_FILE_OFFSET_BITS=64, ensuring that functions
On Fri, 19 Jan 2024 22:47:59 GMT, Jonathan Gibbons wrote:
> Please review an almost trivial change to move the position of an HTML end
> tag to avoid nested use of the tag.
>
> There is no change to the visual presentation, because the macro
> `$(DRAFT_MARKER_STR)` itself uses `` (that was the
Please review an almost trivial change to move the position of an HTML end tag
to avoid nested use of the tag.
There is no change to the visual presentation, because the macro
`$(DRAFT_MARKER_STR)` itself uses `` (that was the cause of the nested
tags).
-
Commit messages:
- JDK-8
On Thu, 18 Jan 2024 16:21:46 GMT, Julian Waters wrote:
>> [JDK-8323008](https://bugs.openjdk.org/browse/JDK-8323008) reports unwanted
>> autoconf flags being added to the command line, and solves the issue by
>> filtering out the added flags by force. This is not optimal however, as
>> doing s
On Fri, 19 Jan 2024 21:17:20 GMT, Erik Joelsson wrote:
> I would just like to point out that it was a change in autoconf behavior
> that triggered this whole ordeal in the first place
I'm not entirely sure that is the case. It might as well have been a latent bug
that was triggered by changes
On Fri, 12 Jan 2024 15:05:46 GMT, Magnus Ihse Bursie wrote:
> In [JDK-8318913](https://bugs.openjdk.org/browse/JDK-8318913), the
> symbolgenerator started to look at current sources as well. This means that
> the gensrc stage needs to be completed before this is run. A dependency was
> added f
On Fri, 19 Jan 2024 09:44:44 GMT, Magnus Ihse Bursie wrote:
>> Somewhat related to this, while investigating another bug and with this PR
>> fresh in memory, I think we are missing another dependency.
>>
>> In `make/modules/jdk.javadoc/Gendata.gmk`, we are copying the generated
>> files into
On Thu, 18 Jan 2024 07:34:31 GMT, Magnus Ihse Bursie wrote:
>> In [JDK-8318913](https://bugs.openjdk.org/browse/JDK-8318913), the
>> symbolgenerator started to look at current sources as well. This means that
>> the gensrc stage needs to be completed before this is run. A dependency was
>> add
On Fri, 19 Jan 2024 14:21:28 GMT, Julian Waters wrote:
> Haha, thanks both. Though one thing has been annoying me ever since I wrote
> this, it's the fact that no "AC_UNDEF" exists to erase macros defined by
> AC_DEFUN. Overwriting macros like this, especially macros that are part of
> the "au
On Fri, 19 Jan 2024 14:14:46 GMT, Magnus Ihse Bursie wrote:
> In contrast with Erik I'm not so worried about future breakage. Autoconf has
> basically stalled in development since decades. If someone were to pick up
> development again (like what happened with GNU Make) we will surely see signs
> Please review a patch to add support for Markdown syntax in documentation
> comments, as described in the associated JEP.
>
> Notable features:
>
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java`
> libra
On Fri, 12 Jan 2024 17:47:06 GMT, Pavel Rappo wrote:
>> Jonathan Gibbons has updated the pull request with a new target base due to
>> a merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains seven additional
>> com
On Mon, 8 Jan 2024 21:26:50 GMT, Jonathan Gibbons wrote:
>> Please review a patch to add support for Markdown syntax in documentation
>> comments, as described in the associated JEP.
>>
>> Notable features:
>>
>> * support for `///` documentation comments in `JavaTokenizer`
>> * new module `jd
> Please review several fixes and improvements to the `this-escape` lint
> warning analyzer.
>
> The goal here is to apply some relatively simple logical fixes that improve
> the precision and accuracy of the analyzer, and capture the remaining
> low-hanging fruit so we can consider the analyze
On Thu, 18 Jan 2024 16:21:46 GMT, Julian Waters wrote:
>> [JDK-8323008](https://bugs.openjdk.org/browse/JDK-8323008) reports unwanted
>> autoconf flags being added to the command line, and solves the issue by
>> filtering out the added flags by force. This is not optimal however, as
>> doing s
On Thu, 18 Jan 2024 16:21:46 GMT, Julian Waters wrote:
>> [JDK-8323008](https://bugs.openjdk.org/browse/JDK-8323008) reports unwanted
>> autoconf flags being added to the command line, and solves the issue by
>> filtering out the added flags by force. This is not optimal however, as
>> doing s
On Thu, 11 Jan 2024 13:23:45 GMT, Julian Waters wrote:
>> Compile the JDK as C++17, enabling the use of all C++17 language features
>
> Julian Waters has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Require clang 13 in toolchain.m4
Well, th
On Fri, 19 Jan 2024 01:22:27 GMT, Julian Waters wrote:
> I found out that the issue of having AC_PROG_CC and AC_PROG_CXX being called
> by AC_REQUIRE can be solved by directly overwriting them in util.m4, rather
> than providing our own UTIL_PROG_CC and so on. Unsure how satisfactory this
> is
On Fri, 19 Jan 2024 10:37:42 GMT, Sam James wrote:
>> The LFS64 symbols provided by glibc are not part of any standard and were
>> gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5).
>> This commit replaces the usage of LFS64 symbols with their regular
>> counterparts an
On Fri, 19 Jan 2024 10:52:40 GMT, Sam James wrote:
>> Sam James has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - sendfile64 -> sendfile
>>
>>Signed-off-by: Sam James
>> - buf64->buf
>>
>>Signed-off-by: Sam James
>
> T
On Thu, 11 Jan 2024 13:23:45 GMT, Julian Waters wrote:
>> Compile the JDK as C++17, enabling the use of all C++17 language features
>
> Julian Waters has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Require clang 13 in toolchain.m4
Should I
On Fri, 19 Jan 2024 10:37:42 GMT, Sam James wrote:
>> The LFS64 symbols provided by glibc are not part of any standard and were
>> gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5).
>> This commit replaces the usage of LFS64 symbols with their regular
>> counterparts an
On Mon, 8 Jan 2024 21:26:50 GMT, Jonathan Gibbons wrote:
>> Please review a patch to add support for Markdown syntax in documentation
>> comments, as described in the associated JEP.
>>
>> Notable features:
>>
>> * support for `///` documentation comments in `JavaTokenizer`
>> * new module `jd
On Fri, 19 Jan 2024 10:30:54 GMT, Kim Barrett wrote:
> Consider (perhaps in a separate PR) forbidding the use of the xxx64
> functions, using FORBID_C_FUNCTION (from compilerWarnings.hpp &etc). I think
> it would be done in globalDefinitions_gcc.hpp, and probably conditional on
> _LARGEFILE64_
On Fri, 19 Jan 2024 10:37:42 GMT, Sam James wrote:
>> The LFS64 symbols provided by glibc are not part of any standard and were
>> gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5).
>> This commit replaces the usage of LFS64 symbols with their regular
>> counterparts an
On Fri, 19 Jan 2024 10:06:33 GMT, Kim Barrett wrote:
>> Sam James has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add message for assert
>>
>> Not all C++ stds implement it w/o.
>
> src/hotspot/os/linux/os_linux.cpp line 4252:
>
>>
> The LFS64 symbols provided by glibc are not part of any standard and were
> gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5).
> This commit replaces the usage of LFS64 symbols with their regular
> counterparts and defines -D_FILE_OFFSET_BITS=64, ensuring that functions
On Fri, 19 Jan 2024 06:47:39 GMT, Sam James wrote:
>> The LFS64 symbols provided by glibc are not part of any standard and were
>> gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5).
>> This commit replaces the usage of LFS64 symbols with their regular
>> counterparts an
On Thu, 18 Jan 2024 23:05:48 GMT, Erik Joelsson wrote:
>> Looking at `make/modules/jdk.javadoc/Gendata.gmk` the recipe never
>> references `$(JDK_OUTPUTDIR)/modules/`, the output dir where the compiled
>> classes are located. It only references the output of `$(call
>> GetModuleSrcPath)` (and
Vote: yes
On Fri, Jan 19, 2024 at 9:09 AM Baesken, Matthias
wrote:
>
> Vote: yes
>
>
>
>
>
> Best regards, Matthias
>
>
>
> >I hereby nominate Christoph Langer (clanger) to Membership in the Build
> >Group.
>
>
>
>
Vote: yes
Best regards, Matthias
>I hereby nominate Christoph Langer (clanger) to Membership in the Build Group.
34 matches
Mail list logo
