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

Erik Joelsson erikj at openjdk.org
Tue Nov 19 20:41:22 UTC 2024


On Mon, 18 Nov 2024 15:12:12 GMT, Magnus Ihse Bursie <ihse at 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 incrementally with one additional commit since the last revision:
> 
>   Copy debuginfo

make/StaticLibs.gmk line 67:

> 65:   # BitmapToYXBandedRectangles, so we exclude it for now.
> 66:   BROKEN_STATIC_LIBS += splashscreen
> 67:   # windowsaccessbridge-64 has multiple collisions and conflicts

I don't think we will ever include the accessbridge libraries. Those are never loaded by the JDK itself. They are meant to be loaded by other applications to interact with the JDK. So instead of classifying them as "broken", I think they should just be permanently excluded for a valid reason.

make/autoconf/buildjdk-spec.gmk.template line 80:

> 78: CXXFLAGS_JDKEXE := @OPENJDK_BUILD_CXXFLAGS_JDKEXE@
> 79: LDFLAGS_JDKEXE := @OPENJDK_BUILD_LDFLAGS_JDKEXE@
> 80: LDFLAGS_STATIC_JDK := @OPENJDK_BUILD_LDFLAGS_STATIC_JDK@

Do we really expect to ever build a static-jdk as buildjdk?

make/common/JdkNativeCompilation.gmk line 313:

> 311:     # created libraries, and is read by ModuleWrapper.
> 312:     ifneq ($$($1_EXCLUDE_FROM_STATIC_LIBS), true)
> 313:       $$(MODULE)_JDK_LIBS += $$($1_NAME)

This variable is used to track libraries that should be included in static libs. Perhaps the name should include the word "static" to make this clearer? Otherwise it doesn't make sense to exclude libraries like this from this list.

make/modules/java.desktop/lib/ClientLibraries.gmk line 166:

> 164:         jfdctflt.o jfdctfst.o jfdctint.o jidctflt.o jidctfst.o jidctint.o \
> 165:         jidctred.o jmemmgr.o jmemnobs.o jpegdecoder.o jquant1.o jquant2.o \
> 166:         jutils.o

If libsplashscreen is already excluded in StaticLibs.gmk, why do we need to exclude obj files here?

Would it be possible to generate this list? I assume it's all the src files in libjavajpeg, but with the object file suffix.

make/modules/java.desktop/lib/ClientLibraries.gmk line 180:

> 178:         deflate.o Deflater.o Inflater.o gzclose.o gzlib.o gzread.o gzwrite.o \
> 179:         infback.o inffast.o inflate.o inftrees.o trees.o uncompr.o zadler32.o \
> 180:         zcrc32.o zip_util.o zutil.o

Same as above.

make/modules/jdk.accessibility/Lib.gmk line 77:

> 75:       VERSIONINFO_RESOURCE := \
> 76:           $(ACCESSIBILITY_SRCDIR)/common/AccessBridgeStatusWindow.rc, \
> 77:       STATIC_LIB_EXCLUDE_OBJS := AccessBridgeDebug.obj AccessBridgeMessages.obj, \

Again, the accessbridge libraries aren't loaded by the JDK, so it doesn't really make sense to include them in a single static launcher.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1848957096
PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1849009531
PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1849016315
PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1849022738
PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1849023239
PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1849026904


More information about the build-dev mailing list