RFR: 8339480: Build static-jdk image with a statically linked launcher [v7]

[Magnus Ihse Bursie]

On Wed, 23 Oct 2024 08:23:34 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Don't hardcode server variant
>
> I tried to build/run this on Linux as well (since I'm using parts of this PR in https://github.com/openjdk/mobile/pull/30) and I noticed that the executable doesn't start (even with --version):
> 
> images/static-jdk/bin/java --version
> Error: Failed , because images/static-jdk/bin/java: undefined symbol: JNI_CreateJavaVM
> 
> The `JNI_CreateJavaVM` symbol seems to be local only:
> 
> nm images/static-jdk/bin/java |grep JNI_CreateJ
> 0000000000e22430 t JNI_CreateJavaVM
> 
> Hence calling it with `dlsym` won't work. And indeed, that is how it is called from `./java.base/unix/native/libjli/java_md.c ` `(LoadJavaVM)`
> 
> dlsym(libjvm, "JNI_CreateJavaVM");
> 
> 
> I noticed that the launcher is created using `-Wl,--export-dynamic ... -Wl,--whole-archive ... libjvm.a`
> I checked `libjvm.a` and as expected, that contains a global symbol for JNI_CreateJavaVM:
> 
> nm libjvm.a |grep JNI_CreateJavaVM
> 0000000000000000 T JNI_CreateJavaVM
> 
> If I remove the `-Wl,--export-dynamic` from the link options, the resulting executable has a global symbol for JNI_createJavaVM. However, in that case `dlsym` will clearly not work because the symbol is not added to the symbol table.
> 
> This is maybe a stupid question, but I wonder though why `dlsym` is used here? 
> When doing this for iOS, I directly use the symbols (instead of searching for them using `dlsym`). We know for sure that this symbol is in the executable, as it is statically linked into it.

@johanvos 

There is indeed no reason to use dlsym for a static build. Unfortunately, the code related to looking up symbols in JDK-internal libraries is still not up to par. It is scattered among several places, and each place is doing its own implementation. I was thinking that cleaning this up could be done as a follow-up, later on, but maybe it is necessary to take the bull by the horns and address all those places in this PR as well. Many of them are already touched by this PR anyway...

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

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2452177592