RFR: 8281262: Windows builds in different directories are not fully reproducible

[Erik Joelsson]

On Fri, 4 Feb 2022 10:55:40 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

> Some dll/exe files end up having absolute path names embedded in them despite the use of `--disable-absolute-paths-in-output` build option. This option effectively translates into adding `-pathmap` to compilation lines, but doesn't (always) achieve the desired effects. The reason for that is in the use of Windows-style path for the argument provided to `pathmap`. The slash characters in the path passed as an argument get removed by the `fixpath` script that pre-processes all commands on Windows prior to running them and is supposed to convert Unix-style paths to what is understood by Windows.
> 
> For example:
> 
> $ build/windows-x86_64-server-release/fixpath print -pathmap:C:\cygwin64\home\maxim\work\repr.build.1=s
> -pathmap:C:cygwin64homemaximworkrepr.build.1=s
> 
> However, if a "normal" Unix-style path is provided, it gets converted correctly:
> 
> $ build/windows-x86_64-server-release/fixpath print -pathmap:/home/maxim/work/repr.build.1=s
> -pathmap:C:\cygwin64\home\maxim\work\repr.build.1=s 
> 
> 
> This commit changes the `-pathmap` compiler option to use "normal", Unix-style paths on Windows. Those will be changed to Windows style by the `fixpath` script. 
> 
> Verified by running two builds (details below) in different directories on the same machine; with this commit, all the exe/dll files under `.../images/jdk/...` are the same.
> 
> 
> Builds were produced by running the following commands on Windows 10 x64 with Visual Studio 2019 installed:
> 
>  ./configure --with-debug-level=release --with-jvm-features=shenandoahgc --with-version-pre= --with-version-build=1 --with-version-opt=b42 --with-toolchain-version=2019 --disable-ccache --enable-cds=yes --enable-reproducible-build --with-source-date=1643953637 --with-hotspot-build-time=2022-02-04 --with-copyright-year=2022 --disable-absolute-paths-in-output --with-boot-jdk=/home/maxim/work/zulu17.0.81-ea-jdk17.0.0-ea.35-win_x64
> make reconfigure clean
> make images

Thank you for finding this! We do have a test that is supposed to catch an issue like this, but unfortunately it seems that test is suffering a similar issue. It's not looking for the correct path strings as the backslashes have been truncated by one too many shell expansions on the way. I created a fix for the test in a branch here: 

https://github.com/erikj79/jdk/tree/JDK-8281262-abspath-windows

I've verified that your fix makes the test pass together with my fix. Something like this should go in with this fix. Feel free to take my change.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7344