<div dir="ltr"><div>For reproducible Temurin Windows builds, we specify our MS VS version in our SBOM, basically as soon as you use a slightly different VS compiler, the native PE code is different... which I think is as expected really.</div><div>For our Linux builds of OpenJDK we use what's termed a "DevKit", which is a specific version level of the gcc compiler, a "user" can independently re-create the DevKit Toolchain from source "identically", and then use that to identically build OpenJDK. Ref: <a href="https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk/master/doc/building.html#cross-compiling-the-easy-way">https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk/master/doc/building.html#cross-compiling-the-easy-way</a></div><div><br> </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 2, 2024 at 7:34 AM Chris Lamb <<a href="mailto:chris@reproducible-builds.org">chris@reproducible-builds.org</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">Danilo wrote:<br>
<br>
> One aspect that I cannot get rid of is the embedded toolchain <br>
> information, as well as differing behavior between toolchain versions. <br>
[…]<br>
> From what I could gather, there is no way to really solve this issue. <br>
> The approach that we currently plan to implement is to simply declare <br>
> the toolchain version we used, and let the user deal with the effort to <br>
> get it installed.<br>
<br>
I can't solve your specific problem with the embedded MSVC versions,<br>
but your alternative plan to simply declare the version out-of-band is<br>
the general approach taken in most non-Windows environments. As in,<br>
you would not be doing anything dramatically different from other<br>
platforms.<br>
<br>
The claim that "X is reproducible" carries an implicit "given the same<br>
build environment". Most projects declare the toolchain versions by<br>
recording the build environment programmatically and distributing that<br>
info in some way: see [0] for some concrete examples.<br>
<br>
For instance, Debian tooling generates a .buildinfo file that<br>
includes the build dependencies along with the versions used. Users<br>
must indeed "deal with the effort" to match that if they want to<br>
reproduce the package.<br>
<br>
However, the scriptable packaging tools for Debian and friends make it<br>
relatively straightforward (in theory!!) to programmatically install a<br>
whole bunch of dependencies with specific versions. That might not be<br>
the case under Windows and with VC components.<br>
<br>
Intriguingly, the way you couch your "alternative" solution with some<br>
hesitation might suggest asking users to install a specific version<br>
goes against the social norms for that technical platform/community.<br>
I'd be interested to learn about that, as its the kind of "we don't<br>
tend to do that.." thing that does not end up in technical<br>
documentation. :)<br>
<br>
<br>
  [0] <a href="https://reproducible-builds.org/docs/recording/" rel="noreferrer" target="_blank">https://reproducible-builds.org/docs/recording/</a><br>
<br>
<br>
Best wishes,<br>
<br>
-- <br>
      o<br>
    ⬋   ⬊      Chris Lamb<br>
   o     o     <a href="http://reproducible-builds.org" rel="noreferrer" target="_blank">reproducible-builds.org</a> 💠<br>
    ⬊   ⬋<br>
      o<br>
<br>
<br>
</blockquote></div>