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 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 support is only added for t
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 support is only added for t
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 support is only added for t
On Fri, 28 Apr 2023 11:59:52 GMT, Alan Bateman 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 crea
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 support is only added for t
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 support is only added for t
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 22:32:34 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 is
> the linking command from my build:
I can't s
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 needed discussions (including
> th
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:
>
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
> > > is the linking command from my b
On Fri, 28 Apr 2023 18:14:48 GMT, Erik Joelsson 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 recent chan
On Sun, 30 Apr 2023 18:34:12 GMT, Alan Bateman wrote:
> A possible direction on this is for the build to create a set of packaged
> modules with the .a files, then have an alternative image builder in jlink
> that integrates with the native linker. Combined with other parts in
> Jiangli's slid
On Sun, 30 Apr 2023 18:53:40 GMT, Jorn Vernee wrote:
> It seems that letting jlink do the linking is also a requirement for user
> provided modules (.jmods) that contain native libraries (as is the case for
> instance with jextract). We don't know about those libraries when building
> the JDK.
On Fri, 28 Apr 2023 23:25:17 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_c
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
> 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 supporte
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'.
>>
>> In this PR, the support is only added
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.desktop/lib/Awt2dLibraries.gmk line 228
27 matches
Mail list logo
