On Thu, 4 May 2023 09:40:31 GMT, Paul Woegerer <d...@openjdk.org> wrote:
>> 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. > [...] I'll see if I can test this on a mandrel build tomorrow... @jianglizhou So I've tested this with a mandrel build and it doesn't break terribly, but a graalvm build after this patch has *two* `libjvm.a` which a) doesn't make sense, b) the hotspot version is **very** large (> 1 GB on my system), so unnecessarily bloats the install. I remain of the opinion that the hotspot `libjvm.a` should only get generated for a new make target (not change the old `static-libs-image` target). Do you think that would be a workable solution for you? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1185416553
