On Fri, 5 May 2023 16:43:46 GMT, Jiangli Zhou <jian...@openjdk.org> wrote:
>>> [...] 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. > At first glance, static-libs-image create libjvm.a in the same directory as > the other lib .a files make sense but I don't know how that works if > --with-jvm-variants is used to create more more than one libjvm. Might have > to think whether this combination make sense or not. We now use a java-static-libs-image target for building all JDK and hotspot .a static libraries. @erikj79 Suggested building libjvm.a for $(JVM_VARIANT_MAIN) for now. I think that's a good starting point. The PR has been updated accordingly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1186308007
