Looks like you are using a newer Visual Studio toolchain:
'C:\PROGRA~2\MICROS~1\2017\PROFES~1\VC\Tools\MSVC\14.16.27023\
See below:
On 07/11/19 12:35, Moshe Zuisman wrote:
now I pulled last source (used get_ssource.sh) and - same result:
[...snip...]
*Generating Code...sh
now I pulled last source (used get_ssource.sh) and - same result:
*Generating Code...sh
C:\openJdk8u_test\jdk8u\hotspot/make/windows/build_vm_def.sh
C:\progra~2\micros~1\2017\profes~1\vc\tools\msvc\1416~1.270\bin\hostx86\x64\link.exe
@C:\cygwin64\tmp\nmE8BD.tmp Creating
Sorry - it is b04
But if get you right - i will have to last commit...
$ hg log --rev $(hg id -i | sed 's/.$//')
changeset: 2369:d43cf567cf72
tag: jdk8u212-b04
user:andrew
date:Wed Apr 03 05:14:53 2019 +0100
summary: Added tag jdk8u212-b03 for changeset 5218ef8ea6c3
Hi, Christoph:
please review this little bugfix in Images.gmk.
Bug: https://bugs.openjdk.java.net/browse/JDK-8227578
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8227578.0/
I guess it's only relevant when building "legacy-bundles" or something that
builds jre-images. However in that
Hi Robert,
This means that the function is using the __stdcall calling convention. I
do not know whether this is correct or not, but caller and callee have to
agree on the calling convention used, so the prototype for that function
used when compiling the caller code must have been declared with
On 7/11/19 1:17 PM, Moshe Zuisman wrote:
> I am trying to build openjdk8u_b24 on windows cygwin environment.
What is "openjdk8u_b24"? What exactly are you trying to build? In other words,
where did you get the
source, and what is the latest change in the source tree? There are many
improvements
Hi. I am trrting to build openjdk8u_b24 on windows cygwin environment.
Get fololowing error:
_
*
C:\progra~2\micros~1\2017\profes~1\vc\tools\msvc\1416~1.270\bin\hostx86\x64\cl.exe
/nologo /W3 /WX /Zi /D "_LP64" /D
Hi,
please review this little bugfix in Images.gmk.
Bug: https://bugs.openjdk.java.net/browse/JDK-8227578
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8227578.0/
I guess it's only relevant when building "legacy-bundles" or something that
builds jre-images. However in that case we
I have tried to use the jpackage EA version in combination with the
win32-build of Java 12 from AdoptOpenJDK.
I was able to build the jpackage EA from the sandbox and built an image
from the win32 Java 12 build, which then was successfully combined using
jpackage's --runtime-image option. (BTW
