On Sun, 30 Apr 2023 18:34:12 GMT, Alan Bateman <al...@openjdk.org> 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 changes to remove duplicate symbol names. It's good > that the PR demonstrates that these can be linked to create "javastatic" but > having it copy into the run-time image created by jlink is probably not the > eventual outcome. > > 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 slides/proposal, it would mean that jlink could produce a single > executable that would work for both the JDK or any set of modules. The comment from @AlanBateman helped me realize that I should be more specific (in my earlier comment regarding "withdraw the current PR first and extract the .a part into a new PR") about the needed fixes/enhancements related to .a part: - Create libjvm.a as well when building static-libs-image target, include it in 'images/static-libs/lib' - Filter out "external" .o files (those are the .o files included from different JDK libraries and needed when creating the .so shared library only) from .a libraries - For libjvm.a specifically, exclude operator_new.o - Handle long arguments case for static build in make/common/NativeCompilation.gmk - Ensure zlib and freetype are bundled when building the static-libs-image target, i.e. libzlib.a and libfreetype.a are included in 'images/static-libs/lib' It's probably best to create a separate enhancement/bug for those (will create shortly) and continue using JDK-8303796 for the broader discussion/effort. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1530368068
