On Fri, 1 Nov 2024 16:25:59 GMT, Magnus Ihse Bursie <i...@openjdk.org> wrote:
>> As a prerequisite for Hermetic Java, we need a statically linked `java` >> launcher. It should behave like the normal, dynamically linked `java` >> launcher, except that all JDK native libraries should be statically, not >> dynamically, linked. >> >> This patch is the first step towards this goal. It will generate a >> `static-jdk` image with a statically linked launcher. This launcher is >> missing several native libs, however, and does therefore not behave like a >> proper dynamic java. One of the reasons for this is that local symbol hiding >> in static libraries are not implemented yet, which causes symbol clashes >> when linking all static libraries together. This will be addressed in an >> upcoming patch. >> >> All changes in the `src` directory are copied from, or inspired by, changes >> made in [the hermetic-java-runtime branch in Project >> Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). > > 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 I'm still not sure how or why this goes wrong on Linux (or why it manages to work on macOS!), but at least with this patch I get it to work on Linux: diff --git a/src/java.base/share/classes/jdk/internal/jimage/NativeImageBuffer.java b/src/java.base/share/classes/jdk/internal/jimage/NativeImageBuffer.java index 0e3b178c32b..54db79e6527 100644 --- a/src/java.base/share/classes/jdk/internal/jimage/NativeImageBuffer.java +++ b/src/java.base/share/classes/jdk/internal/jimage/NativeImageBuffer.java @@ -40,7 +40,7 @@ class NativeImageBuffer { new java.security.PrivilegedAction<Void>() { @SuppressWarnings("restricted") public Void run() { - System.loadLibrary("jimage"); + jdk.internal.loader.BootLoader.loadLibrary("jimage"); return null; } }); The problem here is that this file is also compiled as part of the jrtfs.jar, where `BootLoader` is not available, so I also had to do diff --git a/make/Main.gmk b/make/Main.gmk index 9fc5490a1ef..606dd215e72 100644 --- a/make/Main.gmk +++ b/make/Main.gmk @@ -1000,7 +1000,7 @@ else # When creating the BUILDJDK, we don't need to add hashes to java.base, thus # we don't need to depend on all other jmods ifneq ($(CREATING_BUILDJDK), true) - java.base-jmod: jrtfs-jar $(addsuffix -jmod, $(filter-out java.base, $(sort \ + java.base-jmod: $(addsuffix -jmod, $(filter-out java.base, $(sort \ $(foreach m, $(filter-out $(call FindAllUpgradeableModules), $(JMOD_MODULES)), \ $m $(call FindTransitiveDepsForModules, $m) \ )))) to be able to compile this. But this seems to be the wrong approach. `System.loadLibrary("jimage")` should be able to figure out that an internal, statically-linked, library is being requested. Or at least, I guess that is a reasonable approach? I searched for `System.loadLibrary` and we're doing that a lot to connect to our internal native libraries. (One alternative approach would have been that the JDK should have a separate way to load its own internal libraries, that is not exposed to user code. I was honestly a bit surprised to find out that this is not the case.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2452258062
