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 support is only added for the linux platform. Both gcc and
clang can be supported. For curre
On Fri, 28 Apr 2023 04:57:45 GMT, David Holmes wrote:
> @jianglizhou I thought this work was proposed to be done under the Project
> Leyden umbrella? The other static-build tweaks have been fine but this seems
> to be part of a bigger, yet unspecified, project that may need to be covered
> by
On Fri, 28 Apr 2023 18:16:07 GMT, Erik Joelsson wrote:
> I pulled this PR and had a go at building it. For me it failed with errors
> like this:
>
> ```
> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function
> os::Linux::fast_thread_clock_init():
On Fri, 28 Apr 2023 18:14:48 GMT, Erik Joelsson wrote:
>
> If I understand the make file changes proposed here, it runs the native
> linker to create "javastatic" with the launcher, libjvm and other JNI libs
> linked into one executable, this is generated and copied into the run-time
> image
On Fri, 28 Apr 2023 19:40:34 GMT, Erik Joelsson wrote:
> I think it would be rather beneficial if this linking step could be performed
> by some variant of SetupNativeCompilation. We don't want to have to maintain
> logic for dealing with different platforms and linkers outside of the common
>
On Sat, 29 Apr 2023 00:03:24 GMT, Jiangli Zhou wrote:
> Based the initial feedback from you and other reviewers in the thread, I'll
> repurpose this PR for handling the .a part only. I'll split the 'javastatic'
> static linking part into a separate branch for
On Fri, 28 Apr 2023 18:25:14 GMT, Phil Race wrote:
> Why not ? Surely you aren't statically linking every library you find on the
> platform that's referenced by JDK ?
> I mean its fine to say that I'd prefer to statically link this library, but I
> don't understand the claim that this is the o
On Fri, 28 Apr 2023 18:28:51 GMT, Phil Race wrote:
> Umm. Does this mean you are linking both headless and xawt into the same
> image ?
For the xawt case, we statically link with libawt.a and libawt_xawt.a in our
early prototype. For headless case, we statically link with libawt.a and
libawt_
On Fri, 28 Apr 2023 23:25:17 GMT, Erik Joelsson wrote:
> > Erik, could you please share your
> > `support/native/java.base/java/BUILD_LAUNCHER_javastatic_static_link.cmdline`?
> > This generated .cmdline file contains the static linking command. Here is
> > the linking command from my build:
>
lib/CoreLibraries.gmk and
> make/modules/java.desktop/lib/Awt2dLibraries.gmk.
>
> - In make/common/NativeCompilation.gmk, move the code handling long arguments
> so that it can be used for the static build support as well.
>
> - In make/hotspot/lib/CompileJvm.gmk, it specifies
On Sat, 29 Apr 2023 01:44:07 GMT, Jiangli Zhou wrote:
> > > Erik, could you please share your
> > > `support/native/java.base/java/BUILD_LAUNCHER_javastatic_static_link.cmdline`?
> > > This generated .cmdline file contains the static linking command. Here
> >
On Mon, 1 May 2023 14:03:10 GMT, Erik Joelsson wrote:
> > Based on the above finding, I pushed a change to use $(JVM_LIBS) for the
> > linking command. @erikj79 could you please see if that resolves the clock_*
> > symbol issues in your environment?
>
> Yes, it built cleanly with that change.
On Sun, 30 Apr 2023 18:34:12 GMT, Alan Bateman wrote:
> > The build is already capable of producing .a files and this patch is
> > building on top of that build feature. The current .a file creation is used
> > by the downstream graal build which needs it for nativeimage.
>
> Also builds on re
On Sat, 29 Apr 2023 03:57:53 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'.
>>
>&g
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 building
'static-libs-image' (or 'static-libs-bundles') target, incl
On Fri, 28 Apr 2023 19:32:40 GMT, Erik Joelsson wrote:
> This is the same list as the LIBJLI_EXTRA_FILES above. Would be good to avoid
> the duplication.
@erikj79 Addressed in the extracted https://github.com/openjdk/jdk/pull/13768,
which contains .a related changes only (without linking 'java
On Fri, 28 Apr 2023 19:34:40 GMT, Erik Joelsson wrote:
>> Jiangli Zhou has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Use $(JVM_LIBS), which includes -lrt on Linux currently.
>
> make/modules/java.deskt
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:
Update based on @erikj79 review comments and suggestions:
- Change to copy li
On Wed, 3 May 2023 13:42:03 GMT, Erik Joelsson wrote:
>> Jiangli Zhou has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update based on @erikj79 review comments and suggestions:
>> - Change to copy libjvm.
On Wed, 3 May 2023 16:57:04 GMT, Severin Gehwolf wrote:
> @jianglizhou How does the produced image look like after this patch? I.e.
> what's the contents of `build/*/images/static-libs`?
With the changes in this patch, `build/*/images/static-libs` will contain the
`libjvm.a` in addition to the
On Wed, 3 May 2023 18:33:56 GMT, Erik Joelsson wrote:
>> make/Main.gmk line 1060:
>>
>>> 1058: symbols-image: $(LIBS_TARGETS) $(LAUNCHER_TARGETS)
>>> 1059:
>>> 1060: static-libs-image: hotspot-static-libs $(STATIC_LIBS_TARGETS)
>>
>> Could we decouple `hotspot-static-libs` from `static-lib
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:
Update make/StaticLibsImage.gmk
Thanks
Co-authored-by: Erik Joelsson
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:
Update make/StaticLibsImage.gmk
thanks
Co-authored-by: Erik Joelsson
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:
Update to create and use only hotspot-$(JVM_VARIANT_MAIN)-static-libs, bas
On Wed, 3 May 2023 18:31:56 GMT, Erik Joelsson wrote:
>> Jiangli Zhou has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update based on @erikj79 review comments and suggestions:
>> - Change to copy libjvm.
On Wed, 3 May 2023 18:51:54 GMT, Severin Gehwolf wrote:
>>> Could we decouple `hotspot-static-libs` from `static-libs-image` somehow,
>>> please? `static-libs-image` is used by the `graal-builder-image` target and
>>> it would be good if it didn't include hotspot static libs as they are not
>>
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
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
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:
- Separate building libjvm.a from static-libs-image target, based on input
fro
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:
- Separate building libjvm.a from static-libs-image target, based on input
fro
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
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 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
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 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
>
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 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
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'
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
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 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
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, 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.
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 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
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 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
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: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
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
>>
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
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 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 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 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: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, 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 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
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, 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
> >
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
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 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
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, 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
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 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 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 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 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 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
Please help review this trivial fix for resolving `ld: error: duplicate symbol:
closeDescriptors` when static linking with both libjdwp and libjava, thanks.
-
Commit messages:
- Make closeDescriptors() as static function in
src/java.base/unix/native/libjava/childproc.c and
src/jdk
On Mon, 26 Feb 2024 20:40:52 GMT, Chris Plummer wrote:
>> Please help review this trivial fix for resolving `ld: error: duplicate
>> symbol: closeDescriptors` when static linking with both libjdwp and libjava,
>> thanks.
>
> src/java.base/unix/native/libjava/childproc.h line 134:
>
>> 132: int
On Mon, 26 Feb 2024 22:15:00 GMT, Jiangli Zhou wrote:
>> src/java.base/unix/native/libjava/childproc.h line 134:
>>
>>> 132: int closeSafely(int fd);
>>> 133: int isAsciiDigit(char c);
>>> 134: int closeDescriptors(void);
>>
>> It seems tha
> Please help review this trivial fix for resolving `ld: error: duplicate
> symbol: closeDescriptors` when static linking with both libjdwp and libjava,
> thanks.
Jiangli Zhou has updated the pull request incrementally with two additional
commits since the last revision:
On Mon, 26 Feb 2024 20:37:45 GMT, Chris Plummer wrote:
>> Jiangli Zhou has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Address plummercj's comment and make forkedChildProcess static.
>> - Rever
On Mon, 26 Feb 2024 23:50:11 GMT, Chris Plummer wrote:
> Looks good.
Thanks for the quick review, @plummercj.
-
PR Comment: https://git.openjdk.org/jdk/pull/18013#issuecomment-1965539618
On Tue, 27 Feb 2024 00:34:49 GMT, Serguei Spitsyn wrote:
>> Jiangli Zhou has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Address plummercj's comment and make forkedChildProcess static.
>> - Rever
On Mon, 26 Feb 2024 20:20:31 GMT, Jiangli Zhou wrote:
> Please help review this trivial fix for resolving `ld: error: duplicate
> symbol: closeDescriptors` when static linking with both libjdwp and libjava,
> thanks.
This pull request has now been integrated.
Changeset: 0901de
Please help review this trivial change. This was branched from
https://github.com/openjdk/jdk/pull/18013, based on discussion with @plummercj
in https://github.com/openjdk/jdk/pull/18013 comments. Thanks
-
Commit messages:
- 8326714: Make file-local functions static in
src/java.ba
On Tue, 27 Feb 2024 07:29:46 GMT, Daniel Jeliński wrote:
>> Please help review this trivial change. This was branched from
>> https://github.com/openjdk/jdk/pull/18013, based on discussion with
>> @plummercj in https://github.com/openjdk/jdk/pull/18013 comments. Thanks
>
> LGTM
@djelinski @Rog
On Tue, 27 Feb 2024 03:11:37 GMT, Jiangli Zhou wrote:
> Please help review this trivial change. This was branched from
> https://github.com/openjdk/jdk/pull/18013, based on discussion with
> @plummercj in https://github.com/openjdk/jdk/pull/18013 comments. Thanks
This pull reques
On Mon, 25 Mar 2024 21:37:03 GMT, Liam Miller-Cushon wrote:
> This change fixes a zip64 bug in the launcher that is prevent it from reading
> the manifest of jars where the 'relative offset of local header' field in the
> central directory entry is >4GB. As described in APPNOTE.TXT 4.5.3, the
On Wed, 27 Mar 2024 16:03:09 GMT, Liam Miller-Cushon wrote:
>> src/java.base/share/native/libjli/manifest_info.h line 59:
>>
>>> 57: #define ZIP64_EXTID 1 // Extra field Zip64 header ID
>>> 58:
>>> 59: #define ZIP64_EXTMAXLEN 36 // Maximum Zip64 extra field length
>>
>> The fields desc
On Wed, 27 Mar 2024 17:43:41 GMT, Liam Miller-Cushon wrote:
>> This change fixes a zip64 bug in the launcher that is prevent it from
>> reading the manifest of jars where the 'relative offset of local header'
>> field in the central directory entry is >4GB. As described in APPNOTE.TXT
>> 4.5.3
On Wed, 27 Mar 2024 17:43:41 GMT, Liam Miller-Cushon wrote:
>> This change fixes a zip64 bug in the launcher that is prevent it from
>> reading the manifest of jars where the 'relative offset of local header'
>> field in the central directory entry is >4GB. As described in APPNOTE.TXT
>> 4.5.3
On Fri, 29 Mar 2024 17:50:00 GMT, Liam Miller-Cushon wrote:
>> src/java.base/share/native/libjli/parse_manifest.c line 505:
>>
>>> 503: Byte *base = p + CENHDR + CENNAM(p);
>>> 504: jlong offset = 0;
>>> 505: while (offset < cenext) {
>>
>> Any reason w
On Fri, 29 Mar 2024 18:08:56 GMT, Liam Miller-Cushon wrote:
>> Could you please point to the related spec for the other `extra field`?
>
> it's in APPNOTE.TXT 4.5, the extra field structure is `header1+data1 +
> header2+data2 . . .`, and we have to iterate through to see if there's an
> entry t
On Fri, 29 Mar 2024 17:38:47 GMT, Liam Miller-Cushon wrote:
>> This change fixes a zip64 bug in the launcher that is prevent it from
>> reading the manifest of jars where the 'relative offset of local header'
>> field in the central directory entry is >4GB. As described in APPNOTE.TXT
>> 4.5.3
On Fri, 29 Mar 2024 17:38:47 GMT, Liam Miller-Cushon wrote:
>> This change fixes a zip64 bug in the launcher that is prevent it from
>> reading the manifest of jars where the 'relative offset of local header'
>> field in the central directory entry is >4GB. As described in APPNOTE.TXT
>> 4.5.3
On Fri, 29 Mar 2024 18:41:09 GMT, Liam Miller-Cushon wrote:
>> src/java.base/share/native/libjli/parse_manifest.c line 197:
>>
>>> 195: jlong cenoff = CENOFF(cenhdr);
>>> 196: jlong cenext = CENEXT(cenhdr);
>>> 197: if (cenoff == ZIP64_MAGICVAL && cenext > 0) {
>>
>> Probably also need to
On Fri, 29 Mar 2024 18:43:51 GMT, Liam Miller-Cushon wrote:
>> src/java.base/share/native/libjli/parse_manifest.c line 506:
>>
>>> 504: jlong offset = 0;
>>> 505: while (offset < cenext) {
>>> 506: short headerId = ZIPEXT_HDR(base + offset);
>>
>> Thi
1 - 100 of 130 matches
Mail list logo
