On Mon, 24 Jun 2024 14:33:51 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` ev
r.jmodjava.rmi.jmodjava.xml.crypto.jmod
> jdk.editpad.jmod jdk.internal.vm.compiler.jmod
> jdk.jfr.jmod jdk.management.jmodjdk.unsupported.desktop.jmod
> java.desktop.jmod java.scripting.jmod java.xml.jmod
> jdk.hotspot.ag
On Fri, 14 Jun 2024 06:49:34 GMT, Alan Bateman wrote:
> Yes, on my list.
Thanks!
-
PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2167591811
On Thu, 6 Jun 2024 15:35:20 GMT, Severin Gehwolf wrote:
> My aim will be to bring this into JDK 24 with a JEP then. Hopefully we can
> bring this to a successful conclusion that way.
@AlanBateman JEP draft is here:
https://openjdk.org/jeps/8333799
Could you please help review it?
On Thu, 6 Jun 2024 09:47:30 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` ev
On Thu, 6 Jun 2024 10:42:20 GMT, Alan Bateman wrote:
>> Severin Gehwolf has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix default description of keep-packaged-modules
>
> I've read through all src chan
On Thu, 6 Jun 2024 09:33:43 GMT, Magnus Ihse Bursie wrote:
> As Erik says. You need to add something like: `DEFAULT_DESC: [the inverse of
> --enable-runtime-link-image]`.
https://github.com/openjdk/jdk/pull/14787/commits/7a8f839e55c5109deeb5022d2338b37387c95c85
does that. Sorry it clashed
r.jmodjava.rmi.jmodjava.xml.crypto.jmod
> jdk.editpad.jmod jdk.internal.vm.compiler.jmod
> jdk.jfr.jmod jdk.management.jmodjdk.unsupported.desktop.jmod
> java.desktop.jmod java.scripting.jmod java.xml.jmod
> jdk.hotsp
On Tue, 4 Jun 2024 09:04:30 GMT, Magnus Ihse Bursie wrote:
>>> Does that proposal sound good?
>>
>> That table is useful, I think it's right. No change to default behavior. If
>> someone configures with --enable-runtime-image then they get a JDK run-time
>> image that supports jlink (with
r.jmodjava.rmi.jmodjava.xml.crypto.jmod
> jdk.editpad.jmod jdk.internal.vm.compiler.jmod
> jdk.jfr.jmod jdk.management.jmodjdk.unsupported.desktop.jmod
> java.desktop.jmod java.scripting.jmod java.xml.jmod
> jdk.hotsp
On Wed, 5 Jun 2024 13:21:20 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 113 commits:
>>
>> - Mark some tests with requiring packaged modules
>> -
On Wed, 5 Jun 2024 13:46:59 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 113 commits:
>>
>> - Mark some tests with requiring packaged modules
>> -
On Wed, 5 Jun 2024 13:54: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 113 commits:
>>
>> - Mark some tests with requiring packaged modules
>> -
On Wed, 5 Jun 2024 13:52:43 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 113 commits:
>>
>> - Mark some tests with requiring packaged modules
>> -
On Mon, 3 Jun 2024 19:10:22 GMT, Alan Bateman wrote:
> > Does that proposal sound good?
>
> That table is useful, I think it's right. No change to default behavior. If
> someone configures with --enable-runtime-image then they get a JDK run-time
> image that supports jlink (with some
On Sun, 2 Jun 2024 17:41:55 GMT, Alan Bateman wrote:
> (Doing that would of course mean that several existing jlink tests would need
> some changes, either to `@requires` or to remove the checks for the `jmods`
> directory)
I've added a couple of `@requires jlink.packagedModules` (new with
r.jmodjava.rmi.jmodjava.xml.crypto.jmod
> jdk.editpad.jmod jdk.internal.vm.compiler.jmod
> jdk.jfr.jmod jdk.management.jmodjdk.unsupported.desktop.jmod
> java.desktop.jmod java.scripting.jmod java.xml.jmod
> jdk.hotspot.ag
On Mon, 3 Jun 2024 19:10:22 GMT, Alan Bateman wrote:
> I've read through most of the changes now. Overall I think it's looking good,
> just a few terminology and minor points that I'll add as comments.
@AlanBateman I don't see those comments. Should I?
-
PR Comment:
On Tue, 4 Jun 2024 09:04:30 GMT, Magnus Ihse Bursie wrote:
> > Does that proposal sound good?
>
> What you basically is saying is that the default value of `packaged-modules`
> should be `! runtime-link-image` (i.e. the inverse)?
Yes. **default** of the `packaged-modules` value being the key.
On Mon, 3 Jun 2024 12:55:54 GMT, Alan Bateman wrote:
> So I think we may have the wrong default. Yes, they are separate configure
> and jlink options but I'm wondering if it would be more sensible to
> opt-in(not opt-out) to keep the packaged modules when configured with
>
On Sun, 2 Jun 2024 17:41:55 GMT, Alan Bateman wrote:
> I've been looking through the changes. One thing that I'm wondering about is
> whether --generate-runtime-link-image should disable the keeping of packaged
> modules (set JLINK_KEEP_PACKAGED_MODULES to false). It seems surprising to
> use
On Thu, 30 May 2024 19:14:43 GMT, Magnus Ihse Bursie wrote:
> The original way of building static libraries in the JDK was to use the
> configure argument --enable-static-build, which set the value of the make
> variable STATIC_BUILD. (Note that this is not the same as the source code
>
On Thu, 23 May 2024 18:52:53 GMT, Alan Bateman wrote:
> Yes, I want to help you get this one over the line.
Thanks! Appreciate that.
-
PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2133375454
On Thu, 16 May 2024 13:47:20 GMT, Alan Bateman wrote:
>>> If I understand you correctly, this would be no longer a build-time only
>>> approach to produce the "linkable runtime"? It would be some-kind of
>>> jlink-option driven approach (as it would run some code that should only
>>> run when
r.jmodjava.rmi.jmodjava.xml.crypto.jmod
> jdk.editpad.jmod jdk.internal.vm.compiler.jmod
> jdk.jfr.jmod jdk.management.jmodjdk.unsupported.desktop.jmod
> java.desktop.jmod java.scripting.jmod java.xml.jmod
> jdk.hotspot.ag
On Wed, 22 May 2024 12:25:09 GMT, Severin Gehwolf wrote:
>> I did some testing and it turns out that this is indeed not checked. I
>> believe this is a miss in the Skara reimplementation of jcheck. I've opened
>> https://bugs.openjdk.org/browse/SKARA-2265 to track this.
&
On Wed, 22 May 2024 08:07:59 GMT, Magnus Ihse Bursie wrote:
>> Actually, this is a bit strange. I thought jcheck would look for missing
>> newline at EOF, and that properties files were included in the check
>> nowadays. I'll need to check this out.
>
> I did some testing and it turns out that
r.jmodjava.rmi.jmodjava.xml.crypto.jmod
> jdk.editpad.jmod jdk.internal.vm.compiler.jmod
> jdk.jfr.jmod jdk.management.jmodjdk.unsupported.desktop.jmod
> java.desktop.jmod java.scripting.jmod java.xml.jmod
> jdk.hotspot.ag
On Wed, 8 May 2024 22:36:51 GMT, Magnus Ihse Bursie 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 105 commits:
>>
>> - Generate the runtime image link diff at jlink time
r.jmodjava.rmi.jmodjava.xml.crypto.jmod
> jdk.editpad.jmod jdk.internal.vm.compiler.jmod
> jdk.jfr.jmod jdk.management.jmodjdk.unsupported.desktop.jmod
> java.desktop.jmod java.scripting.jmod java.xml.jmod
> jdk.hotsp
On Thu, 4 Apr 2024 20:56:55 GMT, Magnus Ihse Bursie wrote:
>> Severin Gehwolf has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - Use shorter name for the build tool
>> - Review feedback from Erik J.
On Tue, 7 May 2024 16:52:12 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` ev
On Tue, 16 Apr 2024 13:54:53 GMT, Alan Bateman wrote:
>>> > @mlchung @AlanBateman Any thoughts on this latest version? Is this going
>>> > into the direction you had envisioned? Any more blockers? The CSR should
>>> > be up-to-date and is open for review as well. If no more blockers I'll go
r.jmodjava.rmi.jmodjava.xml.crypto.jmod
> jdk.editpad.jmod jdk.internal.vm.compiler.jmod
> jdk.jfr.jmod jdk.management.jmodjdk.unsupported.desktop.jmod
> java.desktop.jmod java.scripting.jmod java.xml.jmod
> jdk.hotspot.ag
On Tue, 16 Apr 2024 13:54:53 GMT, Alan Bateman wrote:
> I think it continues to build time, it's just using some hidden jlink option.
> So yes, it similar to a previous iteration except that it doesn't run as a
> plugin the pipeline and the delta goes to the lib directory.
OK. If a hidden
Hi,
On Tue, 2024-04-16 at 17:40 +0200, Magnus Ihse Bursie wrote:
> On 2024-04-16 10:28, Volker Simonis wrote:
>
> > Hi, and sorry, I'm completely new to this discussion.
> >
> > I just wonder how `static-libs-image` is related to the
> > `graal-builder-image` target which is available in
On Wed, 3 Apr 2024 22:31:39 GMT, Mandy Chung wrote:
>> Severin Gehwolf has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Move CreateLinkableRuntimePlugin to build folder
>>
>> Keep runtim
On Wed, 3 Apr 2024 22:31:39 GMT, Mandy Chung wrote:
>> Severin Gehwolf has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Move CreateLinkableRuntimePlugin to build folder
>>
>> Keep runtim
On Fri, 5 Apr 2024 09:25:49 GMT, Magnus Ihse Bursie wrote:
>> Thanks. Yes, the long name was my doing. Sorry.
>
> Kind of aligning with the "Donaudampfschiffahrtsgesellschaftskapitän"
> prejudice of German. ;-)
>
>
>
> (In Sweden, we have "flaggstångsknoppsförgyllare" so you are not alone)
On Thu, 4 Apr 2024 20:56:02 GMT, Magnus Ihse Bursie wrote:
>> I was not aware of such a convention and I can't say I agree with it. It
>> just seems redundant and unnecessary, but I suppose we should wait for
>> Magnus to respond.
>
> Just to clarify: I did not say the name needed to be long,
r.jmodjava.rmi.jmodjava.xml.crypto.jmod
> jdk.editpad.jmod jdk.internal.vm.compiler.jmod
> jdk.jfr.jmod jdk.management.jmodjdk.unsupported.desktop.jmod
> java.desktop.jmod java.scripting.jmod java.xml.jmod
> jdk.hotspot.
On Thu, 4 Apr 2024 12:56:41 GMT, Erik Joelsson 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 100 commits:
>>
>> - Fix coment
>> - Fix comment
>> - Fix typo
On Thu, 4 Apr 2024 13:00:33 GMT, Erik Joelsson 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 100 commits:
>>
>> - Fix coment
>> - Fix comment
>> - Fix typo
On Thu, 21 Mar 2024 15:29:45 GMT, Severin Gehwolf wrote:
>> make/Images.gmk line 145:
>>
>>> 143: $(eval $(call SetupJavaCompilation, BUILD_JDK_RUNLINK_CLASSES, \
>>> 144: COMPILER := buildjdk, \
>>> 145: DISABLED_WARNINGS := try, \
>>
On Thu, 21 Mar 2024 15:30:01 GMT, Magnus Ihse Bursie wrote:
>> Thanks! This will also likely change. I'm thinking of just generating the
>> diff file and putting it into `lib/` of the JDK image. That avoids needing
>> to call this build-time only jlink plugin and this `FixPath` magic.
>
> I
On Thu, 21 Mar 2024 15:35:06 GMT, Severin Gehwolf wrote:
>> Ok, fine. Will the new solution still include a build-time only tool?
>
> Yes, but I'll likely go with the interim solution and that would only require
> the a single "driver" class in the build tree with a
On Thu, 14 Mar 2024 17:46:19 GMT, Erik Joelsson wrote:
>> Severin Gehwolf has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix comment in autoconf file
>
> make/Images.gmk line 126:
>
r.jmodjava.rmi.jmodjava.xml.crypto.jmod
> jdk.editpad.jmod jdk.internal.vm.compiler.jmod
> jdk.jfr.jmod jdk.management.jmodjdk.unsupported.desktop.jmod
> java.desktop.jmod java.scripting.jmod java.xml.jmod
> jdk.hotspot.ag
On Wed, 3 Apr 2024 22:31:39 GMT, Mandy Chung wrote:
> Thanks for the investigation w.r.t. extending jimage. It does not seem worth
> the effort in pursuing the support of adding resources to an existing jimage
> file. To me, putting the diff data under `lib` directory as a private file is
> a
On Tue, 19 Mar 2024 16:55:14 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` ev
On Thu, 21 Mar 2024 15:28:23 GMT, Magnus Ihse Bursie wrote:
>>> First question, do this class really need to be in a separate module? (I'm
>>> afraid the answer is "yes" but I need to ask it anyway).
>>
>> Yes, because it uses the `Plugin` ServiceLoader extension using the boot
>>
On Thu, 21 Mar 2024 14:54:15 GMT, Magnus Ihse Bursie wrote:
>> Severin Gehwolf has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Move CreateLinkableRuntimePlugin to build folder
>>
>> Keep runtim
On Tue, 19 Mar 2024 18:05:31 GMT, Mandy Chung wrote:
> Thanks for the details. I feel the pain in extending jlink for this work as
> the current jlink implementation is not easily understandable and has been
> yearning for rewrite in my perspective (looking forward to Project Leyden's
>
r.jmodjava.rmi.jmodjava.xml.crypto.jmod
> jdk.editpad.jmod jdk.internal.vm.compiler.jmod
> jdk.jfr.jmod jdk.management.jmodjdk.unsupported.desktop.jmod
> java.desktop.jmod java.scripting.jmod java.xml.jmod
> jdk.hotsp
r.jmodjava.rmi.jmodjava.xml.crypto.jmod
> jdk.editpad.jmod jdk.internal.vm.compiler.jmod
> jdk.jfr.jmod jdk.management.jmodjdk.unsupported.desktop.jmod
> java.desktop.jmod java.scripting.jmod java.xml.jmod
> jdk.hotspot.ag
On Mon, 18 Mar 2024 20:18:09 GMT, Mandy Chung wrote:
> This is what I understand from your implementation:
>
> 1. create a regular JDK image under
> `support/images/runtime-link-initial-jdk` using jlink from the exploded JDK
> build
>
> 2. create a linkable JDK image under
On Mon, 18 Mar 2024 18:08:23 GMT, Mandy Chung wrote:
> > Yes we do. The main reason being that the `jdk` image has more to it than
> > just the image. `src.zip`, CDS data, `demo` and so on. We don't want to
> > duplicate that. To us, including the `jmods` folder is something that comes
> >
On Fri, 15 Mar 2024 18:09:36 GMT, Mandy Chung wrote:
> > Wasn't the intention to make "creating a linkable runtime image" a build
> > only decision and make the relevant infrastructure classes build-only
> > artefacts?
>
> Build-only decision means that the linkable runtime image is only
On Fri, 15 Mar 2024 19:29:49 GMT, Mandy Chung wrote:
> > > If `--enable-runtime-link-image` is enabled, the JDK image does not
> > > include the packaged modules.
> >
> >
> > That's not true. Right now `--enable-runtime-link-image` modifies how the
> > `lib/modules` image looks like (adds a
r.jmodjava.rmi.jmodjava.xml.crypto.jmod
> jdk.editpad.jmod jdk.internal.vm.compiler.jmod
> jdk.jfr.jmod jdk.management.jmodjdk.unsupported.desktop.jmod
> java.desktop.jmod java.scripting.jmod java.xml.jmod
> jdk.hotsp
On Thu, 14 Mar 2024 20:54:32 GMT, Mandy Chung wrote:
> > The updated patch uses a **build-only** `jlink` plugin, still called
> > `--create-linkable-runtime` which is _a)_ added only at build time with
> > `--add-modules` and _b)_ now generates the diff and prepares the image for
> > runtime
On Thu, 14 Mar 2024 21:16:04 GMT, Erik Joelsson wrote:
> About the configure options,
>
> ```
> --enable-keep-packaged-modules
> enable keeping of packaged modules in jdk image
> [enabled]
> --enable-runtime-link-image
> enable producing
r.jmodjava.rmi.jmodjava.xml.crypto.jmod
> jdk.editpad.jmod jdk.internal.vm.compiler.jmod
> jdk.jfr.jmod jdk.management.jmodjdk.unsupported.desktop.jmod
> java.desktop.jmod java.scripting.jmod java.xml.jmod
> jdk.hotsp
On Thu, 14 Mar 2024 14:24:57 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` ev
On Tue, 27 Feb 2024 22:04:47 GMT, Erik Joelsson 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/autoconf/jdk-
On Tue, 12 Mar 2024 14:07:32 GMT, Magnus Ihse Bursie wrote:
>> I don't see a race. The `rm` was there in the original code and is no
>> scarier in the modified version. The jdk image is constructed by a
>> combination of targets and recipes. The first one to run has to be jlink,
>> then we
On Tue, 27 Feb 2024 22:06:12 GMT, Erik Joelsson 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/autoconf/spec.gm
On Fri, 8 Mar 2024 17:25:18 GMT, Severin Gehwolf wrote:
>> make/Images.gmk line 96:
>>
>>> 94:
>>> 95: ifeq ($(JLINK_KEEP_PACKAGED_MODULES), true)
>>> 96: ifeq ($(JLINK_PRODUCE_RUNTIME_LINK_JDK), true)
>>
>> I don't get it. Why don
On Fri, 8 Mar 2024 19:49:19 GMT, Mandy Chung wrote:
>>> > @AlanBateman @mlchung I've now pushed an update of this patch which now
>>> > uses a build-time approach as discussed elsewhere. In order to produce a
>>> > linkable runtime JDK image, one needs to set --enable-runtime-link-image
>>> >
r.jmodjava.rmi.jmodjava.xml.crypto.jmod
> jdk.editpad.jmod jdk.internal.vm.compiler.jmod
> jdk.jfr.jmod jdk.management.jmodjdk.unsupported.desktop.jmod
> java.desktop.jmod java.scripting.jmod java.xml.jmod
> jdk.hotspot.ag
On Mon, 11 Mar 2024 13:24:54 GMT, Erik Joelsson wrote:
> Based on that I agree with the choice of using a configure argument.
Thanks. The intention is that without the extra configure argument you'd get
`jdk-image` as is today. Not modified. *With* `--enable-runtime-link-image` the
result of
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
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 Mess
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 l
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
On Wed, 6 Mar 2024 17:28:01 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/ToolsJdk.gmk line 8
r.jmodjava.rmi.jmodjava.xml.crypto.jmod
> jdk.editpad.jmod jdk.internal.vm.compiler.jmod
> jdk.jfr.jmod jdk.management.jmodjdk.unsupported.desktop.jmod
> java.desktop.jmod java.scripting.jmod java.xml.jmod
> jdk.hotsp
On Mon, 29 Jan 2024 10:39:44 GMT, Aleksey Shipilev wrote:
> This gives me even more confidence in msys2 unpinning :)
Sounds great! As @jaikiran said, we could pin again if it re-surfaces.
-
PR Comment: https://git.openjdk.org/jdk/pull/17572#issuecomment-1914429753
On Fri, 26 Jan 2024 19:33:49 GMT, Aleksey Shipilev wrote:
>> Current GHA runs produce lots of warnings:
>>
>> Node.js 16 actions are deprecated. Please update the following actions to
>> use Node.js 20: actions/cache@v3, actions/download-artifact@v3,
>> actions/upload-artifact@v3. For more
On Mon, 18 Dec 2023 17:06:51 GMT, Frederic Thevenet
wrote:
> [JDK-8320763](https://bugs.openjdk.org/browse/JDK-8320763) fixed the
> consistency of spaces around the assignment operators in spec.gmk.in (as it
> was called then).
> Unfortunately
On Fri, 2023-09-01 at 12:32 +1000, David Holmes wrote:
> Sounds familiar ...
>
> https://bugs.openjdk.org/browse/JDK-8261656 ?
Gives me:
"""
You can't view this issue
"""
:-(
Thanks,
Severin
On Fri, 16 Jun 2023 11:14:10 GMT, Jaikiran Pai wrote:
> If that works, then perhaps we should just use that pinned version of
> `msys2/setup-msys2`, until we report and have this issue fixed in that
> package?
+1
-
PR Comment:
On Tue, 9 May 2023 23:06:23 GMT, Jiangli Zhou wrote:
>> This PR is branched from the makefile changes for
>> https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for
>> handling the JDK/hotspot static libraries:
>>
>> - Introduce new make target(s) for creating image/bundle
On Fri, 5 May 2023 20:43:41 GMT, Erik Joelsson wrote:
> All of that said, I think we can get away with a smaller subset of targets
> and deliverables. AFAIK, graal needs the combined `graal-builder-image` as
> input to their build anyway, so they should not have any dependency on what
> the
On Fri, 5 May 2023 16:52:22 GMT, Jiangli Zhou wrote:
>> This PR is branched from the makefile changes for
>> https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for
>> handling the JDK/hotspot static libraries:
>>
>> - Introduce new make target(s) for creating image/bundle
On Thu, 4 May 2023 09:40:31 GMT, Paul Woegerer wrote:
>> GraalVM native-image has it's own `libjvm.a` shim which would likely
>> conflict or produce undesirable results. So I'd prefer the approach where
>> `static-libs-image` wouldn't produce hotspot `libjvm.a` as part of it. For
>> new
On Wed, 3 May 2023 18:40:52 GMT, Jiangli Zhou wrote:
>> I'm hoping to get input from the graal team on the impact of this change.
>> The exact usage of the new libjvm.a file is still under discussion so I
>> share you concern about changing things for the current static libs usecase
>> before
On Wed, 3 May 2023 02:09:22 GMT, Jiangli Zhou wrote:
> This PR is branched from the makefile changes for
> https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for
> handling the JDK/VM static libraries:
>
> - Create libjvm.a together with other JDK static libraries when
On Wed, 3 May 2023 02:09:22 GMT, Jiangli Zhou wrote:
> This PR is branched from the makefile changes for
> https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for
> handling the JDK/VM static libraries:
>
> - Create libjvm.a together with other JDK static libraries when
On Fri, 24 Mar 2023 15:31:32 GMT, Severin Gehwolf wrote:
> Please review this change for symbol visibility of static library artefacts.
> This fixes an issue when
> OpenJDK is being used as a base for generating native images preventing the
> symbols from being
> exported and
On Mon, 27 Mar 2023 09:40:22 GMT, Severin Gehwolf wrote:
>> Please review this change for symbol visibility of static library artefacts.
>> This fixes an issue when
>> OpenJDK is being used as a base for generating native images preventing the
>> symbols from being
&
On Tue, 28 Mar 2023 04:40:24 GMT, David Holmes wrote:
> I also added this to JBS:
>
> JDK-8239563 was also done to support Graal, and this change is now undoing
> that. Do the Graal folk who want this understand it will restore the problem
> that JDK-8239563 fixed?
I have no insight as to
On Mon, 27 Mar 2023 13:04:28 GMT, Erik Joelsson wrote:
>> Severin Gehwolf has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Explicitly set the JNI_EXPORT define for static libs
>
> Marked as reviewe
On Mon, 27 Mar 2023 08:56:15 GMT, Severin Gehwolf wrote:
>> make/autoconf/flags-cflags.m4 line 639:
>>
>>> 637: STATIC_LIBS_CFLAGS="-DSTATIC_BUILD=1"
>>> 638: if test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TY
visibity is now
> controlled by a
> linker version script downstream. This changes nothing for the regularly
> shipped dynamic libraries.
>
> Thoughts?
Severin Gehwolf has updated the pull request incrementally with one additional
commit since the last revision:
Explicitly set the JNI
On Mon, 27 Mar 2023 05:23:26 GMT, David Holmes wrote:
>> Please review this change for symbol visibility of static library artefacts.
>> This fixes an issue when
>> OpenJDK is being used as a base for generating native images preventing the
>> symbols from being
>> exported and looked up from
Please review this change for symbol visibility of static library artefacts.
This fixes an issue when
OpenJDK is being used as a base for generating native images preventing the
symbols from being
exported and looked up from the executable. Note that symbol visibity is now
controlled by a
On Mon, 20 Feb 2023 14:22:40 GMT, George Adams wrote:
> The Eclipse Adoptium project recently moved its CI from ci.adoptopenjdk.net
> to ci.adoptium.net. The link to jtreg builds needs updating
>
> See https://github.com/adoptium/infrastructure/issues/2932 for more context
Looks fine to me.
98 matches
Mail list logo
