RFR: 8333268: Fixes for static build [v4]

[Alan Bateman]

On Wed, 19 Jun 2024 15:15:43 GMT, Magnus Ihse Bursie <ihse at 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

The changes to the launcher look okay. The move from `ifdef STATIC_BUILD` to `JLI_IsStaticallyLinked` is quite nice.

Having libjdwp link to libjvm was a surprise but I think okay.

I think it would be useful to provide a brief summary on the when/where the static builds are tested to ensure that the changes don't bit rot. I realise we already have static builds but it isn't obvious where this is tested.

src/hotspot/share/runtime/linkType.cpp line 36:

> 34:   return JNI_TRUE;
> 35: #else
> 36:   return JNI_FALSE;

bool != jboolean, I assume you don't want that.

The naming is a bit unusual, a function that returns a boolean is usually name is_XXX, but maybe there is reason for this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19478#issuecomment-2180635747
PR Review Comment: https://git.openjdk.org/jdk/pull/19478#discussion_r1647480992