OpenJ9 windows 64-bit JDK8 builds not working

[sxa]

 Assembling: xcinterp.asm
Microsoft (R) Library Manager Version 10.00.30319.01
Copyright (C) Microsoft Corporation.  All rights reserved.

   Creating library ../lib/j9vm.lib and object ../lib/j9vm.exp
../makelib/targets.mk:474: UMA_SINGLE_REBASE specified, suppressing per-directory rebase.
BytecodeInterpreter.obj : error LNK2019: unresolved external symbol __imp___acrt_iob_func referenced in function _ZN22VM_BytecodeInterpreter3runEP10J9VMThread
DebugBytecodeInterpreter.obj : error LNK2001: unresolved external symbol __imp___acrt_iob_func
MHInterpreter.obj : error LNK2001: unresolved external symbol __imp___acrt_iob_func
../j9vm29.dll : fatal error LNK1120: 1 unresolved externals
make[3]: *** [../makelib/targets.mk:473: ../j9vm29.dll] Error 96
make[2]: *** [makefile:146: j9vm] Error 2
make[1]: *** [/cygdrive/c/cygwin64/tmp/tmp.TXWuvndLsd/workspace/build/src/closed/OpenJ9.gmk:401: build-j9] Error 2
make: *** [/tmp/tmp.TXWuvndLsd/workspace/build/src/closed/make/Main.gmk:31: j9vm-build] Error 2
Relocating workspace from /tmp/tmp.TXWuvndLsd to /cygdrive/c/Users/jenkins/workspace/build-scripts/jobs/jdk8u/jdk8u-windows-x64-openj9/workspace
Data at: /cygdrive/c/Users/jenkins/workspace/build-scripts/jobs/jdk8u/jdk8u-windows-x64-openj9/workspace

[sxa]

Possibly due to the wrong version of mingw being used. Adding mingw-cygwin and mingw-standalone tags to the appropriate machines since OpenJ9 needs a different one for 11, and everything before 11

[sxa]

Ref: https://github.com/AdoptOpenJDK/openjdk-build/pull/622

[sxa]

Also needs --skip-freetype for the freetype include/lib options to take effect. But then I still get this:

Windows or Windows-like environment detected, skipping downloading of dependencies...: Alsa.
Skipping Freetype
Checking and download CaCerts dependency
Retrieving cacerts file
Requested use of JEP319 certs
[Pipeline] }
[Pipeline] // node
[Pipeline] }
[Pipeline] // stage
[Pipeline] echo
Execution error: script returned exit code 127
[Pipeline] End of Pipeline
Finished: FAILURE

https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-windows-x64-openj9/67/console

[sxa]

Issue is caused by the curl command on the windows machines always returning with rc=127 for some reason. Switching to using wget under https://github.com/AdoptOpenJDK/openjdk-build/pull/626

[AdamBrousseau]

The test scripts use curl as well. Cc @smlambert

[sxa]

Windows builds were failing and (although the description of the problem isn't the underlying problem) should be fixed under https://github.com/eclipse/openj9/issues/3204.

Now still failing seemingly unable to find ClassCache.java although it appears to be in the correct location on the machine's workspace (Not the /tmp location which it is built live in though)

FYI @johnoliver Can you identify why these builds are unable to find the ClassCache.java? It appears to build successfully at the openj9 CI

https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-windows-x64-openj9/ https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-windows-x86-32-openj9/

https://ci.eclipse.org/openj9/job/Build-JDK8-win_x86-64_cmprssptrs/ https://ci.eclipse.org/openj9/job/Build-JDK8-win_x86/

[sxa]

(Currently blocking any testing of https://github.com/AdoptOpenJDK/openjdk-infrastructure/issues/526)

[sxa]

Have attempted to build with the old windows script at https://ci.adoptopenjdk.net/job/openjdk8_openj9_build_x86-64_windows/180/console

[sxa]

^^^ This is from the tmp directory being used by https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-windows-x64-openj9/85/console and shows that the file is present

[andrew-m-leonard]

@johnoliver The configure automatically gets the --with-add-source-root=$full_src_root_dir/closed/adds added during configure time... The $full_src_root_dir will be /tmp/tmp.... by the looks of things, and it looks as though no fixpath gets applied to that to prepend /cygwin/... hence javac can't find the source...

[andrew-m-leonard]

As a comparison a win64 build of ours:

13:28:06 checking cygwin root directory as unix-style path... /cygdrive/c/cygwin64
13:28:07 checking what kind of 'find' is first on the PATH... unix style
13:28:07 checking for top-level directory... /cygdrive/c/Users/j9build/jenkins/workspace/Build-JDK8-win_x86-64_cmprssptrs

whereas the Adopt log:

checking cygwin root directory as unix-style path... /cygdrive/c/cygwin64
checking what kind of 'find' is first on the PATH... unix style
checking for top-level directory... /tmp/tmp.EJzLQjJCJq/workspace/build/src
configure: Rewriting CURDIR to "/cygdrive/c/cygwin64/tmp/tmp.EJzLQjJCJq/workspace/build/src"
configure: Rewriting TOPDIR to "/cygdrive/c/cygwin64/tmp/tmp.EJzLQjJCJq/workspace/build/src"

So top-level directory on our build is a cgydrive path, but not in the Adopt build....?

[andrew-m-leonard]

This maybe an issue too:

--with-cacerts-file=/tmp/tmp.EJzLQjJCJq/workspace/./build//cacerts_area/security/cacerts

[johnoliver]

Hopefully #635 should fix it, a test on https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-windows-x86-32-openj9/27/ seemed to go fine. Been tidied up a bit since that build but I think should work

[sxa]

Nothing seems broken at the moment so this has presumably been fixed. Also we've switched the compiler from mingw to clang/LLVM so the original problem has almost certainly been made irrelevant.