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

[Paul Woegerer]

On Wed, 3 May 2023 18:51:54 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

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

As @jerboaa mentioned, for GraalVM native-image we produce our own `libjvm.a` as part of building GraalVM (every native image gets statically linked to that library). See https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/mx_substratevm.py#L1378 and `com.oracle.svm.native.jvm.{posix,windows}` in https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/suite.py#L736.

Having a hot-spot variant of `libjvm.a` next to the other static libraries might complicate things for us. Ideally the output files produced by target `static-libs-image` should remain the same.

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

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