On Thu, 4 May 2023 19:12:14 GMT, Severin Gehwolf <sgehw...@openjdk.org> wrote:
>> 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? > @jerboaa Thanks very much for testing with mandrel. Based on yours and > @olpaw's feedback, I'll refactor this PR to not use the existing > `static-libs-image` target for including hotspot `libjvm.a`. Updated PR to decouple building libjvm.a from static-libs-image target. Add a java-static-libs-image target for building the static library super set, which includes JDK .a static libraries and hotspot libjvm.a. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1186300461
