On Wed, 3 May 2023 18:40:52 GMT, Jiangli Zhou <jian...@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
