RFR: 8338768: Introduce runtime lookup to check for static builds [v2]

Magnus Ihse Bursie ihse at openjdk.org
Tue Sep 10 21:50:14 UTC 2024


On Tue, 10 Sep 2024 13:51:55 GMT, Josef Eisl <jeisl at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Also update build to link properly
>
> src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c line 135:
> 
>> 133: #endif
>> 134: 
>> 135:     if (!JVM_IsStaticallyLinked()) {
> 
> These "cross-library" link-type probes are a challenge for GraalVM native image. In native image, we statically link most standard JNI libraries into the final executable. However in some cases, for example AWT, static linking is not feasible due to their dependencies. Thus, we resort to dynamic linking. Have a mix of static and dynamic linking means that `JVM_IsStaticallyLinked` should give different answers based on the caller. Example:
> lets assume a follow-up change introduces a call to `JVM_IsStaticallyLinked` in libnet (which native image statically links):
> * if `JVM_IsStaticallyLinked` is called from libawt.so, we want to answer `false`
> * if `JVM_IsStaticallyLinked` is called from libnet.a, we want to answer `true`
> 
> Is the mixed linking use case is something that the Hermetic Java effort is having on its radar?
> 
> For this particular case, one solutions could be to avoid cross-library calls. I.e., instead of calling `JVM_IsStaticallyLinked`, have an `AWT_IsStaticallyLinked` that is local to the libawt. This is similar to the pattern also used for JLI.

Mixing static and dynamic libraries willy-nilly sounds like a situation that is hard to resolve in a safe and sound way. The basic assumption here has been that you either have all libraries dynamic, or all libraries static.

In the particular case you mention about libawt, I think the proper solution is to sort out the mess that is libawt_headless/libawt_xawt. It seems to me that the X support should be loaded using dlopen, not by hard dependencies to the X libraries. I think that should solve your problem (as well as many other problems).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20666#discussion_r1752767100


More information about the serviceability-dev mailing list