Hermetic Java project meeting

[Magnus Ihse Bursie]

On 2024-05-07 06:04, Jiangli Zhou wrote:

> On Tue, Apr 30, 2024 at 5:42 AM Magnus Ihse Bursie
> <magnus.ihse.bursie at oracle.com>  wrote:
>> I am not sure why clang insisted on picking up ld and not lld. I remeber
>> trying with -fuse-ld=lld, and that it did not work either.
>> Unfortunately, I don't remember exactly what the problems were.
>>
>> I started reinstalling my Linux workstation yesterday, but something
>> went wrong, and it failed so hard that it got semi-bricked by the new
>> installation, so I need to redo everything from scratch. :-( After that
>> is done, I'll re-test. Hopefully this was just my old installation that
>> was too broken.

I decided to spend the time to reinstall my machine. Now linking with 
clang works. Kind of. For some reason, it still picks up binutils ld and 
not lld, and then -l:libc++.a does not work, but when I replaced it with 
-l:libstdc++.a it worked just fine. I guess we need to either forcefully 
add -fuse-ld=lld to our clang compilation lines, or figure out if clang 
is going to call the binutils or llvm ld, and select the right option.

I still find the logic for how clang and gcc locates the default linker 
to be mostly magic. I guess I need to make a deep dive in understanding 
this to be able to resolve this properly.

> The JDK and VM code has pre-existing assumptions about the JDK
> directories and dynamic linking (e.g. the .so).
> JLI_IsStaticJDK|JLI_SetStaticJDK|JVM_IsStaticJDK|JVM_SetStaticJDK is
> needed for static JDK support to handle those cases correctly.
> CreateExecutionEnvironment that I mentioned earlier is one of the
> examples.
>
> I'm quite certain the issue that you are running into is due to the
> incorrect static check/handling in CreateExecutionEnvironment.

I'll have a look at that, thanks for the pointer.

>> In my branch, I am only using compile-time #ifdef checks for static vs
>> dynamic. In the long run, the runtime checks that you have done are a
>> good thing, but at the moment they are just adding intrusive changes
>> without providing any benefit -- if we can't reuse .o files between
>> dynamic and static compilation, there is no point in introducing a
>> runtime check when we already have a working compile-time check.
> I haven't seen your branch/code. I'd suggest not going with the #ifdef
> checks as that's the opposite direction of what we want to achieve. It
> doesn't seem to be worth your effort to add more #ifdef checks in
> order to do static linking build work, even those are for temporary
> testing reasons.

Okaaaaay... My understanding was that you wanted to push for the 
quickest possible integration of building a static java launcher into 
mainline. To do that as fast as possible, we need to use the existing 
framework for separating statically and dynamically linked libraries, 
which means doing compile time checks using #ifdefs.

Are you saying now that the priorities has changed, and that you want to 
start by introducing your framework for the runtime lookup if we are 
static or dynamic?

To be honest, I think your prototype is rather hacky in how you 
implement this, and I reckon that it will require quite a lot of work to 
be accepted into mainline. I also think you need a CSR for changing the 
Hotspot/JDK behavior wrt this, which further adds to the process.

If you want to go that route instead, then I'll put my work on hold 
until you have gotten a working solution for the runtime lookup in 
mainline. I gather this means that there is no real stress for me anymore.

/Magnus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20240507/13543216/attachment.htm>