<div dir="ltr">Thanks for the quick and useful response!<div><br></div><div>It was indeed the stripping of native debug symbols that was the cause (due to different versions of objcopy on the build machines). I would suggest those creating reproducible builds use only --strip-java-debug-attributes, which (as I understand it) should be platform-independent.</div><div><br></div><div>Craig</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 5, 2022 at 12:55 PM Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com">Alan.Bateman@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 05/08/2022 11:18, Craig Raw wrote:<br>
> I am having an issue concerning the reproducibility of the JVM <br>
> libraries produced by JLink. When running the same build script across <br>
> different machines with the same JDK, sometimes the binaries and libs <br>
> in the lib/runtime/bin and lib/runtime/lib folders are different. If <br>
> one of the *.so files is different, they all are. However, the <br>
> lib/runtime/lib/modules file produced by JLink is consistently <br>
> identical. The machines running the builds are all Linux running <br>
> flavours of Ubuntu.<br>
><br>
> On examining the issue more closely, I notice that sometimes the files <br>
> are identical to the ones in the JDK installation, and sometimes they <br>
> are not. They are not significantly different, for example:<br>
> JDK:<br>
> -rw-rw-r-- 1 xxx xxx  16560 Aug  4 18:08 libjsig.so<br>
><br>
> JLink:<br>
> -rw-rw-r-- 1 xxx xxx  17136 Aug  4 19:23 libjsig.so<br>
><br>
> Further, I've tried running the java binaries in each, and they differ <br>
> in that one is 'sharing' and the other not:<br>
><br>
> xxx@yyy:~$ ~/.sdkman/candidates/java/18.0.1-tem/bin/java --version<br>
> openjdk 18.0.1 2022-04-19<br>
> OpenJDK Runtime Environment Temurin-18.0.1+10 (build 18.0.1+10)<br>
> OpenJDK 64-Bit Server VM Temurin-18.0.1+10 (build 18.0.1+10, mixed <br>
> mode, sharing)<br>
><br>
> xxx@yyy:~$ ~/project/build/image/bin/java --version<br>
> openjdk 18.0.1 2022-04-19<br>
> OpenJDK Runtime Environment Temurin-18.0.1+10 (build 18.0.1+10)<br>
> OpenJDK 64-Bit Server VM Temurin-18.0.1+10 (build 18.0.1+10, mixed mode)<br>
><br>
> What would cause JLink to modify the JVM itself? Is there a way I can <br>
> achieve a consistently reproducible JVM image?<br>
><br>
<br>
I assume the jlink command used to generate project/build/image doesn't <br>
specify --generate-cds-archive so that will explain why you don't see <br>
"sharing" in the java -version output. You can use <br>
project/build/image/bin/java -Xshare:dump to do the generate it too.<br>
<br>
For the .so file it is possible that your jlink command specifies <br>
-strip-debug or --strip-native-debug-symbols? That might explain why the <br>
sizes are different to the initial image. The stripping of debug symbols <br>
from shared objects runs the objcopy command. Off-hand I don't know if <br>
this is reproducible but maybe there are different versions on the <br>
Ubuntu systems? If you aren't stripping debug symbols then another <br>
possibility is that that the package modules (jmod files) used on the <br>
different versions are identical - this is something you can quickly check.<br>
<br>
-Alan.<br>
<br>
<br>
<br>
</blockquote></div>