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

Reply via email to