On Wed, 19 Jun 2024 15:15:43 GMT, Magnus Ihse Bursie <i...@openjdk.org> wrote:
>> This patch contains a set of changes to improve static builds. They will >> pave the way for implementing a full static-only java launcher. The changes >> here will: >> >> 1) Make sure non-exported symbols are made local in the static libraries. >> This means that the risk of symbol conflict is the same for static libraries >> as for dynamic libraries (i.e. in practice zero, as long as a consistent >> naming scheme is used for exported functions). >> >> 2) Remove the work-arounds to exclude duplicated symbols. >> >> 3) Fix some code in hotspot and the JDK libraries that did not work properly >> with a static java launcher. >> >> The latter fixes are copied from or inspired by the work done by >> @jianglizhou and her team as part of the Project Leyden [Hermetic >> Java](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). > > Magnus Ihse Bursie has updated the pull request incrementally with one > additional commit since the last revision: > > Add dummy implementation of os::lookup_function for Windows src/java.base/unix/native/libjli/java_md.c line 316: > 314: SetExecname(*pargv); > 315: > 316: if (!JLI_IsStaticallyLinked()) { Any reason this is diverted from the change in hermetic Java branch, https://github.com/openjdk/leyden/blob/c1c5fc686c1452550e1b3663a320fba652248505/src/java.base/unix/native/libjli/java_md.c#L300? I think the setenv part below is not needed for static/hermetic support either. There is no $JRE/lib with a single executable image. All natives are statically linked with the executable image. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19478#discussion_r1649356484
