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.joels...@oracle.com <mailto:erik.joels...@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 <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.joels...@oracle.com <mailto:erik.joels...@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.joels...@oracle.com <mailto: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
<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
