bash configure fails on missing VS tools dir

[Nir Lisker]

Great. I don't think I can Watch or comment on the JIRA issue because I
don't have an account, and also I'm not registered on build-dev mailing
list, so if some system or build/configure info is needed I can be
contacted in this email.

- Nir

On Thu, Jan 4, 2018 at 6:09 PM, Erik Joelsson <erik.joelsson at oracle.com>
wrote:

> Thanks! I've filed https://bugs.openjdk.java.net/browse/JDK-8194645
>
> /Erik
>
> On 2018-01-04 16:30, Nir Lisker wrote:
>
> 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.joelsson at 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.joelsson at 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.joelsson at 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.joelsson at 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.joelsson at 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.joelsson at 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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>