RFR: 8307194: Enhance static-libs-image [v2]

[Jiangli Zhou]

On Wed, 3 May 2023 18:33:56 GMT, Erik Joelsson <erikj at openjdk.org> 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-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 needed for it.
>> 
>> Would it be sufficient to just use `hotspot-static-libs` directly? Like: `make static-libs-image hotspot-static-libs`? Failing that, could we introduce a new target that produces both?
>
> I'm hoping to get input from the graal team on the impact of this change. The exact usage of the new libjvm.a file is still under discussion so I share you concern about changing things for the current static libs usecase before we fully understand where this is going.

> 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 needed for it.
> 
> Would it be sufficient to just use `hotspot-static-libs` directly? Like: `make static-libs-image hotspot-static-libs`? Failing that, could we introduce a new target that produces both?

Good questions. I had similar thoughts when making the makefile changes. Here's my reasoning with the current approach in this PR:

The `images/static-libs/lib` would provide a super set of the JDK/VM static libraries (in a JDK binary/release) for downstream developers to produce their desired final static image. With the addition of the `libjvm.a` and potentially bundled `libzlib.a` and `libfreetype.a` included in `static-libs-image` output, users could select the needed subset of the static libraries for their linking step (e.g. via jlink based on the needed modules) to produce the final image. 

If these changes are cumbersome for `graal-builder-image` usages, using `hotspot-static-libs` directly for producing `libjvm.a` as you suggested could be doable. Or, we could try using a new make target for producing the `.a` superset. There might be potential concerns/issues with the differences between `graal-builder-image` support and Java static image support, i.e. it might be a good idea to explore unified solution for both if possible. @dougxc and others related to GraalVM Native Image are on this review thread. It's a good idea to collect the thoughts together.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1184113709