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

[Jiangli Zhou]

On Tue, 27 Aug 2024 13:55:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Also update build to link properly
>
> And the discussion whether the checks are made "dynamically" or "statically" is too simplified to be really helpful.
> 
> Currently, we compile two sets of all object files, with slightly different compiler arguments, one for dynamic libraries and one for static libraries. Files that are doing things differently for these two modes have an #ifdef, so the alternative way of doing things are not included in the object file. 
> 
> In your branch, you still have a separate compilation of all files for static builds, but you also try to figure out through various means (which involves jumping through some hoops to get the bootstrapping right) if this is a static build or a dynamic build. In a way, one could argue that this is just worse than the current solution, since you are still recompiling all files separately for static libraries so you could "know" at build time if you are static or not.
> 
> What I am trying to do is to get to a point where we can compile almost all files just once, and then have two trivially small files that are compiled twice, with just a different value of a define that makes the difference. To propagate this information to all other object files, they need to call the function provided in this object file. So, is it then a "build time" lookup or a "runtime lookup", or a "static lookup" vs "dynamic lookup"? The semantics does not really matter. The whole point is that the difference in build is reduced to an absolute minimum. Sure, this single "lookup" function could be created more like the way you are doing in your branch to try to figure this out without the help of the build system, but there is really no point in that. This is a simple and elegant solution.

We had a zoom discussion with @magicus and others on this PR (as part of regular hermetic Java meeting) this morning. @magicus mentioned that he has a PR in progress with the static linking part, which helps address my specific concern.

> In your branch, you still have a separate compilation of all files for static builds, but you also try to figure out through various means (which involves jumping through some hoops to get the bootstrapping right) if this is a static build or a dynamic build. In a way, one could argue that this is just worse than the current solution, since you are still recompiling all files separately for static libraries so you could "know" at build time if you are static or not.

Yes, the .o files are recompiled for creating the static libraries currently. That causes observable large overhead in terms of both memory and build duration for building JDK itself. In real world constraint environments, both overhead are problematic and cause build issues. So steps toward building the `.so` and `.a` using the same set of `.o` object files should be one of our end goals (just to re-iterate its importance), but would be "ok" without during the initial phases when we are building/integrating hermetic/static support in JDK mainline.

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

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