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

[Severin Gehwolf]

On Wed, 3 May 2023 18:40:52 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> 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.

GraalVM native-image has it's own `libjvm.a` shim which would likely conflict or produce undesirable results. So I'd prefer the approach where `static-libs-image` wouldn't produce hotspot `libjvm.a` as part of it. For new uses-cases needing that, we could add a new top-level target (like `graal-builder-image`) which would produce such an image. As one of the [Mandrel](https://github.com/graalvm/mandrel) maintainers, I'm not sure any post-build filtering via `jlink` or the like would be ideal for us. I'll see if I can test this on a mandrel build tomorrow...

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

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