This is potentially a "future" issue as fully statically linking the launcher executable is not in the JDK mainline yet, but it seems to be a good idea to file the bug for resolving the '-Wl,--exclude-libs,ALL' issue. Please see following details.

I synced https://github.com/openjdk/leyden/tree/hermetic-java-runtime/ last week (the previous sync was done in March 2024) and noticed `javastatic` (the launcher executable that's fully statically linked with most of the JDK static libraries and libjvm.a) fails during startup.

```
$ bin/javastatic
Error: could not find libjava.so
Error: Could not find Java SE Runtime Environment.
```

The issue is due to the system fails to detect that its executing in "static Java" mode and tries to `dlopen` `libjava.so`, which doesn't exist (as `libjava.a` is statically linked with `javastatic`). In the leyden/hermetic-java-runtime branch, the system uses dynamic symbol lookup to look for special symbols from the VM to help detect if its executing in "static Java" mode. However, no symbols from any of the JDK static libraries or libjvm.a` are exported. As a result, it assumes the execution uses dynamic linking, hence the error. Ignoring the part about checking using symbol lookup for now as that's being changed, the issue boils down to no dynamic symbol exporting from libjvm.a and JDK static libraries.

With manual bisecting, I narrowed down the related change to https://github.com/openjdk/jdk/commit/44aef386238977a960093027d9784c667550aae4. Specifically the dynamic symbol exporting issue with `javastatic` is due to using `-Wl,--exclude-libs,ALL`. https://github.com/openjdk/jdk/commit/44aef386238977a960093027d9784c667550aae4 moved `-Wl,--exclude-libs,ALL` to $BASIC_LDFLAGS. $BASIC_LDFLAGS is included in $2JVM_LDFLAGS. As a result `-Wl,--exclude-libs,ALL` is being included when linking `javastatic`. That causes none of the JDK/hotspot dynamic symbols are being exported.