On Thu, 19 Dec 2024 21:48:27 GMT, Phil Race <p...@openjdk.org> wrote:
>> When the static launcher was introduced in >> [JDK-8339480](https://bugs.openjdk.org/browse/JDK-8339480), due to time and >> resource constraints, it was only working properly on Linux and macOS, while >> the Windows port compiled but did not work. Now the time has come to fix >> that. >> >> Most of the changes mirrors the kind of changes that were made for Linux and >> macOS in JDK-8339480. There are still limitations to static builds on >> Windows (e.g. starting with a splashscreen), but these kind of limitations >> also exists on the other platforms. >> >> Note that this PR is blocked by >> [JDK-8346433](https://bugs.openjdk.org/browse/JDK-8346433), >> [JDK-8346195](https://bugs.openjdk.org/browse/JDK-8346195), >> [JDK-8346378](https://bugs.openjdk.org/browse/JDK-8346378), >> [JDK-8346383](https://bugs.openjdk.org/browse/JDK-8346383), >> [JDK-8346388](https://bugs.openjdk.org/browse/JDK-8346388) and >> [JDK-8346394](https://bugs.openjdk.org/browse/JDK-8346394), which must be >> integrated before this one. > > src/java.base/windows/native/libjli/java_md.c line 233: > >> 231: if (JLI_IsStaticallyLinked()) { >> 232: // For statically linked builds, we rely on the system msvcrt >> dlls >> 233: loaded = 1; > > Well that's a limitation. Yes, maybe. A quick googling gives that it appears possible, but not recommended, to statically link msvcrt libraries, so I don't think we should try to go down that route. However, the situation is not principally different from other situations where we rely on system libraries. I know that historically msvcrt libraries of incorrect versions (or entirely missing) have been more of an issue, but I wonder how much so it is in the present. I don't think we'll know for sure until this has been tested "in the wild". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22795#discussion_r1893913410
