<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>On 2025-04-15 16:28, Jiangli Zhou wrote:</p>
<blockquote type="cite" cite="mid:qcMjLHvuURcDCeqw00BIsaAr0WYhnGsHGnWGOdH-kjQ=.e4ef69f3-bbe1-48cb-ac73-8ad26b23917a@github.com">
<pre class="moz-quote-pre" wrap="">On Thu, 10 Apr 2025 16:13:47 GMT, Severin Gehwolf <a class="moz-txt-link-rfc2396E" href="mailto:sgehwolf@openjdk.org"><sgehwolf@openjdk.org></a> wrote:
</pre>
<span style="white-space: pre-wrap">
</span>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">$ ll -lh ./demo-image
-rwxr-xr-x. 1 sgehwolf sgehwolf 909M Apr 10 17:36 ./demo-image
$ strip -g ./demo-image
$ ll -lh ./demo-image
-rwxr-xr-x. 1 sgehwolf sgehwolf 50M Apr 10 18:07 ./demo-image
$ ./demo-image -m mod.example/com.example.demo.Main
Error occurred during initialization of VM
Failed setting boot class path.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Yeah, stripping the final image would corrupt the image. The linked launcher executable should be stripped first, then passed to jlink to create the final image. The `build-id` would be the same.</pre>
</blockquote>
<p>I tried commenting this on a commit, but I guess it is kind of
invisible there, so let me repeat it here, and expand on it.</p>
<p>The current approach on just "tucking on" the jlink data at the
end of the binary surprises me. I've always just presumed that the
jimage part should be stored as an ELF section, so that the entire
binary is a complete, valid ELF file. I assume that if the jlink
data was stored as a proper ELF section, the binary would not be
destroyed by strip.<br>
</p>
<p>It also surprises me that this approach even works. Is appending
arbitrary stuff at the end of the file explicitly allowed by the
ELF spec? Or is this solution dependent on ELF loaders being not
so strict? If so, it can break with any future update to the
dynamic loader...</p>
<p>/Magnus<br>
</p>
</body>
</html>