On Fri, 5 May 2023 16:52:22 GMT, Jiangli Zhou <jian...@openjdk.org> 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 containing hotspot >> libjvm.a and JDK static libraries >> >> - For libjvm.a specifically, exclude operator_new.o >> >> - Filter out "external" .o files (those are the .o files included from a >> different JDK library and needed when creating the .so shared library only) >> from JDK .a libraries; That's to avoid linker failures caused by duplicate >> symbols >> - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o >> zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled >> - For libawt_xawt.a and 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_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. With this solution, the build will produce a different static-libs bundle and image depending on the make target called, but the output name is exactly the same. That isn't ok. If you run one target after the other, the behavior becomes strange and unpredictable. If these are different deliverables, they need to be that all the way through, with a separate image and bundle with their own make targets. If we go with two separate deliverables, then to me it makes more sense that "static-libs-image" is the complete image with all the static libs and if graal needs a specialized subset of this, then that's something graal specific. The graal-builder-image is already meant just for their consumption (which is a combination of the jdk-image and the current static-libs-image). Having graal builds having to change the target they call is inconvenient for them, but for us to be forced to maintain unintuitive build targets is also bad. 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 target `static-libs-image` produces. Given that I propose the following behavior: `make static-libs-image` produces `images/static-libs` with all .a (including libjvm.a). `make static-libs-graal-image` produces `images/static-libs-graal` with all .a except libjvm.a. `make graal-builder-image` produces `images/graal-builder-image` like today, but depends on and uses `static-libs-graal-image` instead of `static-libs-image`. `make static-libs-bundles` depends on and uses `static-libs-image` like today, so will contain libjvm.a, which is new behavior. 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 also get libjvm.a out of the way to cause less trouble for a graal build that uses the static-libs-bundles as input. This goes against what I suggested before, to just use JVM_VARIANT_MAIN, but I think this makes for a cleaner long term solution given the goals of the hermetic java effort. ------------- PR Review: https://git.openjdk.org/jdk/pull/13768#pullrequestreview-1415436469
