RFR: 8338768: Introduce runtime lookup to check for static builds [v2]

[David Holmes]

On Thu, 22 Aug 2024 08:54:56 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Sorry but I don't understand the point of changing build-time constructs using `ifdef STATIC_BUILD` into what appear to be runtime checks, but the result of which is already determined at build time. These are not really runtime checks.
>
> @dholmes-ora 
> 
>> Sorry but I don't understand the point of changing build-time constructs using ifdef STATIC_BUILD into what appear to be runtime checks, but the result of which is already determined at build time. 
> 
> I apologize. I did not express the intent of this change clear enough.
> 
> The background is that we want to build and test statically linked native libraries. Currently, building a statically linked version requires recompiling all native source code into a completely new set of .o files, which are then linked into a static library.
> 
> This is extremely wasteful. Most of the code is completely identical for static and dynamic libraries. To fix this, me, Jiangli and her team have been working on a way to get around this.
> 
> By moving the ifdef check to a new file that just contains a single function, we only need to compile this single file twice -- once for the static library, and once for the dynamic library. All other .o files is compiled just once, and then you link "all other files" + "the one special file for your kind of library" to get what you want. 
> 
> Unfortunately, there is also one more blocker before this can be achieved. That is the reason the corresponding change in the build system is not included in this patch. (So this is a preparation for these future changes, but not the complete solution.) The missing part is that the `[JNI|Agent]_On[Un]Load` functions need to be able to use the static linked naming scheme, even for dynamically linked libraries. This is trivial per se, but requires a spec change, which has not yet happened.
> 
> The reason I want to get this partial solution into the mainline right now, instead of waiting for the spec change and the complete build system fix, is that these new functions for checking for static/dynamic are needed by additional changes that Jiangli have created upstream, and that I am trying to help her get integrated. (The goal of these changes is to make not just static libraries, but to link these static libraries with the java launcher into a statically linked launcher, which is a pre-requisite for the rest of the Hermetic Java story.)

@magicus is the final intent here that this one magic file will be compiled first with an inline declaration such that when the other files containing the apparent runtime check get compiled, it can actually be determined at build time and so have the same effects as the old ifdef logic?

Otherwise it concerns me that a build-time issue that affects a handful of people becomes a runtime issue that affects every single instance of a running Java program.

There are also other source-level solutions possible here by refactoring the code that has static vs dynamic linking dependencies into its own files and the build system can then select which set of files to compile.

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

PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2305875408