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

[Jiangli Zhou]

On Thu, 5 Sep 2024 05:06:55 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> 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 DllMai
 n when compiling them as static libraries

@TheShermanTanker thanks for the details on DllMain issue. Right, we have only tested hermetic/static Java on Linux.

I agree that hiding DllMain is not the right approach. One possible solution is to put the DllMain in separate .c/.cpp files and only link with those when building the .dll. 

With the current PR, we mainly focuses on the Linux (or unix-like) port, e.g. `os::lookup_function()` is not supported in the Windows port yet. Any thoughts on if we only limit static linking these affected JDK libraries on Windows initially, and allow statically linking more libs on Linux? We can add those libs on Windows when we resolve the DllMain issue. For running some minimum jtreg testing initially, I think we would want to include `libnet` (and other libs) in the statically linked `java` binary.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1746129101