On Wed, 3 May 2023 18:51:54 GMT, Severin Gehwolf <sgehw...@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
