On Fri, 8 Mar 2024 17:19:41 GMT, Severin Gehwolf wrote:
>> I tried out the latest commit (a797ea69).
>>
>> The output "The default module path, '$java.home/jmods' not present. Use
>> --verbose to show the full list of plugin options applied" is bit confusing
>> as it looks like jlink failed
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, 8 Mar 2024 15:48:08 GMT, Magnus Ihse Bursie wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>>
On Wed, 6 Mar 2024 13: 43: 00 GMT, Magnus Ihse Bursie wrote: >> Currently, our symbol visibility handling for tests are sloppy; we only handle it properly on Windows. We need to bring it up to the same levels as
ZjQcmQRYFpfptBannerStart
This Message Is From an
On Fri, 8 Mar 2024 16: 51: 11 GMT, Magnus Ihse Bursie wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> Only show runtime
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
On Fri, 8 Mar 2024 17: 35: 45 GMT, Severin Gehwolf wrote: >> make/Images. gmk line 144: >> >>> 142: OUTPUT_DIR := $(JDK_IMAGE_DIR), \ >>> 143: SUPPORT_DIR := $(JDK_RUN_TIME_IMAGE_SUPPORT_DIR),
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
On Fri, 8 Mar 2024 16:52:33 GMT, Magnus Ihse Bursie wrote:
>> Severin Gehwolf has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Only show runtime image suffix for JDK modules
>
> make/Images.gmk line 96:
>
>> 94:
>> 95: ifeq
On Fri, 8 Dec 2023 15:44:07 GMT, Alan Bateman wrote:
>> Severin Gehwolf has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 46 commits:
>>
>> - Add @enablePreview for JImageValidator that uses classfile API
>> - Fix
On Thu, 29 Feb 2024 13:39:41 GMT, Julian Waters wrote:
>> After we removed mapfiles, we can setup -fvisibility=hidden (and
>> -Wl,--exclude-libs,ALL) in the most basic flags, so this applies to all
>> compilation.
>>
>> This will remove duplicate code and make the underlying assumptions of
After we removed mapfiles, we can setup -fvisibility=hidden (and
-Wl,--exclude-libs,ALL) in the most basic flags, so this applies to all
compilation.
This will remove duplicate code and make the underlying assumptions of the
build clearer.
Doing this will result in the same output result --
On Thu, 29 Feb 2024 12:23:37 GMT, Magnus Ihse Bursie wrote:
> After we removed mapfiles, we can setup -fvisibility=hidden (and
> -Wl,--exclude-libs,ALL) in the most basic flags, so this applies to all
> compilation.
>
> This will remove duplicate code and make the underlying assumptions of
On Thu, 29 Feb 2024 12:23:37 GMT, Magnus Ihse Bursie wrote:
> After we removed mapfiles, we can setup -fvisibility=hidden (and
> -Wl,--exclude-libs,ALL) in the most basic flags, so this applies to all
> compilation.
>
> This will remove duplicate code and make the underlying assumptions of
On Thu, 29 Feb 2024 20:15:23 GMT, Jorn Vernee wrote:
> WRT the change from `EXPORT` to `JNIEXPORT`, is that a required change, or
> stylistic?
>
> From a style perspective, it would be preferable not to use `JNIEXPORT`,
> since these functions are not JNI functions. But also, I think we would
On Fri, 1 Mar 2024 13:51:15 GMT, Magnus Ihse Bursie wrote:
> If you really insist on not including jni.h, I would need to duplicate all
> the platform-specific JNIEXPORT definitions from that file. I can do it (I
> understand your reluctance of risking to bring in unintentional stuff), but
>
On Thu, 29 Feb 2024 12:23:37 GMT, Magnus Ihse Bursie wrote:
> After we removed mapfiles, we can setup -fvisibility=hidden (and
> -Wl,--exclude-libs,ALL) in the most basic flags, so this applies to all
> compilation.
>
> This will remove duplicate code and make the underlying assumptions of
On Wed, 6 Mar 2024 13:43:00 GMT, Magnus Ihse Bursie wrote:
>> Currently, our symbol visibility handling for tests are sloppy; we only
>> handle it properly on Windows. We need to bring it up to the same levels as
>> product code. This is a prerequisite for
>>
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 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, 8 Dec 2023 15:44:07 GMT, Alan Bateman wrote:
>> Severin Gehwolf has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 46 commits:
>>
>> - Add @enablePreview for JImageValidator that uses classfile API
>> - Fix
On Fri, 8 Mar 2024 15:48:08 GMT, Magnus Ihse Bursie wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>>
On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes wrote:
> The HotSpot code has inserted the value of `HOTSPOT_BUILD_USER` into the
> internal version string since before the JDK was open-sourced, so the
> reasoning for this is not in the public history. See
>
On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes wrote:
> The HotSpot code has inserted the value of `HOTSPOT_BUILD_USER` into the
> internal version string since before the JDK was open-sourced, so the
> reasoning for this is not in the public history. See
>
On Fri, 8 Mar 2024 15:48:08 GMT, Magnus Ihse Bursie wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>>
On Fri, 8 Mar 2024 15:41:16 GMT, Magnus Ihse Bursie wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert SEARCH_PATH changes
>
> make/autoconf/toolchain.m4 line 444:
>
>> 442: COMPILER_NAME=$2
>> 443:
> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
> clang by another name, and it uses the clang toolchain in the JDK build. Thus
> the old xlc toolchain is no longer supported, and should be
On Fri, 8 Mar 2024 15:44:48 GMT, Magnus Ihse Bursie wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>>
On Fri, 8 Mar 2024 15:29:58 GMT, Magnus Ihse Bursie wrote:
> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
> clang by another name, and it uses the clang toolchain in the JDK build. Thus
>
On Fri, 8 Mar 2024 15:29:58 GMT, Magnus Ihse Bursie wrote:
> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
> clang by another name, and it uses the clang toolchain in the JDK build. Thus
>
As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building the
JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect clang by
another name, and it uses the clang toolchain in the JDK build. Thus the old
xlc toolchain is no longer supported, and should be removed.
On Fri, 8 Mar 2024 10:17:08 GMT, Magnus Ihse Bursie wrote:
> We should match the building of jspawnhelper in
> make/modules/java.base/Launcher.gmk with the usage for all unix platforms in
> src/java.base/unix/classes/java/lang/ProcessImpl.java.
>
> Granted, the list of OSes in the makefile
On Fri, 8 Mar 2024 13:58:25 GMT, Erik Joelsson wrote:
> Looks good, but why are the tests failing?
**macos-x64 / test (langtools/tier1)** fails when installing homebrew:
Error: Failure while executing; `/usr/bin/env
/usr/local/Homebrew/Library/Homebrew/shims/shared/curl --disable --cookie
On Fri, 8 Mar 2024 10:17:08 GMT, Magnus Ihse Bursie wrote:
> We should match the building of jspawnhelper in
> make/modules/java.base/Launcher.gmk with the usage for all unix platforms in
> src/java.base/unix/classes/java/lang/ProcessImpl.java.
>
> Granted, the list of OSes in the makefile
> This is a patch that:
> a) upgrades the JLine inside the JDK to 3.25.1
> b) since the new version of JLine has a FFM backend, our custom native
> backends are removed, and replaced with the FFM backend
>
> Some changes had to be made to the original JLine in order to fit into the
> JDK. Most
On Thu, 7 Mar 2024 21:53:07 GMT, Jan Lahoda wrote:
>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are
>> automatically granted the native access. I am working on an upgrade of JLine
>> inside the `jdk.internal.le` module, and I would like to replace the current
>>
> This is a patch that:
> a) upgrades the JLine inside the JDK to 3.25.1
> b) since the new version of JLine has a FFM backend, our custom native
> backends are removed, and replaced with the FFM backend
>
> Some changes had to be made to the original JLine in order to fit into the
> JDK. Most
On Mon, 4 Mar 2024 13:52:13 GMT, Jan Lahoda wrote:
> Currently, JDK modules load by the bootstrap and platform ClassLoaders are
> automatically granted the native access. I am working on an upgrade of JLine
> inside the `jdk.internal.le` module, and I would like to replace the current
>
On Fri, 8 Mar 2024 10:17:08 GMT, Magnus Ihse Bursie wrote:
> We should match the building of jspawnhelper in
> make/modules/java.base/Launcher.gmk with the usage for all unix platforms in
> src/java.base/unix/classes/java/lang/ProcessImpl.java.
>
> Granted, the list of OSes in the makefile
On Thu, 7 Mar 2024 19:53:35 GMT, Andrew John Hughes wrote:
>>> Also, it might be worth repeating one of my long-standing wishes: that the
>>> version string should not be hard-coded into the build, but e.g. stored as
>>> a string in the `release` file, and read from there. If we did that, the
On Fri, 8 Mar 2024 10:17:08 GMT, Magnus Ihse Bursie wrote:
> We should match the building of jspawnhelper in
> make/modules/java.base/Launcher.gmk with the usage for all unix platforms in
> src/java.base/unix/classes/java/lang/ProcessImpl.java.
>
> Granted, the list of OSes in the makefile
We should match the building of jspawnhelper in
make/modules/java.base/Launcher.gmk with the usage for all unix platforms in
src/java.base/unix/classes/java/lang/ProcessImpl.java.
Granted, the list of OSes in the makefile amounts to the current list of all
Unix OSes in the JDK, but there is no
On Wed, 6 Mar 2024 13:53:06 GMT, Magnus Ihse Bursie wrote:
> I am currently running tier 4-10
This is now done. A handful of tests failed, but all are due to transient
environmental problems, known errors, or seemingly intermittent product errors
-- none are due to symbol visibility.
So I'd
On Thu, 7 Mar 2024 21:53:07 GMT, Jan Lahoda wrote:
>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are
>> automatically granted the native access. I am working on an upgrade of JLine
>> inside the `jdk.internal.le` module, and I would like to replace the current
>>
On Wed, 6 Mar 2024 21:20:50 GMT, Jan Lahoda wrote:
> This is a patch that:
> a) upgrades the JLine inside the JDK to 3.25.1
> b) since the new version of JLine has a FFM backend, our custom native
> backends are removed, and replaced with the FFM backend
>
> Some changes had to be made to the
43 matches
Mail list logo
