On Wed, 4 Sep 2024 23:06:00 GMT, Jiangli Zhou <jian...@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). > > make/StaticLibs.gmk line 71: > >> 69: # libsspi_bridge has name conflicts with sunmscapi >> 70: BROKEN_STATIC_LIBS += sspi_bridge >> 71: # These libs define DllMain which conflict with Hotspot > > I'm not aware of the DllMain issue with static linking these libs. Could you > please explain? The libawt.a and libdt_socket.a are statically linked with > `javastatic` in https://github.com/openjdk/leyden/tree/hermetic-java-runtime/ > branch. DllMain is a Windows specific initialization method that is called when a Windows dll (Dynamic library) is loaded, among other things. Since DllMain is extern "C", it is not mangled and hence likely that having multiple static libraries that each define it will cause multiple symbol definition errors during linking. It might be that the reason hermetic Java hasn't encountered this problem yet is because it mainly tests its code on Linux, while this is a Windows specific issue, since the names you mention (libawt.a and libdt_socket.a) are the names of those libraries on Linux, not Windows. However, the issue likely deeper than that. DllMain is completely wrong to define when inside a static library, and should not be compiled at all when making the static versions of these libraries. Simply localizing the DllMain symbol when creating a static library would be wrong. We'll have to find out how to run the initialization code for each of these currently dynamic libraries without DllMain when compiling them as static libraries > src/hotspot/share/classfile/classLoader.cpp line 953: > >> 951: assert(CanonicalizeEntry == nullptr, "should not load java library >> twice"); >> 952: if (is_vm_statically_linked()) { >> 953: CanonicalizeEntry = CAST_TO_FN_PTR(canonicalize_fn_t, >> os::lookup_function("JDK_Canonicalize")); > > Can you add an assert to make sure `CanonicalizeEntry` is not NULL? Also please remember to use nullptr and not NULL! @kimbarrett would appreciate it :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1744808169 PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1744810286
