<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>On 2024-05-07 06:04, Jiangli Zhou wrote:</p>
<blockquote type="cite" cite="mid:CALrW1jzzQ8pkkXDmvM-9WbbdSiTrARZgnm6-x2V4zKC053RzgA@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">On Tue, Apr 30, 2024 at 5:42 AM Magnus Ihse Bursie
<a class="moz-txt-link-rfc2396E" href="mailto:magnus.ihse.bursie@oracle.com"><magnus.ihse.bursie@oracle.com></a> wrote:
</pre>
<blockquote type="cite"><span style="white-space: pre-wrap">
</span>
<pre class="moz-quote-pre" wrap="">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.</pre>
</blockquote>
</blockquote>
<p>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.</p>
<p>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.<br>
</p>
<p><span style="white-space: pre-wrap">
</span></p>
<blockquote type="cite" cite="mid:CALrW1jzzQ8pkkXDmvM-9WbbdSiTrARZgnm6-x2V4zKC053RzgA@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">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.</pre>
</blockquote>
<p>I'll have a look at that, thanks for the pointer.</p>
<blockquote type="cite" cite="mid:CALrW1jzzQ8pkkXDmvM-9WbbdSiTrARZgnm6-x2V4zKC053RzgA@mail.gmail.com">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.</pre>
</blockquote>
<p>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.<br>
</p>
<p>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? <br>
</p>
<p>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.</p>
<p>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. <br>
</p>
<p>/Magnus</p>
</body>
</html>