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