bash configure fails on missing VS tools dir
Erik Joelsson
erik.joelsson at oracle.com
Thu Jan 4 16:09:09 UTC 2018
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 <mailto: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 <mailto: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.ba <http://vcvars32.ba>t"
>>> 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
>>> <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
>> <https://msdn.microsoft.com/en-us/library/hs24szh9%28v=vs.120%29.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 <mailto: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
>>>> <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
>>>> <mailto: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
>>>>> <mailto: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
>>>>>> <mailto: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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
More information about the build-dev
mailing list