Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Install VS2017 on all build machines #448

Closed
sxa opened this issue Sep 3, 2018 · 20 comments
Closed

Install VS2017 on all build machines #448

sxa opened this issue Sep 3, 2018 · 20 comments

Comments

@sxa
Copy link
Member

sxa commented Sep 3, 2018

Oracle are switching to supporting VS2017 builds, so we should too:
Ref: https://bugs.openjdk.java.net/browse/JDK-8201267 and eclipse-openj9/openj9#1697

@johanvos
Copy link
Contributor

johanvos commented Sep 3, 2018

Note that there is a compiler bug in recent versions of VS2017 that prevents JavaFX (at least webkit) from being built for now: https://bugs.openjdk.java.net/browse/JDK-8210218
(this should not block you, as we're not even close to have an Ansible setup for JavaFX on windows)

@sxa
Copy link
Member Author

sxa commented Sep 4, 2018

That's ok - this shouldn't result in earlier versions being removed - it would be an addition for now. But thanks for that info - useful to be aware of it.

@sxa
Copy link
Member Author

sxa commented Sep 4, 2018

I've heard from a colleague on the infrastructure call today that there may be some conflicts installing VS2017 on machines that have the earlier versions so we're going to do some investigation before pushing this forward

@jdekonin
Copy link
Contributor

jdekonin commented Sep 4, 2018

The conflicts as I found our are related to the version of mingw installed on the machine. OpenJ9 only compiles with specific versions in when VS2017 is used.

#422 was the commit for VS2017 required changes, but there is no mention of version of mingw that should be used. That can be inferred through the openj9 build instructions here in the Windows section :
https://github.com/eclipse/openj9/blob/master/buildenv/Build_Instructions_V11.md#windows

I am not sure if the mingw v8.1 tooling will work alongside older VS installs. I have a student working on the addition to the playbook which should be coming in the next few days.

@johanvos
Copy link
Contributor

johanvos commented Sep 4, 2018

The problems we have occur exactly when there are 2 versions installed, and different environment variables point to conflicting versions. Hopefully you won't run into it, but it caused lots of headaches :)

@sxa
Copy link
Member Author

sxa commented Sep 4, 2018

Hopefully you won't run into it

Do you have reason to believe we won't see the same problems as you did @johanvos? We are planning to have them both installed on our machines so we need to know this will have no risk of destabilising our use of either version.

@jdekonin
Copy link
Contributor

jdekonin commented Sep 5, 2018

@vsebe has VS2010, VS2013, and VS2017 installed on each of the 4 Windows 2012 Server machines on the OpenJ9 jenkins.

There are further changes required (mingw 8.1) as detail in the url above that I believe @vsebe is working on for adding to the playbook. Currently there is a defect open against OMR for compilation failure within DDR; eclipse-omr/omr#2885

@jdekonin
Copy link
Contributor

jdekonin commented Sep 6, 2018

#479

@sxa
Copy link
Member Author

sxa commented Sep 10, 2018

@johanvos Can you please clarify your "Hopefully you won't run into it" assertion and would like to understand why you believe that to be the case. Has @vsebe seen any of them?
@jdekonin Do you know if that OMR issue related specifically to VS2017 or MinGW?

@jdekonin
Copy link
Contributor

Its a hard fail with VS2017, VS2013 still compiles fine. OpenJ9 won't be moving to VS2017 until this defect is resolved and there is a clean compile.

@vsebe
Copy link
Contributor

vsebe commented Sep 10, 2018

Please note there are two versions of MinGW:

  • the cygwin packages (gcc 5.4 or newer but less than 8.1) required to build OpenJ9 extensions for OpenJDK8 & OpenJDK10 - using VS 2010, 2013 toolchains
  • MinGW-W64 v5 (gcc 8.1.0) required to build OpenJ9 extensions for OpenJDK11 (for now) with VS2017 toolchain. MinGW-W64 is installed in different location (see WIP: Install MinGW-W64 on Windows #479) than the cygwin package and has to be added first to the PATH.

@sxa
Copy link
Member Author

sxa commented Sep 14, 2018

@vsebe So if we're going to move to VS2017 everywhere for OpenJ9 then the version installed in PR479 should be adequate - is that correct? I'll aim to get one of our build machines in a suitable state for this.

@sxa
Copy link
Member Author

sxa commented Sep 14, 2018

https://ci.adoptopenjdk.net/label/windows&&x64&&buildj9/ are the current J9 build machines - I'll start putting the newer versions on https://ci.adoptopenjdk.net/computer/build-softlayer-win2012r2-x64-2/ (37.58.103.196)

@vsebe
Copy link
Contributor

vsebe commented Sep 14, 2018

@sxa555 - yes, the MinGW from PR#479 is adequate.

@sxa
Copy link
Member Author

sxa commented Sep 14, 2018

@vsebe Is the install location specified in that PR - C:\mingw-w64\x86_64-8.1.0-win32-seh-rt_v6-rev0 - the one that the OpenJ9 build process will look for explicitly or does the bin directory in there need to be added to the PATH somewhere as a separate step?

@sxa
Copy link
Member Author

sxa commented Sep 14, 2018

Going to remove the buildj9 tag from https://ci.adoptopenjdk.net/computer/build-softlayer-win2012r2-x64-1/ for now to force all OpenJ9 builds onto the new -2 machine.

(This will probably temporarily lock out our ability to run Win32 OpenJ9 builds)

@vsebe
Copy link
Contributor

vsebe commented Sep 14, 2018

@sxa555 - fyi the OpenJ9 is investigating using Clang instead of mingw on Windows(eclipse-openj9/openj9#2469 (comment))

@sxa
Copy link
Member Author

sxa commented Sep 14, 2018

Bumping to next milestone - installed and tested on one machine so solves the immediate need.

@mwornast
Copy link
Contributor

To set expectations this is not going to be solved this Month. I am about to go on leave. Realistic timeline is mid October.

@sej-jackson Maybe you want to pick this up.

@sxa sxa removed this from the 2018 September B milestone Oct 1, 2018
@sxa sxa added this to the 2019 March milestone Mar 7, 2019
@karianna karianna modified the milestones: 2019 March, 2019 April Apr 1, 2019
@karianna karianna modified the milestones: 2019 April, 2019 May May 2, 2019
@karianna karianna modified the milestones: 2019 May, 2019 June Jun 3, 2019
@sxa sxa modified the milestones: 2019 June, July 2019 Jul 2, 2019
@karianna karianna modified the milestones: July 2019, August 2019 Aug 6, 2019
@karianna karianna modified the milestones: August 2019, September 2019 Sep 2, 2019
@karianna karianna modified the milestones: September 2019, October 2019 Oct 4, 2019
@sxa sxa modified the milestones: October 2019, November 2019 Oct 28, 2019
@sxa sxa modified the milestones: November 2019, December 2019 Nov 29, 2019
@sxa sxa modified the milestones: December 2019, January 2020 Dec 31, 2019
@karianna karianna modified the milestones: January 2020, February 2020 Feb 3, 2020
@sxa sxa modified the milestones: February 2020, Icebox / On Hold Feb 25, 2020
@gdams
Copy link
Member

gdams commented Apr 6, 2020

@sxa555 assume this can be closed? VS2017 is in the playbook and installed on all build machines

@sxa sxa closed this as completed Apr 6, 2020
@karianna karianna modified the milestones: Icebox / On Hold, April 2020 Apr 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants