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
