On Wed, 2 Apr 2025 20:38:48 GMT, Magnus Ihse Bursie wrote:
> [JDK-8348998](https://bugs.openjdk.org/browse/JDK-8348998) broke tab
> completion for all init targets, i.e. `print-modules print-targets
> print-configuration print-tests reconfigure pre-compare-build
> post-compare-build`, of which
On Tue, 1 Apr 2025 12:41:48 GMT, David Holmes wrote:
> Revert "8353272: One instance of STATIC_LIB_CFLAGS was missed in JDK-8345683"
>
> This reverts commit cef5610b5d4f7c5c2ceda46995ef3a0d961294e5.
>
> This causes failures building the static libs on Windows and macOS.
>
> Thanks
LGTM. Sorry
On Fri, 4 Apr 2025 15:22:10 GMT, Severin Gehwolf wrote:
>> For JEP 493-enabled builds there are no JMODs. Certain files come from the
>> installed JDK image when a user creates a custom run-time from it. This is
>> problematic for example for files that often come from a different package
>> (
On Tue, 1 Apr 2025 12:07:09 GMT, SendaoYan wrote:
>> Hi all,
>> File src/java.base/share/native/libjli/java.c compile error: control reaches
>> end of non-void function [-Werror=return-type] with gcc options
>> -fsanitize=address -O0. The function int JavaMain(void* _args) in this file
>> will
On Mon, 17 Mar 2025 09:10:50 GMT, Alan Bateman wrote:
> The discussion on jdk-dev was useful but I don't think adding
> --with-import-jvms is the right direction. It's too fragile and loose to
> import from a build created somewhere else.
Why's that? It's more loose than just "importing" a jtr
On Mon, 31 Mar 2025 12:57:38 GMT, Magnus Ihse Bursie wrote:
> While I normally advocate using DISABLE_WARNING in makefiles instead of
> pragmas, in this particular case I wonder if not a pragma in the `LEAVE`
> macro would be better?
PR has been changed to use `#pragma GCC diagnostic ignored "
On Fri, 21 Mar 2025 10:33:10 GMT, Magnus Ihse Bursie wrote:
>> Joachim Kern has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> added needed include
>
> make/StaticLibs.gmk line 117:
>
>> 115: OUTPUT_FILE := $(lib).exp, \
>> 116:
On Thu, 3 Apr 2025 14:48:58 GMT, Hannes Wallnöfer wrote:
> Please review a change to add a `javadoc` option to enable syntax
> highlighting for code fragments in snippets and `` tags. The new
> `--syntax-highlight` option uses the [highlight.js] JavaScript library and
> supports Java, Propert
On Mon, 17 Mar 2025 16:07:09 GMT, Leonid Mesnik wrote:
>> Ioi Lam has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixed windows path problem
>
> Marked as reviewed by lmesnik (Reviewer).
Thanks @lmesnik @erikj79 @vnkozlov for the review
On Sun, 23 Mar 2025 21:14:47 GMT, Doug Simon wrote:
> This PR adds `bin/sort_includes.py`, a python3 script to check that blocks of
> include statements in C++ files are sorted alphabetically and that there's at
> least one blank line between user and sys includes (as per the [style
> guide](h
On Tue, 1 Apr 2025 12:41:48 GMT, David Holmes wrote:
> Revert "8353272: One instance of STATIC_LIB_CFLAGS was missed in JDK-8345683"
>
> This reverts commit cef5610b5d4f7c5c2ceda46995ef3a0d961294e5.
>
> This causes failures building the static libs on Windows and macOS.
>
> Thanks
Thanks for
On Tue, 1 Apr 2025 09:13:45 GMT, Joachim Kern wrote:
> In the JDK launcher, there is a codepath which would set/modify the
> LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can
> also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which
> contains a li
Configure does not properly detect Windows/aarch64 on Cygwin. One complicating
factor here is that no native aarch64 version of Cygwin exists, so it is
running x64 binaries in emulated mode.
-
Commit messages:
- 8353066: Properly detect Windows/aarch64 as build platform
Changes: h
On Wed, 2 Apr 2025 17:57:06 GMT, Magnus Ihse Bursie wrote:
> [JDK-8348905](https://bugs.openjdk.org/browse/JDK-8348905) added the
> possibility to set `JDK_FOR_COMPILE` on the command line to pass the
> `-compilejdk:` argument to jtreg. Unfortunately the way it did this meant
> that -compilejd
On Thu, 20 Mar 2025 22:19:47 GMT, Magnus Ihse Bursie wrote:
>> src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 1104:
>>
>>> 1102: Java_sun_awt_screencast_ScreencastHelper_closeSession(JNIEnv *env,
>>> jclass cls) {
>>> 1103: }
>>> 1104:
>>
>> Suggestion:
>>
>>
>>
>>
When running configure on WSL, the following error message is printed, instead
of proper Linux environment info:
/build/.configure-support/generated-configure.sh: line 13102: -d: command
not found
This is due to us calling `$LSB_RELEASE -d`, but LSB_RELEASE is not yet defined
at that po
On Thu, 3 Apr 2025 09:18:07 GMT, Magnus Ihse Bursie wrote:
> After [JDK-8292944](https://bugs.openjdk.org/browse/JDK-8292944), we only
> generate module-deps.gmk once at the start of Init.gmk. This causes `make
> clean ` to first generate and then remove module-deps.gmk
> after which the rest
On Sat, 29 Mar 2025 17:41:29 GMT, Julian Waters wrote:
>> Build and use SLEEF library as a backend implementation for Vector API
>> trigonometric functions on macosx-aarch64 platform.
>>
>> It improves raw throughput and eliminates GC overhead of non-intrinsified
>> Vector API operation.
>>
>
> Hi all,
> File src/java.base/share/native/libjli/java.c compile error: control reaches
> end of non-void function [-Werror=return-type] with gcc options
> -fsanitize=address -O0. The function int JavaMain(void* _args) in this file
> will execute return ret in LEAVE() macro, but gcc with -O0 is
On Mon, 31 Mar 2025 12:27:23 GMT, Magnus Ihse Bursie wrote:
>> Build and use SLEEF library as a backend implementation for Vector API
>> trigonometric functions on macosx-aarch64 platform.
>>
>> It improves raw throughput and eliminates GC overhead of non-intrinsified
>> Vector API operation.
On Sat, 29 Mar 2025 17:46:43 GMT, Julian Waters wrote:
> Is leaving the sources of sleef in share/native the right thing to do?
No, it should move to the least common directory for all platforms where it is
needed. In this case, it should move to `unix` instead of `share`.
But code that were
We have been sloppy in our use of `printf` in make code. Most of the time, we
should really use `echo` instead. If we do need to use `printf`, we should
never inline make or shell variables into the formatting string, since they may
contain `%` which will be interpreted as formatting. Instead, w
On Thu, 20 Mar 2025 20:59:34 GMT, David Holmes wrote:
>> The file to setup special arguments to native JTReg Hotspot tests is
>> needlessly complicated. With some generalisation, we can make it much
>> simpler.
>
> make/test/JtregNativeHotspot.gmk line 121:
>
>> 119: -I$(VM_TESTBASE_DIR)/n
On Thu, 3 Apr 2025 18:40:05 GMT, Magnus Ihse Bursie wrote:
>> make/autoconf/basic_tools.m4 line 109:
>>
>>> 107: UTIL_LOOKUP_PROGS(WHOAMI, whoami)
>>> 108:
>>> 109: # Tools only needed on some platforms
>>
>> Comment still relevant? Or is it needed on all platforms?
>
> No, so I removed it
On Thu, 3 Apr 2025 13:09:10 GMT, Joachim Kern wrote:
>> In the JDK launcher, there is a codepath which would set/modify the
>> LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can
>> also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which
>> contains
> The target selection configuration flag for Windows AArch64 should be added
> to the build documentation for improved discoverability and completeness.
Saint Wesonga has updated the pull request incrementally with one additional
commit since the last revision:
Clarify that instructions are
Hi all,
File src/java.base/share/native/libjli/java.c compile error: control reaches
end of non-void function [-Werror=return-type] with gcc options
-fsanitize=address -O0. The function int JavaMain(void* _args) in this file
will execute return ret in LEAVE() macro, but gcc with -O0 is not smart
On Thu, 3 Apr 2025 08:04:50 GMT, snake66 wrote:
> The configure script is not able to pick up the giflib installed via system
> packages if it's not located in the system include and lib directories. Since
> giflib does not provide a pkgconfig, arguments to specify the location of the
> includ
On Wed, 2 Apr 2025 23:25:28 GMT, Magnus Ihse Bursie wrote:
> Configure does not properly detect Windows/aarch64 on Cygwin. One
> complicating factor here is that no native aarch64 version of Cygwin exists,
> so it is running x64 binaries in emulated mode.
Marked as reviewed by skateb...@github
On Thu, 3 Apr 2025 07:59:26 GMT, snake66 wrote:
> The autoconf scrips fail to find libjpeg on systems where it's not installed
> in the default system include and library directories. It should check for
> the pkgconfig in these cases.
>
> This work is sponsored by The FreeBSD Foundation
@sna
On Mon, 31 Mar 2025 18:11:27 GMT, Saint Wesonga wrote:
>> The target selection configuration flag for Windows AArch64 should be added
>> to the build documentation for improved discoverability and completeness.
>
> Saint Wesonga has updated the pull request incrementally with one additional
> c
We had a test setup failure in our distributed test system where the process
running jtreg crashed. This caused the hs_err file to end up in the root of the
source tree. Dropping crash files in the source tree is bad practice and makes
it harder to find such files. We should change the current w
On Fri, Apr 04, 2025 at 07:02:48AM +, Erik Joelsson wrote:
> On Thu, 3 Apr 2025 08:04:50 GMT, snake66 wrote:
>
> > The configure script is not able to pick up the giflib installed via system
> > packages if it's not located in the system include and lib directories.
> > Since giflib does not
On Sunday, March 30, 2025 2:58:30 PM China Standard Time Bingwu Zhang wrote:
> I have spent a whole weekend on bisecting, due to the poor performance of
> the loongson3 processors and some recent network issues of the AOSC's build
> servers (where I do the bisect). Current progress is ~16 commits/4
On Fri, 4 Apr 2025 15:22:10 GMT, Severin Gehwolf wrote:
>> For JEP 493-enabled builds there are no JMODs. Certain files come from the
>> installed JDK image when a user creates a custom run-time from it. This is
>> problematic for example for files that often come from a different package
>> (
On Wed, 2 Apr 2025 23:25:28 GMT, Magnus Ihse Bursie wrote:
> Configure does not properly detect Windows/aarch64 on Cygwin. One
> complicating factor here is that no native aarch64 version of Cygwin exists,
> so it is running x64 binaries in emulated mode.
This pull request has now been integra
After [JDK-8292944](https://bugs.openjdk.org/browse/JDK-8292944), we only
generate module-deps.gmk once at the start of Init.gmk. This causes `make clean
` to first generate and then remove module-deps.gmk after
which the rest of the build proceeds without a module-deps.gmk, causing
problems wi
On Fri, 4 Apr 2025 07:55:20 GMT, Alan Bateman wrote:
>>> Part of me is concerned that the hidden option is a bit of an attractive
>>> nuisance. What would you think about just having a fixed list in a
>>> properties file in the repo, thus a resource in the jlink module. This
>>> would avoid th
On Fri, 4 Apr 2025 13:53:57 GMT, Erik Joelsson wrote:
>> I'm not sure I agree. Why would:
>>
>> $$(ECHO) -n '$$($1_OVERVIEW_TEXT)'
>>
>> be better than
>>
>> $$(PRINTF) "%s" '$$($1_OVERVIEW_TEXT)'
>>
>> ?
>>
>> We're kind of squabbling over details here, and it really doesn't matter as
>>
> We have been sloppy in our use of `printf` in make code. Most of the time, we
> should really use `echo` instead. If we do need to use `printf`, we should
> never inline make or shell variables into the formatting string, since they
> may contain `%` which will be interpreted as formatting. In
On Mon, 31 Mar 2025 18:11:27 GMT, Saint Wesonga wrote:
>> The target selection configuration flag for Windows AArch64 should be added
>> to the build documentation for improved discoverability and completeness.
>
> Saint Wesonga has updated the pull request incrementally with one additional
> c
On Thu, 3 Apr 2025 18:12:54 GMT, Jan Lahoda wrote:
>> The `java.io.Console` has several backends: a simple on in `java.base`, a
>> more convenient one in `jdk.internal.le` (with line-reading based on JLine)
>> and one for JShell.
>>
>> The backend based on JLine is proving to be a somewhat pro
> We have been sloppy in our use of `printf` in make code. Most of the time, we
> should really use `echo` instead. If we do need to use `printf`, we should
> never inline make or shell variables into the formatting string, since they
> may contain `%` which will be interpreted as formatting. In
On Tue, 11 Mar 2025 09:12:45 GMT, David Linus Briemann wrote:
>> Add an .editorconfig to define indentation, trim trailing whitespace and
>> open curly brace position for C++ and Java.
>> This allows various editors to easily infer basics of the coding style.
>
> David Linus Briemann has updated
Alternative to https://github.com/openjdk/jdk/pull/23693 for implementing
JDK-8311227.
This `.editorconfig` file is a 1-to-1 conversion of the checks done by jcheck
into .editorconfig format. I believe that is a better way to introduce an
`.editorconfig` file into the existing JDK project.
---
On Wed, 2 Apr 2025 20:38:48 GMT, Magnus Ihse Bursie wrote:
> [JDK-8348998](https://bugs.openjdk.org/browse/JDK-8348998) broke tab
> completion for all init targets, i.e. `print-modules print-targets
> print-configuration print-tests reconfigure pre-compare-build
> post-compare-build`, of which
On Fri, 4 Apr 2025 13:41:17 GMT, Magnus Ihse Bursie wrote:
>> I wasn't aware of that feature in `echo`, but I agree that if we are using
>> printf just to omit the line break, then `echo -n` seems like a better
>> choice.
>
> I'm not sure I agree. Why would:
>
> $$(ECHO) -n '$$($1_OVERVIEW_TEX
On Thu, 3 Apr 2025 09:44:02 GMT, Magnus Ihse Bursie wrote:
> The JDK mainline build when using XCode 16 or 16.1 fails with:
>
>
> * For target
> buildtools_create_symbols_javac__the.COMPILE_CREATE_SYMBOLS_batch:
> Exception in thread "main" java.lang.ClassFormatError: StackMapTable format
> e
On Wed, 2 Apr 2025 20:24:12 GMT, Magnus Ihse Bursie wrote:
> Unfortunately, JDK-8348998 broke the generation of the "test-"
> group of targets.
>
> Or, rather, it breaks the first time you run it in a new configuration. The
> problem is that we need to populate the find-test.gmk cache before c
On Fri, 4 Apr 2025 07:17:16 GMT, Erik Joelsson wrote:
>> `echo -n` ?
>
> I wasn't aware of that feature in `echo`, but I agree that if we are using
> printf just to omit the line break, then `echo -n` seems like a better choice.
I'm not sure I agree. Why would:
$$(ECHO) -n '$$($1_OVERVIEW_TEXT
On Fri, 4 Apr 2025 02:35:07 GMT, David Holmes wrote:
>> We have been sloppy in our use of `printf` in make code. Most of the time,
>> we should really use `echo` instead. If we do need to use `printf`, we
>> should never inline make or shell variables into the formatting string,
>> since they
On Fri, 4 Apr 2025 09:14:12 GMT, christian wrote:
> Have you made it work with WSL2? made the configure work, but the build ran
> into issues.
WSL2 has been more problematic to get to work with the OpenJDK build than WSL1.
Don't be fooled by the "version" numbers, WSL1 is a completely differen
On Thu, 3 Apr 2025 10:04:59 GMT, Magnus Ihse Bursie wrote:
> When running configure on WSL, the following error message is printed,
> instead of proper Linux environment info:
>
>
> /build/.configure-support/generated-configure.sh: line 13102: -d: command
> not found
>
>
> This is due
On Thu, 3 Apr 2025 21:41:21 GMT, Phil Race wrote:
> works for me on Windows 11 aarch64 generated the right configure and the
> build seems to be doing aarch64 things.
same here.
backported it locally to 21u and it works there, too.
thx
Have you made it work with WSL2? made the configure work
Currently, when building with `--with-external-symbols-in-bundles=public`, the
debug symbols bundle contains the stripped pdb files. It should better have the
full pdb files since stripped pdbs are in the runtime image already.
-
Commit messages:
- JDK-8353709
Changes: https://git
On Wed, 2 Apr 2025 23:25:28 GMT, Magnus Ihse Bursie wrote:
> Configure does not properly detect Windows/aarch64 on Cygwin. One
> complicating factor here is that no native aarch64 version of Cygwin exists,
> so it is running x64 binaries in emulated mode.
Marked as reviewed by erikj (Reviewer)
On Tue, 11 Mar 2025 09:12:45 GMT, David Linus Briemann wrote:
>> Add an .editorconfig to define indentation, trim trailing whitespace and
>> open curly brace position for C++ and Java.
>> This allows various editors to easily infer basics of the coding style.
>
> David Linus Briemann has updated
> In the JDK launcher, there is a codepath which would set/modify the
> LD_LIBRARY_PATH. This happens unconditionally on AIX and Linux/musl and can
> also happen on other Linux platforms if an LD_LIBRARY_PATH is pre-set which
> contains a libjvm.so.
>
> The LD_LIBRARY_PATH is set to $JVMPATH:$J
On Fri, 4 Apr 2025 08:55:40 GMT, Christoph Langer wrote:
> > Is the symbols bundle currently containing just the stripped pdbs, or both
> > the full and the stripped pdbs?
>
> Currently the bundle only contains the stripped pdb files.
>
> This is because during preparation of the bundle files
On Fri, 4 Apr 2025 07:48:37 GMT, Christoph Langer wrote:
> Currently, when building with `--with-external-symbols-in-bundles=public`,
> the debug symbols bundle contains the stripped pdb files. It should better
> have the full pdb files since stripped pdbs are in the runtime image already.
Mar
On Thu, 3 Apr 2025 07:59:26 GMT, snake66 wrote:
> The autoconf scrips fail to find libjpeg on systems where it's not installed
> in the default system include and library directories. It should check for
> the pkgconfig in these cases.
>
> This work is sponsored by The FreeBSD Foundation
Mark
On Fri, 4 Apr 2025 08:28:28 GMT, Erik Joelsson wrote:
> Is the symbols bundle currently containing just the stripped pdbs, or both
> the full and the stripped pdbs?
Currently the bundle only contains the stripped pdb files.
This is because during preparation of the bundle files we rename the
On Thu, 3 Apr 2025 10:04:59 GMT, Magnus Ihse Bursie wrote:
> When running configure on WSL, the following error message is printed,
> instead of proper Linux environment info:
>
>
> /build/.configure-support/generated-configure.sh: line 13102: -d: command
> not found
>
>
> This is due
On Fri, Apr 04, 2025 at 06:56:53AM +, Erik Joelsson wrote:
> On Thu, 3 Apr 2025 07:59:26 GMT, snake66 wrote:
>
> > The autoconf scrips fail to find libjpeg on systems where it's not
> > installed in the default system include and library directories. It should
> > check for the pkgconfig in
On Fri, 4 Apr 2025 07:48:37 GMT, Christoph Langer wrote:
> Currently, when building with `--with-external-symbols-in-bundles=public`,
> the debug symbols bundle contains the stripped pdb files. It should better
> have the full pdb files since stripped pdbs are in the runtime image already.
Is
> Alternative approach to #24012
>
> This keeps the current handling of *.pdb vs *.stripped.pdb which allows
> debugging at the cost of a little hack in jlink. Maybe the code in jlink can
> be improved, e.g. make it more conditional.
>
> I'm running this through our testing still to see whether
On Wed, 2 Apr 2025 20:24:12 GMT, Magnus Ihse Bursie wrote:
> Unfortunately, JDK-8348998 broke the generation of the "test-"
> group of targets.
>
> Or, rather, it breaks the first time you run it in a new configuration. The
> problem is that we need to populate the find-test.gmk cache before c
On Fri, 4 Apr 2025 02:23:23 GMT, David Holmes wrote:
>> That would add an extra \n at the end. Maybe it does not matter so much, but
>> I did not want to change anything.
>
> `echo -n` ?
I wasn't aware of that feature in `echo`, but I agree that if we are using
printf just to omit the line bre
On Thu, 3 Apr 2025 08:04:50 GMT, snake66 wrote:
> The configure script is not able to pick up the giflib installed via system
> packages if it's not located in the system include and lib directories. Since
> giflib does not provide a pkgconfig, arguments to specify the location of the
> includ
On Thu, 3 Apr 2025 09:44:02 GMT, Magnus Ihse Bursie wrote:
> The JDK mainline build when using XCode 16 or 16.1 fails with:
>
>
> * For target
> buildtools_create_symbols_javac__the.COMPILE_CREATE_SYMBOLS_batch:
> Exception in thread "main" java.lang.ClassFormatError: StackMapTable format
> e
70 matches
Mail list logo
