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

[Jiangli Zhou]

On Sun, 3 Nov 2024 20:23:32 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
>> 
>>  - Merge branch 'master' into static-jdk-image
>>  - Fix bug in filtering out -Wl,--exclude-libs,ALL
>>  - Don't hardcode server variant
>>  - Setup LDFLAGS_STATIC_JDK
>>  - Update GetJREPath comment and remove unnecessary JLI_IsStaticallyLinked check
>>  - Add lookup asserts
>>  - Remove superfluous SRC.
>>  - Merge branch 'master' into static-jdk-image
>>  - Makefile changes needed for static-launcher and static-jdk-image targets
>>  - Incorporate changes from leyden/hermetic-java-runtime that allows running a static launcher
>
> https://github.com/openjdk/jdk/pull/21861 for adding DEF_STATIC_JNI_OnLoad in libjimage and libsaproc native libraries.

> @jianglizhou I'm trying to follow your comments here... Am I correct in understanding that you are saying that the missing DEF_STATIC_JNI_OnLoad is not, in fact, the problem that causes .java files to not load? Because I tried applying your patch from #21861, and it did not help.

The missing`DEF_STATIC_JNI_OnLoad` in jimage.cpp **is** the cause. With the fix, running `static-jdk/bin/java` with `HelloWorld.java` now works for me without failure:


build/linux-x86_64-server-slowdebug/images/static-jdk$ bin/java ~/tests/HelloWorld.java
HelloWorld


> Because I tried applying your patch from #21861, and it did not help.

Did you do a clean build? I notice incremental build with your current PR doesn't update `static-jdk/bin/java` properly. This should be fixed as well. 

Please do `make clean` and rebuild the `images` and `static-jdk-image` to test if you are still running into any failure. If you are still seeing failures, please send me the specific build and run commands.

> 
> > I think we would need to decide what is the `dll_dir` with the static JDK support and hermetic support.
> 
> Do you mean that this the core issue related to the .java launching failure?

No, the `dll_dir` issue that I pointed out earlier was not the cause. 

With static JDK support, `libjimage` is statically linked with  `static-jdk/bin/java`. When `loadLibrary()` is called to "load" the `jimage` native library, the system first looks for built-in `jimage` native library by looking up `JNI_OnLoad_jimage` symbol. If the symbol exists, it means the `libjimage` is built in and there is no need to `dlopen` the native library from `dll_dir`. That's why the `dll_dir` issue is not the root cause.  If it can't find `JNI_OnLoad_jimage` symbol, the system would try to load `libjimage.so` from `dll_dir`. However, that should never happen with static JDK.

`JNI_OnLoad_jimage` symbol is defined by `DEF_STATIC_JNI_OnLoad` macro. That's why the missing `DEF_STATIC_JNI_OnLoad` in jimage.cpp is the root cause of the `loadLibrary()` failure.

> 
> I also find it curious that it does work on macOS, but not on Linux. This indicates, to me, that there is some difference in platform-dependent code that is different between Linux and mac, and there is not much such code in this PR. So maybe it is some pre-existing difference in code that provokes this difference in behavior.

I think the macOS might have other bugs that masks this failure. As we discussed in hermetic Java meetings, let's focus on supporting the Linux platform initially.

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

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