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