> 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:08:21 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
> 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 Sat, 16 Dec 2023 06:38:38 GMT, Sam James wrote:
> My preference for moving forward is:
>
> 1. I add some static_assert for off_t to the modified JVM bits to be safe
> (that's what I tested with);
> 2. We keep this PR for the build-only fixes which are semantically identical
> to the previo
On Tue, 24 Oct 2023 01:36:32 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 and de
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
Well, there's a certain individual that can help out if need be ;)
best regards,
Julian
On Fri, Jan 19, 2024 at 6:46 AM Magnus Ihse Bursie
wrote:
>
> On 2024-01-18 10:44, Julian Waters wrote:
>
> If I understand you correctly, this new hypothetical system would replace
> autoconf as such?
>
> c
Vote: yes
best regards,
Julian
On Thu, 18 Jan 2024 13:54:23 GMT, Erik Joelsson wrote:
>> @lahodaj Just to be absolutely clear: In `jdk.javadoc-gendata`, we're
>> calling two tools: Not only `JavadocElementList` (which only requires
>> source, not class files), but also `CreateSymbols build-javadoc-data`. Can
>> you confirm
On 2024-01-18 10:44, Julian Waters wrote:
If I understand you correctly, this new hypothetical system would
replace autoconf as such?
configure -> autoconf -> compiled configure -> make
to
configure -> compile Java -> Java configure program -> make
Yep, something like that. With a thin shell
Vote: yes
/Magnus
On 2024-01-18 17:46, Baesken, Matthias wrote:
I hereby nominate Christoph Langer (clanger) to Membership in the
Build Group.
Christoph is a long standing member of the JVM team at SAP and a long
time OpenJDK contributor [3].
He is a member of the OpenJDK Members Group a
On Mon, 11 Dec 2023 16:36:09 GMT, Hannes Wallnöfer wrote:
> This is a rather big change to update the structural navigation in API
> documentation generated by JavaDoc. It adds a table of contents for the
> current page to module, package, and class documentation, and replaces the
> old sub-na
Vote: yes
/Erik
On 1/18/24 08:46, Baesken, Matthias wrote:
I hereby nominate Christoph Langer (clanger) to Membership in the
Build Group.
Christoph is a long standing member of the JVM team at SAP and a long
time OpenJDK contributor [3].
He is a member of the OpenJDK Members Group and th
I hereby nominate Christoph Langer (clanger) to Membership in the Build Group.
Christoph is a long standing member of the JVM team at SAP and a long time
OpenJDK contributor [3].
He is a member of the OpenJDK Members Group and the Vulnerability Group, and
Reviewer in a number of projects.
Chris
On Thu, 18 Jan 2024 16:25:49 GMT, Hannes Wallnöfer wrote:
>> This is a rather big change to update the structural navigation in API
>> documentation generated by JavaDoc. It adds a table of contents for the
>> current page to module, package, and class documentation, and replaces the
>> old su
> [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
> so leaves the autoconf message that the flags were added still
> This is a rather big change to update the structural navigation in API
> documentation generated by JavaDoc. It adds a table of contents for the
> current page to module, package, and class documentation, and replaces the
> old sub-navigation bar with a breadcrumb-style links in those pages. T
On Wed, 17 Jan 2024 13:35:23 GMT, Claes Redestad wrote:
> Incrementally building the OpenJDK microbenchmarks emit a "Note: Benchmark
> entries for already exists, overwriting" for each microbenchmark
> class. This is generated by the JMH BenchmarkProcessor annotation processor
> via the javac
On Wed, 17 Jan 2024 13:35:23 GMT, Claes Redestad wrote:
> Incrementally building the OpenJDK microbenchmarks emit a "Note: Benchmark
> entries for already exists, overwriting" for each microbenchmark
> class. This is generated by the JMH BenchmarkProcessor annotation processor
> via the javac
> [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
> so leaves the autoconf message that the flags were added still
> [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
> so leaves the autoconf message that the flags were added still
On Thu, 18 Jan 2024 13:59:30 GMT, Erik Joelsson wrote:
> > What fun, I just found out that omitting the call to AC_PROG_CC and
> > AC_PROG_CXX has no effect, and they're _still_ called magically from
> > somewhere by autoconf even if you don't call them. I'm genuinely at a loss
> > for words :
On Wed, 17 Jan 2024 15:30:36 GMT, Julian Waters wrote:
> What fun, I just found out that omitting the call to AC_PROG_CC and
> AC_PROG_CXX has no effect, and they're _still_ called magically from
> somewhere by autoconf even if you don't call them. I'm genuinely at a loss
> for words :)
If I'
On Thu, 18 Jan 2024 07:25:48 GMT, Magnus Ihse Bursie wrote:
>> Uh, sorry for not being precise. I was talking of the
>> `JavadocElementList`/`jdk.javadoc-gendata` - that does not use classfiles,
>> only sources. `jdk.compiler-gendata`/`ct.sym` generation surely does use
>> (all) the new JDK cl
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
> This is a rather big change to update the structural navigation in API
> documentation generated by JavaDoc. It adds a table of contents for the
> current page to module, package, and class documentation, and replaces the
> old sub-navigation bar with a breadcrumb-style links in those pages. T
On Tue, 16 Jan 2024 19:47:47 GMT, Jonathan Gibbons wrote:
> * Medium-size suggestion/question:
> consider init-ing `HtmlDocletWriter.tableOfContents` directly in the
> constructor for `HtmlDocletWriter` and not in the constructors for the
> subtypes.
I agree it would be nice, but not
On Fri, 12 Jan 2024 14:33:01 GMT, Andrew Leonard wrote:
> For gcc toolchains in ALLOW_ABSOLUTE_PATHS_IN_OUTPUT=False builds, this PR
> finds the location of the gcc system include paths, and adds
> -fdebug-prefix-map flags to map them to a standard location. Thus making the
> debuginfo and res
On Thu, 18 Jan 2024 09:23:24 GMT, Magnus Ihse Bursie wrote:
> > (Sometimes I wonder whether Java could've gone the way V8 went and used
> > Python or Java itself as the build system instead, oh well)
>
> While I think we're stuck with make for the long run, a long-term goal for me
> has been (
On Tue, 16 Jan 2024 19:46:30 GMT, Jonathan Gibbons wrote:
>> Hannes Wallnöfer has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Consolidate TOC functionality into new TableOfContents class
>
> src/jdk.javadoc/share/classes/jdk/javadoc/inte
On Tue, 16 Jan 2024 19:26:21 GMT, Jonathan Gibbons wrote:
>> Hannes Wallnöfer has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Consolidate TOC functionality into new TableOfContents class
>
> src/jdk.javadoc/share/classes/jdk/javadoc/inte
On Thu, 18 Jan 2024 09:12:46 GMT, Julian Waters wrote:
> (Sometimes I wonder whether Java could've gone the way V8 went and used
> Python or Java itself as the build system instead, oh well)
While I think we're stuck with make for the long run, a long-term goal for me
has been (and still is) t
On Thu, 18 Jan 2024 07:37:11 GMT, Magnus Ihse Bursie wrote:
> Then it sounds like this is not a viable approach.
There's definitely gotta be a way to make autoconf do what we want that's out
there, I'll work on it and post any findings back here. I've just found out
that the implicit calls to
On Wed, 17 Jan 2024 13:35:23 GMT, Claes Redestad wrote:
> Incrementally building the OpenJDK microbenchmarks emit a "Note: Benchmark
> entries for already exists, overwriting" for each microbenchmark
> class. This is generated by the JMH BenchmarkProcessor annotation processor
> via the javac
34 matches
Mail list logo
