On Tue, 27 Feb 2024 21:46:17 GMT, Magnus Ihse Bursie wrote:
>> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been
>> integrated, it is possible to do some cleanup. The goal of
>> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change
>> any
On Tue, 27 Feb 2024 21:46:17 GMT, Magnus Ihse Bursie wrote:
>> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been
>> integrated, it is possible to do some cleanup. The goal of
>> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change
>> any
On Sat, 17 Feb 2024 08:28:56 GMT, Kim Barrett wrote:
> Please review this change that updates the minimum supported version of gcc
> to be used for building OpenJDK from 6.0 to 10.0.
>
> This permits enabling C++17 (JDK-8314488), though gcc 9.0 might suffice for
> that. A minimum of gcc 10 also
On Thu, 15 Feb 2024 05:19:45 GMT, Kim Barrett wrote:
> Please review this change that updates the minimum supported version of Clang
> to be used for building OpenJDK from 3.5 to 13.
>
> This permits enabling C++17 (JDK-8314488), though Clang 5 might suffice for
> that. A minimum of Clang 13
On Wed, 14 Feb 2024 22:43:37 GMT, Kim Barrett wrote:
> Please review this change that updates the minimum supported version of IBM
> Open XL C/C++. SAP dropped support for older versions in JDK 22, only
> supporting the version specified in this change.
>
> I need someone from the aix-ppc
On Tue, 27 Feb 2024 13:44:15 GMT, Andrew Leonard wrote:
>> Adds Linux -fdebug-prefix-map'ing for SUPPORT_OUTPUTDIR and
>> HOTSPOT_OUTPUTDIR when absolute paths are not allowed in the binaries, thus
>> making the building of a JDK identically reproducible from different build
>> directories.
>
On Tue, 27 Feb 2024 15:23:09 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Fri, 23 Feb 2024 12:03:37 GMT, Bernhard Urban-Forster
wrote:
>> Instead of discussing removal of windows/aarch64 (although the general rule
>> in OpenJDK is that ports that are not maintained by anyone should be
>> removed); let's stick to the question here: do we need to export `das1()`
On Tue, 27 Feb 2024 16:11:34 GMT, Andrew Dinn wrote:
>> You can probably remove the entire function given it's an indirection to
>> `das` anyway. I remember using it for debugging during the first stages of
>> the Windows-AArch64 port but I've long forgotten about it.
>
> @luhenry @magicus
On Tue, 27 Feb 2024 11:01:03 GMT, Magnus Ihse Bursie wrote:
>> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been
>> integrated, it is possible to do some cleanup. The goal of
>> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change
>> any
> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been
> integrated, it is possible to do some cleanup. The goal of
> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change
> any behavior, even if that behavior seemed odd.
>
> Now let's try to fix
On Tue, 27 Feb 2024 13:56:56 GMT, Ludvig Janiuk wrote:
> I'll note that you still need to run configure to execute make test-only
> JTREG=help. Should this really be necessary?
I agree that it would be convenient, in some rare usecase, to be able to run
this without configure, but the added
On Tue, 27 Feb 2024 13:55:53 GMT, Ludvig Janiuk wrote:
> Clarifying text in `make help` output on how to list variables for e.g.
> JTREG='...'.
Marked as reviewed by erikj (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/18028#pullrequestreview-1904771315
Lorris,
You cannot use new API in java.base in the code for javac, meaning the
java.compiler and jdk.compiler modules. This is an ingherent limitation
of the bootstrap process.
-- Jon
On 2/27/24 1:57 AM, Lorris wrote:
Yes indeed, I am trying to use those changes from the jdk.compiler
On Tue, 27 Feb 2024 11:24:08 GMT, Magnus Ihse Bursie wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Addressing review comments
>
> This looks good from a build perspective. Actually, it looks great! :) I'm
> happy
On Tue, 27 Feb 2024 11:06:15 GMT, Magnus Ihse Bursie wrote:
>> This was actually an important part of this PR, trying to combat the all too
>> general solution we had when trying to combine microsoft and non-microsoft
>> linking. On all Unix-style linkers, the option to mark the output file is
On Tue, 27 Feb 2024 15:35:56 GMT, Ludovic Henry wrote:
>> It does not sound like anyone object to the removal of `JNIEXPORT` for
>> `das1`, then.
>>
>> Or should I just remove the entire function, if it serves no purpose that
>> any current maintainers know or care about?
>
> You can probably
On Tue, 27 Feb 2024 13:44:15 GMT, Andrew Leonard wrote:
>> Adds Linux -fdebug-prefix-map'ing for SUPPORT_OUTPUTDIR and
>> HOTSPOT_OUTPUTDIR when absolute paths are not allowed in the binaries, thus
>> making the building of a JDK identically reproducible from different build
>> directories.
>
On Mon, 26 Feb 2024 20:07:35 GMT, Magnus Ihse Bursie wrote:
>> I use `das` every day. In contrast, I don't know what `das1` is for.
>
> It does not sound like anyone object to the removal of `JNIEXPORT` for
> `das1`, then.
>
> Or should I just remove the entire function, if it serves no
> Please review this patch which adds a jlink mode to the JDK which doesn't
> need the packaged modules being present. A.k.a run-time image based jlink.
> Fundamentally this patch adds an option to use `jlink` even though your JDK
> install might not come with the packaged modules (directory
Clarifying text in `make help` output on how to list variables for e.g.
JTREG='...'.
-
Commit messages:
- 8326831 Clarify test harness control variables in make help
Changes: https://git.openjdk.org/jdk/pull/18028/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=18028=00
On Tue, 27 Feb 2024 13:55:53 GMT, Ludvig Janiuk wrote:
> Clarifying text in `make help` output on how to list variables for e.g.
> JTREG='...'.
I'll note that you still need to run configure to execute `make test-only
JTREG=help`. Should this really be necessary?
Also, while `make test-only
> Adds Linux -fdebug-prefix-map'ing for SUPPORT_OUTPUTDIR and HOTSPOT_OUTPUTDIR
> when absolute paths are not allowed in the binaries, thus making the building
> of a JDK identically reproducible from different build directories.
Andrew Leonard has updated the pull request incrementally with
I don’t have problems with clock skew (or at least I never encountered any
problem with it until today). The problem I was referring to in this statement
is when I modify a class A, to add for example a method to it, and then
reference this new method in another file B, when I build for the
On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie wrote:
>> The idea of setting up general "toolchains" in the native build was good,
>> but it turned out that we really only need a single toolchain, with a single
>> twist: if it should use CC or CPP to link. This is better described by a
On Tue, 27 Feb 2024 11:53:03 GMT, Andrew Leonard wrote:
>> Adds Linux -fdebug-prefix-map'ing for SUPPORT_OUTPUTDIR and
>> HOTSPOT_OUTPUTDIR when absolute paths are not allowed in the binaries, thus
>> making the building of a JDK identically reproducible from different build
>> directories.
>
On Tue, 27 Feb 2024 11:50:35 GMT, Andrew Leonard wrote:
>> Also, this mapping business is getting really convoluted. :-( I did not like
>> it as it was, and this patch makes it even worse. I think we need to rewrite
>> this to create some kind of dict/map, and then iterate over the map and
>>
On Tue, 27 Feb 2024 11:44:31 GMT, Daniel Jeliński wrote:
> FWIW, when I added -lstdc++ before both -static-libstdc++ and replaced LDCXX
> with LD, the code compiled and linked just fine.
Both GCC and G++ call the same linker, and the parameter differences are well
documented. It's only a
> Adds Linux -fdebug-prefix-map'ing for SUPPORT_OUTPUTDIR and HOTSPOT_OUTPUTDIR
> when absolute paths are not allowed in the binaries, thus making the building
> of a JDK identically reproducible from different build directories.
Andrew Leonard has updated the pull request incrementally with
On Tue, 27 Feb 2024 10:35:20 GMT, Magnus Ihse Bursie wrote:
>> It seems correct to include the output dir in the remapping, but I have two
>> objections/questions to the way you are doing it.
>> 1) Why not just use OUTPUTDIR instead of the two specialized subdirs? That
>> is simpler, more
On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie wrote:
>> The idea of setting up general "toolchains" in the native build was good,
>> but it turned out that we really only need a single toolchain, with a single
>> twist: if it should use CC or CPP to link. This is better described by a
On Tue, 27 Feb 2024 11:09:26 GMT, Magnus Ihse Bursie wrote:
> > can we get rid of LDCXX?
>
> Yeah, that is something I plan to look into. Linking C++ object files with
> gcc will fail; and it might be that linking pure C with g++ might be
> problematic. If this is the case, I hope we can at
On Tue, 27 Feb 2024 08:14:56 GMT, Julian Waters wrote:
> can we get rid of LDCXX?
Yeah, that is something I plan to look into. Linking C++ object files with gcc
will fail; and it might be that linking pure C with g++ might be problematic.
If this is the case, I hope we can at least determine
> The idea of setting up general "toolchains" in the native build was good, but
> it turned out that we really only need a single toolchain, with a single
> twist: if it should use CC or CPP to link. This is better described by a
> specific argument to SetupNativeCompilation, LANG := C++ or
On Tue, 27 Feb 2024 00:24:08 GMT, Naoto Sato wrote:
>> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The
>> `COMPAT` locale data was introduced for applications' migratory purposes
>> transitioning to `CLDR`. It is becoming a technical debt and now is the time
>> to
On Tue, 27 Feb 2024 08:29:44 GMT, Julian Waters wrote:
> All those new parameters to SetupNativeCompilation, were they always there
> and the comments about them were just missing from the documentation about
> the function?
Yep. The toolchain definition was a way to "package" multiple
On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie wrote:
> The idea of setting up general "toolchains" in the native build was good, but
> it turned out that we really only need a single toolchain, with a single
> twist: if it should use CC or CPP to link. This is better described by a
>
On Tue, 27 Feb 2024 11:04:49 GMT, Magnus Ihse Bursie wrote:
>> I tend to agree, this should not have been changed to specifying -o
>> directly. We generally keep options inside Makefile variables rather than
>> directly passing them like this, much like how $(OBJ_SUFFIX) was recently
>> used
On Tue, 27 Feb 2024 05:20:11 GMT, Julian Waters wrote:
>> make/common/native/Link.gmk line 131:
>>
>>> 129:$(if $$($1_LINK_OBJS_RELATIVE), $$(CD) $$(OUTPUTDIR) ; ) \
>>> 130: $$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING)
>>> $$($1_SYSROOT_LDFLAGS) \
>>> 131:
On Tue, 27 Feb 2024 10:59:54 GMT, Andrew Leonard wrote:
>> Also, this mapping business is getting really convoluted. :-( I did not like
>> it as it was, and this patch makes it even worse. I think we need to rewrite
>> this to create some kind of dict/map, and then iterate over the map and
>>
On Tue, 27 Feb 2024 10:35:20 GMT, Magnus Ihse Bursie wrote:
>> It seems correct to include the output dir in the remapping, but I have two
>> objections/questions to the way you are doing it.
>> 1) Why not just use OUTPUTDIR instead of the two specialized subdirs? That
>> is simpler, more
> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been
> integrated, it is possible to do some cleanup. The goal of
> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change
> any behavior, even if that behavior seemed odd.
>
> Now let's try to fix
On Fri, 23 Feb 2024 12:42:08 GMT, Magnus Ihse Bursie wrote:
> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) is done, we
> have no need for mapfiles anymore in the JDK project. The mapfile handling
> was inherited from the old build system and is just messy. We should remove
> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) is done, we
> have no need for mapfiles anymore in the JDK project. The mapfile handling
> was inherited from the old build system and is just messy. We should remove
> it to make the linking process more clear.
>
> Note that
On Tue, 27 Feb 2024 10:32:24 GMT, Magnus Ihse Bursie wrote:
>>> Oh you are right, we should always add the OUTPUTDIR to both maps
>>> regardless of if it's internal to the WORKSPACE_ROOT or not. Paths relative
>>> to the OUTPUTDIR should be stable across builds in different output
>>>
On Tue, 27 Feb 2024 08:19:11 GMT, Andrew Leonard wrote:
>>> I have not thought this fully through, but just throwing out a question:
>>> would this work even if one build directory were inside the workspace root,
>>> and the other not?
>>
>> Yes, I have tested that scenario as well, and does
> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) is done, we
> have no need for mapfiles anymore in the JDK project. The mapfile handling
> was inherited from the old build system and is just messy. We should remove
> it to make the linking process more clear.
>
> Note that
On Wed, 21 Feb 2024 23:32:15 GMT, Magnus Ihse Bursie wrote:
> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
> compiler options and `JNIEXPORT` on all platforms.
>
> The bug that this PR solves,
> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was
Yes indeed, I am trying to use those changes from the jdk.compiler module. How
can I make this work without causing problem when building the interim module ?
Lorris
> On 26 Feb 2024, at 14:59, erik.joels...@oracle.com wrote:
>
> Hello Lorris,
>
> This is not expected behavior. Building
On Mon, 26 Feb 2024 20:21:55 GMT, Magnus Ihse Bursie wrote:
>> The idea of setting up general "toolchains" in the native build was good,
>> but it turned out that we really only need a single toolchain, with a single
>> twist: if it should use CC or CPP to link. This is better described by a
On Tue, 27 Feb 2024 08:13:07 GMT, Andrew Leonard wrote:
>> Oh you are right, we should always add the OUTPUTDIR to both maps regardless
>> of if it's internal to the WORKSPACE_ROOT or not. Paths relative to the
>> OUTPUTDIR should be stable across builds in different output directories,
>>
On Tue, 27 Feb 2024 08:07:38 GMT, Daniel Jeliński wrote:
> can we get rid of LDCXX? On my system LDCXX is mapped to `g++` and LD is
> `gcc`; I searched for the differences, and the only thing I could find is
> that `g++` implicitly adds `-lstdc++ -shared-libgcc`; I suppose we could
>
On Mon, 26 Feb 2024 22:05:34 GMT, Erik Joelsson wrote:
>> I have not thought this fully through, but just throwing out a question:
>> would this work even if one build directory were inside the workspace root,
>> and the other not?
>
> Oh you are right, we should always add the OUTPUTDIR to
On Mon, 26 Feb 2024 20:21:55 GMT, Magnus Ihse Bursie wrote:
>> The idea of setting up general "toolchains" in the native build was good,
>> but it turned out that we really only need a single toolchain, with a single
>> twist: if it should use CC or CPP to link. This is better described by a
54 matches
Mail list logo
