On Thu, 5 Sep 2024 09:57:15 GMT, Magnus Ihse Bursie wrote:
>> make/modules/java.desktop/lib/AwtLibraries.gmk line 176:
>>
>>> 174:
>>> 175: ifneq ($(ENABLE_HEADLESS_ONLY), true)
>>> 176: # We cannot link with both awt_headless and awt_xawt at the same
>>> time
>>
>> Just a note on that.
On Thu, 5 Sep 2024 10:03:19 GMT, Magnus Ihse Bursie wrote:
>> make/StaticLibs.gmk line 118:
>>
>>> 116: OPTIMIZATION := HIGH, \
>>> 117: STATIC_LAUNCHER := true, \
>>> 118: LDFLAGS := $(JAVASTATIC_LINK_LDFLAGS), \
>>
>> I could be missing something, but I don't see where is
>> $JAV
On Thu, 5 Sep 2024 05:06:55 GMT, Julian Waters wrote:
>> make/StaticLibs.gmk line 71:
>>
>>> 69: # libsspi_bridge has name conflicts with sunmscapi
>>> 70: BROKEN_STATIC_LIBS += sspi_bridge
>>> 71: # These libs define DllMain which conflict with Hotspot
>>
>> I'm not aware of the DllMain
On Thu, 5 Sep 2024 09:50:49 GMT, Magnus Ihse Bursie wrote:
> Well, but your proof-of-concept only supports clang on linux, where you have
> enabled symbol hiding.
The hermetic-java-runtime branch doesn't have general symbol hiding enabled.
That's why I'm wondering what the issues are with thes
On Tue, 3 Sep 2024 12:51:13 GMT, Magnus Ihse Bursie wrote:
> @jianglizhou Can you please check if there are any other contributors that
> should be acknowledged?
Thanks for asking! I checked all the related changes in
https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch. Followi
On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie wrote:
> As a prerequisite for Hermetic Java, we need a statically linked `java`
> launcher. It should behave like the normal, dynamically linked `java`
> launcher, except that all JDK native libraries should be statically, not
> dynamically,
On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie wrote:
> As a prerequisite for Hermetic Java, we need a statically linked `java`
> launcher. It should behave like the normal, dynamically linked `java`
> launcher, except that all JDK native libraries should be statically, not
> dynamically,
On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie wrote:
> As a prerequisite for Hermetic Java, we need a statically linked `java`
> launcher. It should behave like the normal, dynamically linked `java`
> launcher, except that all JDK native libraries should be statically, not
> dynamically,
On Thu, 29 Aug 2024 08:26:16 GMT, Magnus Ihse Bursie wrote:
> Okay. Unless I misunderstand something, there were no additional authors to
> be credited for these two commits.
That's correct for these.
-
PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2317982354
On Tue, 27 Aug 2024 23:15:03 GMT, Jiangli Zhou wrote:
>> And the discussion whether the checks are made "dynamically" or "statically"
>> is too simplified to be really helpful.
>>
>> Currently, we compile two sets of all object files, with slight
On Sat, 20 Jul 2024 00:20:19 GMT, Jiangli Zhou wrote:
> Please review this PR that strips the `.llvm_addrsig` section from JDK and
> hotspot `.a` static libraries when building with clang. Please see
> https://bugs.openjdk.org/browse/JDK-8336849 description for details.
This pull re
On Wed, 7 Aug 2024 15:07:51 GMT, Magnus Ihse Bursie wrote:
> Are you saying that even using strip can cause lld malfunction?
Based on the referenced discussion thread, that seems to be the case. I haven't
tested with strip for this issue.
> Is there any chance we risk running into problems th
On Wed, 7 Aug 2024 15:12:30 GMT, Magnus Ihse Bursie wrote:
>> Jiangli Zhou has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> - Incorporate comment suggestion from @magicus. Also applied some
>> additional m
> Please review this PR that strips the `.llvm_addrsig` section from JDK and
> hotspot `.a` static libraries when building with clang. Please see
> https://bugs.openjdk.org/browse/JDK-8336849 description for details.
Jiangli Zhou has updated the pull request incrementally with one a
On Tue, 6 Aug 2024 18:58:42 GMT, Magnus Ihse Bursie wrote:
> > No, it's not when building libjvm.a. It's when linking the final elf
> > executable using libjvm.a (or libnet.a, etc) that's created with ld -r or
> > objcopy. During the final elf executable linking time, user could include
> > ad
On Tue, 6 Aug 2024 13:26:00 GMT, Magnus Ihse Bursie wrote:
> But why and how do you specify `-Wl,--icf=safe` when building libjvm.a? That
> is not part of the linker flags in the JDK build mainline. I have not
> encountered these problems when trying to link with lld.
No, it's not when **build
On Sat, 20 Jul 2024 00:20:19 GMT, Jiangli Zhou wrote:
> Please review this PR that strips the `.llvm_addrsig` section from JDK and
> hotspot `.a` static libraries when building with clang. Please see
> https://bugs.openjdk.org/browse/JDK-8336849 description for details.
Thanks fo
On Sat, 20 Jul 2024 00:20:19 GMT, Jiangli Zhou wrote:
> Please review this PR that strips the `.llvm_addrsig` section from JDK and
> hotspot `.a` static libraries when building with clang. Please see
> https://bugs.openjdk.org/browse/JDK-8336849 description for details.
Could som
On Mon, 22 Jul 2024 12:15:59 GMT, Julian Waters wrote:
> This seems odd, since I recall Magnus forcing the JDK to use lld when clang
> is the compiler, so ld being invoked seems strange to me. Does this still
> happen with lld?
The issue occurs with clang linker `lld` during linking executable
Please review this PR that strips the `.llvm_addrsig` section from JDK and
hotspot `.a` static libraries when building with clang. Please see
https://bugs.openjdk.org/browse/JDK-8336849 description for details.
-
Commit messages:
- 8336849: Remove .llvm_addrsig section from JDK/VM
On Wed, 19 Jun 2024 15:15:43 GMT, Magnus Ihse Bursie wrote:
>> This patch contains a set of changes to improve static builds. They will
>> pave the way for implementing a full static-only java launcher. The changes
>> here will:
>>
>> 1) Make sure non-exported symbols are made local in the sta
On Wed, 19 Jun 2024 15:15:43 GMT, Magnus Ihse Bursie wrote:
>> This patch contains a set of changes to improve static builds. They will
>> pave the way for implementing a full static-only java launcher. The changes
>> here will:
>>
>> 1) Make sure non-exported symbols are made local in the sta
On Wed, 19 Jun 2024 15:15:43 GMT, Magnus Ihse Bursie wrote:
>> This patch contains a set of changes to improve static builds. They will
>> pave the way for implementing a full static-only java launcher. The changes
>> here will:
>>
>> 1) Make sure non-exported symbols are made local in the sta
On Wed, 19 Jun 2024 15:15:43 GMT, Magnus Ihse Bursie wrote:
>> This patch contains a set of changes to improve static builds. They will
>> pave the way for implementing a full static-only java launcher. The changes
>> here will:
>>
>> 1) Make sure non-exported symbols are made local in the sta
On Wed, 19 Jun 2024 15:15:43 GMT, Magnus Ihse Bursie wrote:
>> This patch contains a set of changes to improve static builds. They will
>> pave the way for implementing a full static-only java launcher. The changes
>> here will:
>>
>> 1) Make sure non-exported symbols are made local in the sta
On Wed, 19 Jun 2024 15:15:43 GMT, Magnus Ihse Bursie wrote:
>> This patch contains a set of changes to improve static builds. They will
>> pave the way for implementing a full static-only java launcher. The changes
>> here will:
>>
>> 1) Make sure non-exported symbols are made local in the sta
On Wed, 19 Jun 2024 15:15:43 GMT, Magnus Ihse Bursie wrote:
>> This patch contains a set of changes to improve static builds. They will
>> pave the way for implementing a full static-only java launcher. The changes
>> here will:
>>
>> 1) Make sure non-exported symbols are made local in the sta
On Wed, 19 Jun 2024 15:15:43 GMT, Magnus Ihse Bursie wrote:
>> This patch contains a set of changes to improve static builds. They will
>> pave the way for implementing a full static-only java launcher. The changes
>> here will:
>>
>> 1) Make sure non-exported symbols are made local in the sta
On Wed, 19 Jun 2024 15:15:43 GMT, Magnus Ihse Bursie wrote:
>> This patch contains a set of changes to improve static builds. They will
>> pave the way for implementing a full static-only java launcher. The changes
>> here will:
>>
>> 1) Make sure non-exported symbols are made local in the sta
On Tue, 18 Jun 2024 17:57:29 GMT, Magnus Ihse Bursie wrote:
>> Magnus Ihse Bursie has updated the pull request with a new target base due
>> to a merge or a rebase. The incremental webrev excludes the unrelated
>> changes brought in by the merge/rebase. The pull request contains seven
>> addit
On Wed, 29 May 2024 15:10:58 GMT, Jiangli Zhou wrote:
>> When compiling with clang on linux, clang can decide to pick up the bfd
>> linker instead of lld, the LLVM linker. This will invalidate assumptions
>> about command lines that are passed on to the linker. We should us
On Wed, 29 May 2024 15:01:27 GMT, Magnus Ihse Bursie wrote:
> When compiling with clang on linux, clang can decide to pick up the bfd
> linker instead of lld, the LLVM linker. This will invalidate assumptions
> about command lines that are passed on to the linker. We should use
> -fuse-ld=lld
On Tue, May 28, 2024 at 9:09 AM Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:
> On 2024-05-07 06:04, Jiangli Zhou wrote:
>
> I did think I correctly changed every dynamic check that you had added
> to a compile-time check, so it bewilders me somewhat when you say
revert the #ifdef changes.
Best,
Jiangli
On Mon, May 20, 2024 at 10:17 PM Jiangli Zhou
wrote:
> On Tue, May 7, 2024 at 5:26 AM Magnus Ihse Bursie <
> magnus.ihse.bur...@oracle.com> wrote:
>
>> On 2024-05-07 06:04, Jiangli Zhou wrote:
>>
>> On Tue, Apr 30, 2024 at 5:4
On Tue, May 7, 2024 at 5:26 AM Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:
> On 2024-05-07 06:04, Jiangli Zhou wrote:
>
> On Tue, Apr 30, 2024 at 5:42 AM Magnus Ihse
> Bursie wrote:
>
> I am not sure why clang insisted on picking up ld and not lld. I rem
On Tue, Apr 30, 2024 at 5:42 AM Magnus Ihse Bursie
wrote:
>
>
> On 2024-04-26 03:15, Jiangli Zhou wrote:
> > On Thu, Apr 25, 2024 at 9:28 AM Magnus Ihse Bursie
> > wrote:
> >>
> >> Just to be more clear, that's with using `objcopy` to localize
On Thu, Apr 25, 2024 at 9:28 AM Magnus Ihse Bursie
wrote:
>
>
> Just to be more clear, that's with using `objcopy` to localize non-exported
> symbols for all JDK static libraries and libjvm.a, not just libjvm.a right?
>
> Yes.
>
>
> Can you please include the compiler or linker errors on linux/cl
Magnus, thanks for the update! Looks like you've made some good progress.
Please see my comments below.
On Tue, Apr 23, 2024 at 3:42 AM Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:
> I will not be able to participate in the meeting today.
>
> Let me report a bit on my work this week
On Tue, Apr 16, 2024 at 12:39 PM Jiangli Zhou wrote:
>
> Magnus, thanks for the meeting summary! Please see clarifications
> below, to avoid any confusion.
>
> On Tue, Apr 16, 2024 at 11:27 AM Magnus Ihse Bursie
> wrote:
> >
> > This is my summary of wh
On Tue, Apr 16, 2024 at 9:20 AM Jiangli Zhou wrote:
>
> On Tue, Apr 16, 2024 at 8:30 AM Magnus Ihse Bursie
> wrote:
> >
> > Jiangli,
> >
> > First of all: I tried building the leyden branch "hermetic-java-runtime"
> > but failed. :-( I tried
Magnus, thanks for the meeting summary! Please see clarifications
below, to avoid any confusion.
On Tue, Apr 16, 2024 at 11:27 AM Magnus Ihse Bursie
wrote:
>
> This is my summary of what was said in today's meeting:
>
> * Jiangli reported that her team had done extensive testing and not seen
> an
st place. I'll look for a better place.
Let's discuss more on the rest of the topics below during our meeting
today. We can update on the mailing list about the discussion, if
others are interested.
Best,
Jiangli
>
> I would very much like to test it out myself to check this static
Magnus, thanks for the response. Please see comments inlined below.
On Fri, Apr 12, 2024 at 4:52 AM Magnus Ihse Bursie
wrote:
>
> On 2024-04-02 21:16, Jiangli Zhou wrote:
>
> Hi Magnus,
>
> In today's zoom meeting with Alan, Ron, Liam and Chuck, we (briefly)
> dis
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 Mon, 26 Feb 2024 11:03:19 GMT, Magnus Ihse Bursie wrote:
>> There is not much overlap on how linking is done on Windows on one hand, and
>> on all Unix platforms on the other. This makes Link.gmk basically consists
>> of two parts, each in it own half of if statements, and the few common par
Hi Magnus,
For hotspot symbols that need to be exported, when statically linking
the launcher executable using libjvm.a, we use lld's
`-Wl,--export-dynamic-symbol-list=` option. Those exported symbols can
be used outside the VM code, e.g. in agent. Our friend(s) in c++
compiler/toolchain added the
On Wed, Feb 14, 2024 at 5:07 PM Jiangli Zhou wrote:
>
> Hi Magnus,
>
> Thanks for looking into this from the build perspective.
>
> On Wed, Feb 14, 2024 at 1:00 AM Magnus Ihse Bursie
> wrote:
> >
> > First some background for build-dev: I have spent s
Hi Magnus,
Thanks for looking into this from the build perspective.
On Wed, Feb 14, 2024 at 1:00 AM Magnus Ihse Bursie
wrote:
>
> First some background for build-dev: I have spent some time looking at
> the build implications of the Hermetic Java effort, which is part of
> Project Leyden. A high
On Wed, 17 Jan 2024 00:14:58 GMT, Jiangli Zhou wrote:
> Please review this PR with a simple solution for resolving duplicate `Thread`
> symbol issue. In https://github.com/openjdk/jdk/pull/14808 comments, there
> was an alternative suggestion to redefine the symbol at build time
On Wed, 23 Aug 2023 21:13:07 GMT, Erik Joelsson wrote:
> [JDK-8307858](https://bugs.openjdk.org/browse/JDK-8307858) added libjvm.a to
> the set of static-libs in the static-libs image and subsequently the
> static-libs bundle. The main user of the existing static-image was the graal
> build, w
On Wed, 21 Jun 2023 17:09:58 GMT, Kevin Rushforth wrote:
> Since this Enhancement was rejected for JDK 21, this PR should be closed.
Closing without integration accordingly, thanks.
-
PR Comment: https://git.openjdk.org/jdk21/pull/26#issuecomment-1601273074
On Fri, 16 Jun 2023 20:36:07 GMT, Jiangli Zhou wrote:
> 8307858: [REDO] JDK-8307194 Add make target for optionally building a
> complete set of all JDK and hotspot libjvm static libraries
This pull request has been closed without being integrated.
-
PR: https://git.openj
On Fri, 28 Apr 2023 01:03:28 GMT, Jiangli Zhou wrote:
> Initial implementation for supporting building a fully statically linked
> (with a desired set of JDK native libraries and libjvm) Java launcher
> executable, which is named as 'javastatic'.
>
> In this PR, the
On Tue, 20 Jun 2023 17:25:16 GMT, Erik Joelsson wrote:
> The changes look ok.
Thanks. I'll wait for approval on https://bugs.openjdk.org/browse/JDK-8307858
as well.
-
PR Comment: https://git.openjdk.org/jdk21/pull/26#issuecomment-1599256118
On Tue, 20 Jun 2023 17:24:03 GMT, Erik Joelsson wrote:
> > @erikj - You did a round of Mach5 testing on the JDK22 version of this fix.
> > Do you have plans to redo that testing for the JDK21 backport?
>
> I have done testing of the JDK 21 version of the patch and it's running
> cleanly.
Than
On Fri, 16 Jun 2023 22:08:19 GMT, Daniel D. Daugherty
wrote:
> GHA is failing on windows; is this related to this PR or something else?
The windows build failures occur with other PRs as well, e.g.
https://github.com/openjdk/jdk21/pull/24/checks?check_run_id=14317258603. They
should be unrela
On Fri, 16 Jun 2023 20:52:13 GMT, Kevin Rushforth wrote:
> As a P4 enhancement, this doesn't meet the criteria for integration into JDK
> 21 during [Rampdown Phase
> 1](https://mail.openjdk.org/pipermail/jdk-dev/2023-June/007911.html). You
> could request late approval to get this enhancement
8307858: [REDO] JDK-8307194 Add make target for optionally building a complete
set of all JDK and hotspot libjvm static libraries
-
Commit messages:
- Backport 45414fc2dfa41cbbfc6de7fec15eb47f41cf8986
Changes: https://git.openjdk.org/jdk21/pull/26/files
Webrev: https://webrevs.ope
On Fri, 19 May 2023 20:18:53 GMT, Jiangli Zhou wrote:
> Original description for JDK-8307194 change:
> -
> 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 s
ich caused failures on
> macosx- builds. On darwin (https://www.unix.com/man-page/osx/1/ar/),
> `ar` does not support @argument_file. The updated change avoids using
> @argument_file for `ar`.
>
> The partial linking change is done in make/common/NativeCompilation.gmk. The
> flag r
ich caused failures on
> macosx- builds. On darwin (https://www.unix.com/man-page/osx/1/ar/),
> `ar` does not support @argument_file. The updated change avoids using
> @argument_file for `ar`.
>
> The partial linking change is done in make/common/NativeCompilation.gmk. The
> flag r
On Fri, 9 Jun 2023 20:03:23 GMT, Erik Joelsson wrote:
> All our builds succeeded, so this is looking pretty good now. Just a minor
> suggestion left.
Thanks a lot!
> This combination of conditions is repeated 3 times. Maybe we could assign the
> result to a variable (e.g. `$1_ENABLE_PARTIAL_L
On Fri, 2 Jun 2023 14:04:23 GMT, Erik Joelsson wrote:
> > Sounds good for solving the macosx `ar` limitation differently. I'll change
> > that. We can also exclude the partial linking part for gcc (due the older
> > tool issue that you've found). Any concerns with including partial linking
> >
ich caused failures on
> macosx- builds. On darwin (https://www.unix.com/man-page/osx/1/ar/),
> `ar` does not support @argument_file. The updated change avoids using
> @argument_file for `ar`.
>
> The partial linking change is done in make/common/NativeCompilation.gmk. The
> flag r
ich caused failures on
> macosx- builds. On darwin (https://www.unix.com/man-page/osx/1/ar/),
> `ar` does not support @argument_file. The updated change avoids using
> @argument_file for `ar`.
>
> The partial linking change is done in make/common/NativeCompilation.gmk. The
> flag r
On Fri, 19 May 2023 21:20:19 GMT, Erik Joelsson wrote:
>> Jiangli Zhou has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update make/common/NativeCompilation.gmk
>>
>> Thanks you!
>>
&g
On Thu, 1 Jun 2023 16:18:24 GMT, Erik Joelsson wrote:
> > > Another possibility might be the user provided `BUILD_LDCXX` includes
> > > extra options in the testing build (?). If that's the case, we probably
> > > could define a separate `BUILD_LD_PARTIAL` with no added options. In our
> > > p
On Wed, 24 May 2023 21:02:00 GMT, Jiangli Zhou wrote:
>> Original description for JDK-8307194 change:
>> -
>> This PR is branched from the makefile changes for
>> https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for
>> handling th
On Thu, 25 May 2023 01:19:11 GMT, Jiangli Zhou wrote:
> > > > My build job is still running, but it has failed in two distinct ways
> > > > already. See below for mac fix. Our cross build of arm32 fails with
> > > > this message:
> > > > ```
On Wed, 24 May 2023 21:47:49 GMT, Jiangli Zhou wrote:
> > > My build job is still running, but it has failed in two distinct ways
> > > already. See below for mac fix. Our cross build of arm32 fails with this
> > > message:
> > > ```
> > > [2023
On Wed, 24 May 2023 20:52:38 GMT, Erik Joelsson wrote:
> > My build job is still running, but it has failed in two distinct ways
> > already. See below for mac fix. Our cross build of arm32 fails with this
> > message:
> > ```
> > [2023-05-24T19:25:15,310Z]
> > /opt/mach5/mesos/work_dir/jib-ma
On Wed, 24 May 2023 20:52:38 GMT, Erik Joelsson wrote:
>> My build job is still running, but it has failed in two distinct ways
>> already. See below for mac fix. Our cross build of arm32 fails with this
>> message:
>>
>>
>> [2023-05-24T19:25:15,310Z]
>> /opt/mach5/mesos/work_dir/jib-master/
ich caused failures on
> macosx- builds. On darwin (https://www.unix.com/man-page/osx/1/ar/),
> `ar` does not support @argument_file. The updated change avoids using
> @argument_file for `ar`.
>
> The partial linking change is done in make/common/NativeCompilation.gmk. The
> flag re
On Fri, 19 May 2023 21:20:19 GMT, Erik Joelsson wrote:
>> Jiangli Zhou has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> - Add $$($1_LD) $$($1_SYSROOT_LDFLAGS) to $1_VARDEPS if $(TOOLCHAIN_TYPE)
>> is
ich caused failures on
> macosx- builds. On darwin (https://www.unix.com/man-page/osx/1/ar/),
> `ar` does not support @argument_file. The updated change avoids using
> @argument_file for `ar`.
>
> The partial linking change is done in make/common/NativeCompilation.gmk. The
> flag re
On Mon, 22 May 2023 19:52:42 GMT, Erik Joelsson wrote:
>> Jiangli Zhou has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 12 commits:
>>
>> - Merge branch 'master' into JDK-8307858
>>
On Mon, 22 May 2023 19:54:59 GMT, Erik Joelsson wrote:
>> Jiangli Zhou has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 12 commits:
>>
>> - Merge branch 'master' into JDK-8307858
>>
ich caused failures on
> macosx- builds. On darwin (https://www.unix.com/man-page/osx/1/ar/),
> `ar` does not support @argument_file. The updated change avoids using
> @argument_file for `ar`.
>
> The partial linking change is done in make/common/NativeCompilation.gmk. The
> flag re
ich caused failures on
> macosx- builds. On darwin (https://www.unix.com/man-page/osx/1/ar/),
> `ar` does not support @argument_file. The updated change avoids using
> @argument_file for `ar`.
>
> The partial linking change is done in make/common/NativeCompilation.gmk. The
> flag r
On Mon, 22 May 2023 19:10:57 GMT, Jiangli Zhou wrote:
> Thanks @erikj79. Could you please help provide some more info on the build
> failure:
>
> Which macOs version ran into the build issue? My mac is on Ventura 13.3.1
> (a). It builds successfully for the `static-lib
On Fri, 19 May 2023 22:45:16 GMT, Erik Joelsson wrote:
>> make/common/NativeCompilation.gmk line 1208:
>>
>>> 1206: $$(call ExecuteWithLog,
>>> $$($1_OBJECT_DIR)/$$($1_SAFE_NAME)_partial_link, \
>>> 1207:$$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING)
>>> $(LD_OUT_OPTION)$$($1_TAR
On Fri, 19 May 2023 21:20:19 GMT, Erik Joelsson wrote:
> I ran this patch in our internal build and test system and got failures on
> macos and windows.
Thanks a lot, @erikj79! I was going to ask your help for testing the patch.
> I think I know the cause for the mac failure, but the Windows
Original description for JDK-8307194 change:
-
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:
- Build hotspot libjvm.a and JDK static libraries for
static-libs-image/sta
On Wed, 10 May 2023 21:07:23 GMT, Daniel D. Daugherty
wrote:
>> This reverts commit 1964954da9ac1d020e0b5ba35893f475d86ec909.
>
> All builds have passed.
Thank you, @dcubed-ojdk!
-
PR Comment: https://git.openjdk.org/jdk/pull/13918#issuecomment-1542821136
On Wed, 10 May 2023 17:13:13 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:
>>
>> - Build hotspot libjvm.
On Wed, 10 May 2023 20:24:30 GMT, Erik Joelsson wrote:
> This change caused all our builds but Linux to fail. Did you verify on other
> platforms than Linux at all? I see you have GHA turned off.
Sorry about the issue. There were failed workflows after I merged with the
latest JDK master this
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/hotspot static libraries:
>
> - Build hotspot libjvm.a and JDK stati
d libawt_head.a: Not include systemScale.o, since it's
> provided in libawt.a
>
> - Handle long arguments case for static build in
> make/common/NativeCompilation.gmk
>
> - Address @erikj79's comment in
> https://github.com/openjdk/jdk/pull/13709#discussion_r1
d libawt_head.a: Not include systemScale.o, since it's
> provided in libawt.a
>
> - Handle long arguments case for static build in
> make/common/NativeCompilation.gmk
>
> - Address @erikj79's comment in
> https://github.com/openjdk/jdk/pull/13709#discussion_r1
On Wed, 3 May 2023 13:34:12 GMT, Erik Joelsson 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 Tue, 9 May 2023 22:14:04 GMT, Erik Joelsson wrote:
> I think you also need to make a change to `GraalBuilderImage.gmk` and the
> target in `Main.gmk` that calls it.
Good catch! Fixed `GraalBuilderImage.gmk`, thanks!
For the `graal-builder-image` target that uses `GraalBuilderImage.gmk`, it'
x27;s
> provided in libawt.a
>
> - Handle long arguments case for static build in
> make/common/NativeCompilation.gmk
>
> - Address @erikj79's comment in
> https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for
> LIBJLI_STATIC_EXCLUDE_OBJS
Jiangli Zh
On Mon, 8 May 2023 19:45:18 GMT, Jiangli Zhou 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
x27;s
> provided in libawt.a
>
> - Handle long arguments case for static build in
> make/common/NativeCompilation.gmk
>
> - Address @erikj79's comment in
> https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for
> LIBJLI_STATIC_EXCLUDE_OBJS
Jiangli Zh
x27;s
> provided in libawt.a
>
> - Handle long arguments case for static build in
> make/common/NativeCompilation.gmk
>
> - Address @erikj79's comment in
> https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for
> LIBJLI_STATIC_EXCLUDE_OBJS
Jiangli Zh
On Fri, 5 May 2023 20:43:41 GMT, Erik Joelsson wrote:
> Further I would like to suggest that libjvm.a gets put in the variant subdir
> under lib, just like libjvm.so does today (e.g. `lib/server/libjvm.a`). That
> way you can support building libjvm.a for all variants without worry. It will
>
On Mon, 8 May 2023 08:57:37 GMT, Severin Gehwolf 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
On Fri, 5 May 2023 16:43:46 GMT, Jiangli Zhou wrote:
>>> [...] I'll see if I can test this on a mandrel build tomorrow...
>>
>> @jianglizhou So I've tested this with a mandrel build and it doesn't break
>> terribly, but a graalvm build after this patch
ikj79's comment in
> https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for
> LIBJLI_STATIC_EXCLUDE_OBJS;
Jiangli Zhou has updated the pull request incrementally with one additional
commit since the last revision:
Fix whitespace error in make/StaticJvmLibsImage.gmk.
-
Changes:
On Thu, 4 May 2023 19:12:14 GMT, Severin Gehwolf wrote:
>> As @jerboaa mentioned, for GraalVM native-image we produce our own
>> `libjvm.a` as part of building GraalVM (every native image gets statically
>> linked to that library). See
>> https://github.com/oracle/graal/blob/f1c1d710625ac84559
1 - 100 of 132 matches
Mail list logo
