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 >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >
