Yeah, make also completed successfully: Finished building target 'default (exploded-image)' in configuration 'windows-x86_64-normal-server-release'
This is what I did in toolchain_windows.m4: if test "x$OPENJDK_TARGET_CPU_BITS" = x32; then VCVARSFILE="vc/bin/vcvars32.bat" else # VCVARSFILE="vc/bin/amd64/vcvars64.bat" VCVARSFILE="vc/bin/x86_amd64/vcvarsx86_amd64.bat" fi If you need any extra info I can update. - Nir On Thu, Jan 4, 2018 at 5:23 PM, Erik Joelsson <erik.joels...@oracle.com> wrote: > If this works for you, we should update configure to look for both. > > /Erik > > On 2018-01-04 14:51, Nir Lisker wrote: > > It seems to have accepted vcvarsx86_amd64.bat quietly. Configure > succeeded: > > Tools summary: > * Environment: cygwin version 2.9.0(0.318/5/3) (root at > /cygdrive/c/cygwin64) > * Boot JDK: java version "9" Java(TM) SE Runtime Environment (build > 9+181) Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode) (at > /cygdrive/c/progra~1/java/jdk-9) > * Toolchain: microsoft (Microsoft Visual Studio 2013) > * C Compiler: Version 18.00.31101 (at /cygdrive/c/progra~2/micros~1. > 0/vc/bin/x86_am~1/cl) > * C++ Compiler: Version 18.00.31101 (at /cygdrive/c/progra~2/micros~1. > 0/vc/bin/x86_am~1/cl) > > Hopefully all this would be helpful to someone in the future. > > On with the rest of the steps... > > Thanks, > Nir > > On Thu, Jan 4, 2018 at 2:36 PM, Erik Joelsson <erik.joels...@oracle.com> > wrote: > >> >> On 2018-01-04 12:45, Nir Lisker wrote: >> >> Yes, that did it, autegen.sh completed successfully. Thanks. >> >> Now the next problem with "bash configure": >> configure: error: Target CPU mismatch. We are building for x86_64 but CL >> is for "x86"; expected "x64". >> >> If that's the cl.exe which is in the same folder as vcvars, I noticed >> that in toolchain_windows.m4 that the script can try to find vcvars64.bat: >> >> if test "x$OPENJDK_TARGET_CPU_BITS" = x32; then >> VCVARSFILE="vc/bin/vcvars32.bat" >> else >> VCVARSFILE="vc/bin/amd64/vcvars64.bat" >> fi >> >> But this file doesn't exist in the VS 12.0 or 11.0 installations. The >> change I made to the above in order to solve the "missing" VC/bin dir was >> to force using "vc/bin/vcvars32.bat" (because /amd64 doesn't exist), which >> I guess was not smart and caused the above error. >> Here is the list of all vcvars in the VS installations: >> https://i.imgur.com/QtlePFq.png >> >> Note that VS 2017 has vcvars64.bat. Maybe vcvarsx86_amd64.bat in VS 2013 >> is fine? >> >> By the way, would building JDK 10 be any different in terms of >> compatibility? I already built OpenJFX 11 and I only need the JDK for that >> purpose. If JDK 10 can work here and is easier to build I'm fine with that. >> >> >> It seems the Visual Studio Express edition did not include the native >> 64bit compiler: >> https://msdn.microsoft.com/en-us/library/hs24szh9(v=vs.120).aspx >> >> When we updated to VS 2013 in JDK 9, we used the professional edition >> internally, which comes with the 64bit native compiler. For OpenJDK, we >> were still able to build 32bit with the express edition so we were fine >> with that. In JDK 10 and 11 32bit is not as well supported. >> >> The vcvarsx86_amd64.bat seems to be a 32bit to 64bit cross compilation >> toolchain. I would try that and see what happens. In theory it should work, >> but there may be a few more details to fix to get it all the way. >> >> /Erik >> >> >> On Thu, Jan 4, 2018 at 12:55 PM, Erik Joelsson <erik.joels...@oracle.com> >> wrote: >> >>> I think you also need the "Wrapper scripts for autoconf commands". Was a >>> long time since I did this. >>> >>> /Erik >>> >>> On 2018-01-04 11:40, Nir Lisker wrote: >>> >>> I get "-bash: autoconf: command not found". >>> >>> Here's an image of the autoconf packages in the cygwin installer in case >>> I didn't install the right one: https://i.imgur.com/V3GMg9Y.png >>> >>> Do I need to add some directory to the PATH env variable? I'd imagine >>> cygwin would know where it installed it. >>> >>> - Nir >>> >>> On Thu, Jan 4, 2018 at 10:29 AM, Erik Joelsson <erik.joels...@oracle.com >>> > wrote: >>> >>>> Can you run "autoconf --version" on the command line? >>>> >>>> /Erik >>>> >>>> On 2018-01-03 16:33, Nir Lisker wrote: >>>> >>>> Hello Erik, >>>> >>>> I installed autoconf 2.69-3 through cygwin (indeed it was listed as >>>> 2.5). However, running "bash autogen.sh" still gives: >>>> >>>> You need autoconf installed to be able to regenerate the configure >>>> script >>>> Error: Cannot find autoconf >>>> >>>> If I run "bash configure" I get >>>> >>>> Configure source code has been updated, checking time stamps >>>> Running generated-configure.sh >>>> >>>> And that's it. I checked generated-configure.sh and it contains only >>>> comments and no script. >>>> >>>> In autogen.sh I tried adding a print to help with debugging: >>>> >>>> AUTOCONF="`which autoconf 2> /dev/null | grep -v '^no autoconf in'`" >>>> echo "AUTOCONF is ${AUTOCONF}" >>>> >>>> which prints >>>> >>>> AUTOCONF is >>>> >>>> Apologies for the mess. How do I continue? >>>> >>>> - Nir >>>> >>>> On Wed, Jan 3, 2018 at 4:54 PM, Erik Joelsson <erik.joels...@oracle.com >>>> > wrote: >>>> >>>>> Hello Nir, >>>>> On 2018-01-03 15:34, Nir Lisker wrote: >>>>> >>>>> Thanks for the detailed reply. >>>>> >>>>> Iv'e changed the logic in toolchain_windows.m4 and got this message: >>>>> >>>>> Configure source code has been updated, checking time stamps >>>>> Warning: The configure source files is newer than the generated files. >>>>> Cannot locate autoconf, unable to correct situation. >>>>> Please install autoconf and run 'bash autogen.sh' to update the >>>>> generated files. >>>>> Error: Cannot continue >>>>> >>>>> I downloaded autoconf 2.69. How do I point to it? There is no >>>>> installation. >>>>> >>>>> If you downloaded the src distro, then you need to compile and install >>>>> it with something like >>>>> >>>>> $ ./configure >>>>> $ make >>>>> $ make install >>>>> >>>>> On Windows it's probably easier to just get it through cygwin. Note >>>>> that the cygwin installer probably still lists autoconf as an old version >>>>> in the name, but last I checked it was 2.69 that they actually provided. >>>>> On >>>>> Linux, just use your favorite package installation tool (apt, yum etc). >>>>> >>>>> As long as it's on the path, autogen.sh will pick it up. Configure >>>>> will also detect that you changed an .m4 file and run autogen.sh for you >>>>> automatically, which is what happened to you above. >>>>> >>>>> /Erik >>>>> >>>>> On Wed, Jan 3, 2018 at 3:24 PM, Erik Joelsson < >>>>> erik.joels...@oracle.com> wrote: >>>>> >>>>>> Hello Nir, >>>>>> >>>>>> On 2018-01-03 13:05, Nir Lisker wrote: >>>>>> >>>>>>> When trying to build JDK 11 on Windows 10 with VS Express 2013 >>>>>>> Update 4 (as >>>>>>> stated in the docs - the highest supported version) the build fails: >>>>>>> >>>>>> AFAIK, this should work, though I have only ever used VS 2013 >>>>>> Professional. >>>>>> >>>>>>> bash configure --with-tools-dir='C:\Program Files (x86)\Microsoft >>>>>>> Visual >>>>>>> Studio 12.0\VC\bin' >>>>>>> >>>>>> If VS is properly installed in the default location, there should be >>>>>> no need to specify --with-tools-dir. Configure will look in the default >>>>>> location automatically. >>>>>> >>>>>>> ... >>>>>>> configure: Found Visual Studio installation at /cygdrive/c/Program >>>>>>> Files >>>>>>> (x86)/Microsoft Visual Studio 12.0/ using --with-tools-dir >>>>>>> configure: Warning: vc/bin/amd64/vcvars64.bat is missing, this is >>>>>>> probably >>>>>>> Visual Studio Express. Ignoring >>>>>>> configure: Found Visual Studio installation at /cygdrive/c/Program >>>>>>> Files >>>>>>> (x86)/ using --with-tools-dir >>>>>>> configure: Warning: vc/bin/amd64/vcvars64.bat is missing, this is >>>>>>> probably >>>>>>> Visual Studio Express. Ignoring >>>>>>> configure: The path given by --with-tools-dir does not contain a >>>>>>> valid >>>>>>> configure: Visual Studio installation. Please point to the VC/bin or >>>>>>> VC/bin/amd64 >>>>>>> configure: directory within the Visual Studio installation >>>>>>> configure: error: Cannot locate a valid Visual Studio installation >>>>>>> configure exiting with result code 1 >>>>>>> >>>>>>> /Microsoft Visual Studio 12.0/VC/bin/ does not contain an /amd64 >>>>>>> folder, >>>>>>> instead it has /x86_amd64. Also, vcvars64.bat is located directly >>>>>>> under >>>>>>> /VC/bin. >>>>>>> >>>>>> This is strange. Looking at the configure source, we assume that the >>>>>> VS installation should contain "vc/bin/amd64/vcvars64.bat". If that file >>>>>> isn't found, configure doesn't recognize the VS installation. >>>>>> Unfortunately >>>>>> I don't have an Express installation to look at, but my old professional >>>>>> installation has that file. In VC/bin I only have vcvars32.bat. >>>>>> >>>>>> I'm pretty sure this layout was how the express edition used to look >>>>>> as well. Otherwise Magnus wouldn't have written the build doc claiming it >>>>>> would work. >>>>>> >>>>>> This means the file layout for Visual Studio 2013 has changed, or >>>>>> that it's different on Windows 10 (our builds are on older versions of >>>>>> Windows still). >>>>>> >>>>>> If you would like to try to fix this, the logic that needs updating >>>>>> is in make/autoconf/toolchain_windows.m4, in the macro >>>>>> TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT. >>>>>> >>>>>>> Iv'e made another attempt using /Microsoft Visual Studio >>>>>>> 11.0/VC/bin/ which >>>>>>> resulted in the same error. This folder also has vcvars64.bat >>>>>>> directly >>>>>>> under it. It also contains an /amd64 folder with a couple of dlls >>>>>>> inside. >>>>>>> >>>>>>> Since I'm specifying the path to the /VC/bin dir I don't understand >>>>>>> why >>>>>>> it's still complaining. What am I doing wrong? >>>>>>> >>>>>> Because of how different the versions of Visual Studio are, configure >>>>>> will not automatically assume or try a different version than the default >>>>>> without being told to. If you want to try 2012, you need to tell >>>>>> configure >>>>>> using --with-toolchain-version=2012. No need to specify tools dir as long >>>>>> as it's installed in the default location. >>>>>> >>>>>>> On a related note, is it possible to update the build requirements >>>>>>> to work >>>>>>> with VS 2017? OpenJFX already uses this version. >>>>>>> >>>>>> This will likely happen in JDK 11 time frame. Note though that >>>>>> changing compilers is usually a pretty big effort so it will take a >>>>>> while. >>>>>> >>>>>> /Erik >>>>>> >>>>>>> - Nir >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >