Investigate changing jdk8u to build with VS2019 for Windows for July 2022 PSU

[karianna]

Upstream change has been merged into jdk8u-dev

[sxa]

Looks like #2967 has bumped it to VS2017. We should also consider the implications for the 32-bit JDK8 builds which I understand do not work with VS2017 based on a discussion in this week's PMC call (Although later java versions seem ok)

[sxa]

@karianna This has not been implemented. Slightly worryingly the 64-bit JDK8 build logs currently show this:

19:08:02  Tools summary:
19:08:02  * Environment:    cygwin version 3.1.7(0.340/5/3) (root at /cygdrive/c/cygwin64)
19:08:02  * Boot JDK:       openjdk version "1.7.0_75"  OpenJDK Runtime Environment (build 1.7.0_75-b13)  OpenJDK Client VM (build 24.75-b04, mixed mode)   (at /cygdrive/c/openjdk/jdk-7)
19:08:02  * Toolchain:      microsoft (Microsoft Visual Studio 2017 - CURRENTLY NOT WORKING)
19:08:02  * C Compiler:     Version 19.16.27043 (at /cygdrive/c/progra~2/mib055~1/2017/commun~1/vc/tools/msvc/1416~1.270/bin/hostx86/x64/cl)
19:08:02  * C++ Compiler:   Version 19.16.27043 (at /cygdrive/c/progra~2/mib055~1/2017/commun~1/vc/tools/msvc/1416~1.270/bin/hostx86/x64/cl)

Are you concerned about this build not using 2019 or the "CURRENTLY NOT WORKING" message?

32-bit JDK8 is still on VS2013:

19:09:38  Tools summary:
19:09:38  * Environment:    cygwin version 3.1.4(0.340/5/3) (root at /cygdrive/c/cygwin64)
19:09:38  * Boot JDK:       openjdk version "1.7.0_75"  OpenJDK Runtime Environment (build 1.7.0_75-b13)  OpenJDK Client VM (build 24.75-b04, mixed mode)   (at /cygdrive/c/openjdk/jdk7)
19:09:38  * Toolchain:      microsoft (Microsoft Visual Studio 2013)
19:09:38  * C Compiler:     Version 18.00.40629 (at /cygdrive/c/progra~2/micros~1.0/vc/bin/cl)
19:09:38  * C++ Compiler:   Version 18.00.40629 (at /cygdrive/c/progra~2/micros~1.0/vc/bin/cl)

[gdams]

Not sure if it's compatible yet. I did a test build here that failed https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-windows-x64-temurin/119/

[sxa]

My preference would very much be not to change it at this stage of the process - I mostly highlighted it just so that people didn't think it had happened.

[karianna]

Fair, good spot on x32

[sxa]

A few experiments:

• JDK8/win64 with VS2019: ✅
• JDK11/win32 with VS2019: Lots of Compiler intrinsic is defined for method [java.lang.Object.<init>()V], but the method is not annotated with @HotSpotIntrinsicCandidate. Method will not be inlined.
• JDK8/win32 with VS2019 ✅
• JDK8/win64 with VS2022 ✅
• JDK17/win64 with VS2022 (and no urct dll override) ✅
• JDK11/win64 with VS2019 ✅
• JDK8/win32 with VS2022 ✅
• JDK11/win64 with VS2022 ✅
• JDK11/win32 with VS2022 ✅

[sxa]

Noting that with the latest Visual Studio Community edition (The one installed by default with out playbooks unless our VS2022 layout is available) the build for jdk8u does not succeed:

Log snippet from JDK8u with VS Community compiler 14.40.33807

Note: Some of these lines are truncated:

Generating Code...
        C:\progra~1\micros~1\2022\commun~1\vc\tools\msvc\1440~1.338\bin\hostx86\x64\cl.exe    /nologo /W3 /WX /wd4800 /Zi /D "_LP64" /D "AMD64" /D "WIN32" /D
cl : Command line warning D9035 : option 'GX' has been deprecated and will be removed in a future release
cl : Command line warning D9036 : use 'EHsc' instead of 'GX'
opcodes.cpp
        C:\progra~1\micros~1\2022\commun~1\vc\tools\msvc\1440~1.338\bin\hostx86\x64\link.exe  kernel32.lib user32.lib gdi32.lib winspool.lib  comdlg32.lib ad
        C:\progra~2\window~1\10\bin\100226~1.0\x86\mt.exe /manifest adlc.exe.manifest /outputresource:adlc.exe;#1
NMAKE : Microsoft (R) Manifest Tool
Copyright (c) Microsoft Corporation. 
All rights reserved.

adlc.exe.manifest : general error c1010070: Failed to load and parse the manifest. The system cannot find the file specified.
fatal error U1077: 'C:\progra~2\window~1\10\bin\100226~1.0\x86\mt.exe /manifest adlc.exe.manifest /outputresource:adlc.exe;#1' : return code '0x1f'
Stop.
NMAKE : fatal error U1077: 'cd generated && C:\PROGRA~1\MICROS~1\2022\COMMUN~1\VC\Tools\MSVC\14.40.33807\bin\HostX86\x64\nmake.EXE -NOLOGO -f C:\workspace\te
Stop.
NMAKE : fatal error U1077: 'nmake -nologo -f C:\workspace\temurin-build\build-farm\workspace\build\src\hotspot\make\windows\makefiles\top.make BUILD_FLAVOR=p
Stop.
make[3]: *** [Makefile:231: generic_build2] Error 2
make[2]: *** [Makefile:177: product] Error 2
make[1]: *** [HotspotWrapper.gmk:45: /cygdrive/c/workspace/temurin-build/build-farm/workspace/build/src/build/windows-x86_64-normal-server-release/hotspot/_h
make: *** [/cygdrive/c/workspace/temurin-build/build-farm/workspace/build/src//make/Main.gmk:110: hotspot-only] Error 2
OpenJDK make failed, archiving make failed logs

I would expect that if we move to a fixed version of the VS2022 build tools that this will not be an issue

[sxa]

Note on building jdk8u with VS2022 Build Tools: freetype does not build due to missing files in the current build tools install. We need to identify whether the appropriate modules can be added the build tools installer to provide the files that are required:

configure: Trying to compile freetype sources with PlatformToolset=v143 to /cygdrive/c/temurin-build/build-farm/workspace/libs/freetype/lib64/ ...
configure: User specified --with-freetype-src but building freetype failed. (see freetype.log for build results)
configure: error: Consider building freetype manually and using --with-freetype instead.
No configurations found for /cygdrive/c/temurin-build/build-farm/workspace/build/src/! Please run configure to create a configuration.
Makefile:55: *** Cannot continue.  Stop.
OpenJDK make failed, archiving make failed logs

The underlying freetype log has:
C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\MSBuild\Microsoft\VC\v170\Microsoft.Cpp.WindowsSDK.targets(46,5): error MSB8036: The Windows SDK version 10.0.17763.0 was not found. Install the required version of Windows SDK or change the SDK version in the project property pages or by right-clicking the solution and selecting "Retarget solution". [C:\temurin- build\build-farm\workspace\libs\freetype\builds\windows\vc2010\freetype.vcxproj]

The directory path down to v170 exists, but not the Microsoft.Cpp.WindowsSDK.targets directory under that.

(EDIT: This can be fixed by avoiding calling the freetype patch function in our build scripts, which is only required for earlier visual studio versions)