Hi,
I tried out your changes locally, and with Yasumasa's change and the following
diff [1], I can confirm that this works on my setup (VS2019 devkit w/ Cygwin).
I'll give a spin with WSL1 and WSL2, as well as VS2017.
[1] Diff to fix support for VS2019
--- a/make/autoconf/toolchain_microsoft.m4
+++ b/make/autoconf/toolchain_microsoft.m4
@@ -628,9 +606,9 @@ AC_DEFUN([TOOLCHAIN_SETUP_VS_RUNTIME_DLLS],
fi
AC_ARG_WITH(vcruntime-1-dll, [AS_HELP_STRING([--with-vcruntime-1-dll],
[path to microsoft C++ runtime dll (vcruntime*_1.dll) (Windows x64 only)
@<:@probed@:>@])])
- if test "x$VCRUNTIME_1_NAME" != "x" && test "x$OPENJDK_TARGET_BITS" = x64;
then
+ if test "x$VCRUNTIME_1_NAME" != "x" && test "x$OPENJDK_TARGET_CPU_BITS" =
x64; then
if test "x$with_vcruntime_1_dll" != x; then
# If given explicitly by user, do not probe. If not present, fail
directly.
TOOLCHAIN_CHECK_POSSIBLE_MSVC_DLL($VCRUNTIME_1_NAME,
[$with_vcruntime_1_dll],
I also want to propose integrating the bits to support cross-compilation with
the microsoft toolchain as part of your change, even without adding the
targetting for Windows-AArch64. The following diff [2] integrates such support
for cross-compilation without adding Windows-AArch64:
[2] Diff to add support for cross-compilation
commit c23c78e33e57955d3f344383619592f34b84169b
Author: Ludovic Henry <[email protected]>
Date: Tue Jul 7 11:35:41 2020 -0700
8248498: Add build system support for Windows AArch64 (Part 1)
This adds support for cross-compilation on Windows, without adding the
AArch64 specific bits.
https://bugs.openjdk.java.net/browse/JDK-8248498
diff --git a/make/autoconf/basic.m4 b/make/autoconf/basic.m4
index 7248163242d..60b4097cba9 100644
--- a/make/autoconf/basic.m4
+++ b/make/autoconf/basic.m4
@@ -111,6 +111,16 @@ AC_DEFUN([BASIC_EVAL_DEVKIT_VARIABLE],
fi
])
+###############################################################################
+# Evaluates platform specific overrides for build devkit variables.
+# $1: Name of variable
+AC_DEFUN([BASIC_EVAL_BUILD_DEVKIT_VARIABLE],
+[
+ if test "x[$]$1" = x; then
+ eval $1="\${$1_${OPENJDK_BUILD_CPU}}"
+ fi
+])
+
###############################################################################
AC_DEFUN_ONCE([BASIC_SETUP_DEVKIT],
[
diff --git a/make/autoconf/flags-ldflags.m4 b/make/autoconf/flags-ldflags.m4
index a2a52f98ef7..8af9a20b5e8 100644
--- a/make/autoconf/flags-ldflags.m4
+++ b/make/autoconf/flags-ldflags.m4
@@ -164,15 +164,14 @@ AC_DEFUN([FLAGS_SETUP_LDFLAGS_CPU_DEP],
fi
elif test "x$TOOLCHAIN_TYPE" = xmicrosoft; then
- if test "x${OPENJDK_$1_CPU}" = "xx86"; then
- $1_CPU_LDFLAGS="-safeseh"
- # NOTE: Old build added -machine. Probably not needed.
- $1_CPU_LDFLAGS_JVM_ONLY="-machine:I386"
+ if test "x${OPENJDK_$1_CPU_BITS}" = "x32"; then
$1_CPU_EXECUTABLE_LDFLAGS="-stack:327680"
- else
- $1_CPU_LDFLAGS_JVM_ONLY="-machine:AMD64"
+ elif test "x${OPENJDK_$1_CPU_BITS}" = "x64"; then
$1_CPU_EXECUTABLE_LDFLAGS="-stack:1048576"
fi
+ if test "x${OPENJDK_$1_CPU}" = "xx86"; then
+ $1_CPU_LDFLAGS="-safeseh"
+ fi
fi
# JVM_VARIANT_PATH depends on if this is build or target...
diff --git a/make/autoconf/flags.m4 b/make/autoconf/flags.m4
index 694d41052ba..8cbf306ab0c 100644
--- a/make/autoconf/flags.m4
+++ b/make/autoconf/flags.m4
@@ -204,32 +204,36 @@ AC_DEFUN_ONCE([FLAGS_SETUP_USER_SUPPLIED_FLAGS],
# Param 1 - Optional prefix to all variables. (e.g BUILD_)
AC_DEFUN([FLAGS_SETUP_SYSROOT_FLAGS],
[
- if test "x[$]$1SYSROOT" != "x"; then
- if test "x$TOOLCHAIN_TYPE" = xgcc; then
- $1SYSROOT_CFLAGS="--sysroot=[$]$1SYSROOT"
- $1SYSROOT_LDFLAGS="--sysroot=[$]$1SYSROOT"
- elif test "x$TOOLCHAIN_TYPE" = xclang; then
- $1SYSROOT_CFLAGS="-isysroot [$]$1SYSROOT"
- $1SYSROOT_LDFLAGS="-isysroot [$]$1SYSROOT"
- fi
- fi
-
- if test "x$OPENJDK_TARGET_OS" = xmacosx; then
- # We also need -iframework<path>/System/Library/Frameworks
- $1SYSROOT_CFLAGS="[$]$1SYSROOT_CFLAGS -iframework
[$]$1SYSROOT/System/Library/Frameworks"
- $1SYSROOT_LDFLAGS="[$]$1SYSROOT_LDFLAGS -iframework
[$]$1SYSROOT/System/Library/Frameworks"
- # These always need to be set, or we can't find the frameworks embedded in
JavaVM.framework
- # set this here so it doesn't have to be peppered throughout the forest
- $1SYSROOT_CFLAGS="[$]$1SYSROOT_CFLAGS -F
[$]$1SYSROOT/System/Library/Frameworks/JavaVM.framework/Frameworks"
- $1SYSROOT_LDFLAGS="[$]$1SYSROOT_LDFLAGS -F
[$]$1SYSROOT/System/Library/Frameworks/JavaVM.framework/Frameworks"
- fi
-
# For the microsoft toolchain, we need to get the SYSROOT flags from the
# Visual Studio environment. Currently we cannot handle this as a separate
# build toolchain.
- if test "x$1" = x && test "x$OPENJDK_BUILD_OS" = "xwindows" \
- && test "x$TOOLCHAIN_TYPE" = "xmicrosoft"; then
- TOOLCHAIN_SETUP_VISUAL_STUDIO_ENV
+ if test "x$TOOLCHAIN_TYPE" = "xmicrosoft"; then
+ # The BUILD_* flags are setup in TOOLCHAIN_SETUP_BUILD_COMPILERS
+ if test "x$1" = x; then
+ TOOLCHAIN_SETUP_VISUAL_STUDIO_ENV
+ fi
+
+ TOOLCHAIN_SETUP_VISUAL_STUDIO_SYSROOT_FLAGS([$1])
+ else
+ if test "x[$]$1SYSROOT" != "x"; then
+ if test "x$TOOLCHAIN_TYPE" = xgcc; then
+ $1SYSROOT_CFLAGS="--sysroot=[$]$1SYSROOT"
+ $1SYSROOT_LDFLAGS="--sysroot=[$]$1SYSROOT"
+ elif test "x$TOOLCHAIN_TYPE" = xclang; then
+ $1SYSROOT_CFLAGS="-isysroot [$]$1SYSROOT"
+ $1SYSROOT_LDFLAGS="-isysroot [$]$1SYSROOT"
+ fi
+ fi
+
+ if test "x$OPENJDK_TARGET_OS" = xmacosx; then
+ # We also need -iframework<path>/System/Library/Frameworks
+ $1SYSROOT_CFLAGS="[$]$1SYSROOT_CFLAGS -iframework
[$]$1SYSROOT/System/Library/Frameworks"
+ $1SYSROOT_LDFLAGS="[$]$1SYSROOT_LDFLAGS -iframework
[$]$1SYSROOT/System/Library/Frameworks"
+ # These always need to be set, or we can't find the frameworks embedded
in JavaVM.framework
+ # set this here so it doesn't have to be peppered throughout the forest
+ $1SYSROOT_CFLAGS="[$]$1SYSROOT_CFLAGS -F
[$]$1SYSROOT/System/Library/Frameworks/JavaVM.framework/Frameworks"
+ $1SYSROOT_LDFLAGS="[$]$1SYSROOT_LDFLAGS -F
[$]$1SYSROOT/System/Library/Frameworks/JavaVM.framework/Frameworks"
+ fi
fi
AC_SUBST($1SYSROOT_CFLAGS)
@@ -373,7 +377,8 @@ AC_DEFUN_ONCE([FLAGS_POST_TOOLCHAIN],
[
FLAGS_SETUP_TOOLCHAIN_CONTROL
- if test "x$BUILD_SYSROOT" != x; then
+ if test "x$BUILD_SYSROOT" != x || \
+ test "x$TOOLCHAIN_TYPE" = "xmicrosoft"; then
FLAGS_SETUP_SYSROOT_FLAGS([BUILD_])
else
if test "x$COMPILE_TYPE" != "xcross"; then
diff --git a/make/autoconf/toolchain.m4 b/make/autoconf/toolchain.m4
index 14213f896d4..4a2462c2dd6 100644
--- a/make/autoconf/toolchain.m4
+++ b/make/autoconf/toolchain.m4
@@ -798,14 +798,18 @@ AC_DEFUN_ONCE([TOOLCHAIN_SETUP_BUILD_COMPILERS],
. $CONFIGURESUPPORT_OUTPUTDIR/build-devkit.info
# This potentially sets the following:
# A descriptive name of the devkit
- BASIC_EVAL_DEVKIT_VARIABLE([BUILD_DEVKIT_NAME])
+ BASIC_EVAL_BUILD_DEVKIT_VARIABLE([BUILD_DEVKIT_NAME])
# Corresponds to --with-extra-path
- BASIC_EVAL_DEVKIT_VARIABLE([BUILD_DEVKIT_EXTRA_PATH])
+ BASIC_EVAL_BUILD_DEVKIT_VARIABLE([BUILD_DEVKIT_EXTRA_PATH])
# Corresponds to --with-toolchain-path
- BASIC_EVAL_DEVKIT_VARIABLE([BUILD_DEVKIT_TOOLCHAIN_PATH])
+ BASIC_EVAL_BUILD_DEVKIT_VARIABLE([BUILD_DEVKIT_TOOLCHAIN_PATH])
# Corresponds to --with-sysroot
- BASIC_EVAL_DEVKIT_VARIABLE([BUILD_DEVKIT_SYSROOT])
- # Skip the Window specific parts
+ BASIC_EVAL_BUILD_DEVKIT_VARIABLE([BUILD_DEVKIT_SYSROOT])
+
+ if test "x$TOOLCHAIN_TYPE" = xmicrosoft; then
+ BASIC_EVAL_BUILD_DEVKIT_VARIABLE([BUILD_DEVKIT_VS_INCLUDE])
+ BASIC_EVAL_BUILD_DEVKIT_VARIABLE([BUILD_DEVKIT_VS_LIB])
+ fi
fi
AC_MSG_CHECKING([for build platform devkit])
@@ -817,11 +821,17 @@ AC_DEFUN_ONCE([TOOLCHAIN_SETUP_BUILD_COMPILERS],
BUILD_SYSROOT="$BUILD_DEVKIT_SYSROOT"
- # Fallback default of just /bin if DEVKIT_PATH is not defined
+ # Fallback default of just /bin if DEVKIT_PATH is not defined
if test "x$BUILD_DEVKIT_TOOLCHAIN_PATH" = x; then
BUILD_DEVKIT_TOOLCHAIN_PATH="$BUILD_DEVKIT_ROOT/bin"
fi
- PATH="$BUILD_DEVKIT_TOOLCHAIN_PATH:$BUILD_DEVKIT_EXTRA_PATH"
+
+
UTIL_PREPEND_TO_PATH([PATH],"$BUILD_DEVKIT_TOOLCHAIN_PATH:$BUILD_DEVKIT_EXTRA_PATH")
+
+ if test "x$TOOLCHAIN_TYPE" = xmicrosoft; then
+ BUILD_VS_INCLUDE="${BUILD_DEVKIT_VS_INCLUDE//;/:}"
+ BUILD_VS_LIB="${BUILD_DEVKIT_VS_LIB//;/:}"
+ fi
fi
fi
@@ -836,9 +846,27 @@ AC_DEFUN_ONCE([TOOLCHAIN_SETUP_BUILD_COMPILERS],
UTIL_LOOKUP_PROGS(BUILD_STRIP, strip)
# Assume the C compiler is the assembler
BUILD_AS="$BUILD_CC -c"
- # Just like for the target compiler, use the compiler as linker
- BUILD_LD="$BUILD_CC"
- BUILD_LDCXX="$BUILD_CXX"
+ if test "x$TOOLCHAIN_TYPE" = xmicrosoft; then
+ # In the Microsoft toolchain we have a separate LD command "link".
+ UTIL_LOOKUP_TOOLCHAIN_PROGS(BUILD_LD, link)
+
+ # Make sure we did not pick up /usr/bin/link, which is the unix-style
+ # link executable.
+ AC_MSG_CHECKING([if the found link.exe is actually the Visual Studio
linker])
+ $BUILD_LD --version > /dev/null
+ if test $? -eq 0 ; then
+ AC_MSG_RESULT([no])
+ AC_MSG_ERROR([This is the winenv link tool. Please check your PATH and
rerun configure.])
+ else
+ AC_MSG_RESULT([yes])
+ fi
+
+ BUILD_LDCXX="$BUILD_LD"
+ else
+ # Just like for the target compiler, use the compiler as linker
+ BUILD_LD="$BUILD_CC"
+ BUILD_LDCXX="$BUILD_CXX"
+ fi
PATH="$OLDPATH"
@@ -879,7 +907,7 @@ AC_DEFUN_ONCE([TOOLCHAIN_MISC_CHECKS],
# Check for extra potential brokenness.
if test "x$TOOLCHAIN_TYPE" = xmicrosoft; then
# On Windows, double-check that we got the right compiler.
- CC_VERSION_OUTPUT=`$COMPILER 2>&1 1>/dev/null | $GREP -v
'ERROR.*UtilTranslatePathList' | $HEAD -n 1 | $TR -d '\r'`
+ CC_VERSION_OUTPUT=`$CC 2>&1 1>/dev/null | $GREP -v
'ERROR.*UtilTranslatePathList' | $HEAD -n 1 | $TR -d '\r'`
COMPILER_CPU_TEST=`$ECHO $CC_VERSION_OUTPUT | $SED -n "s/^.* \(.*\)$/\1/p"`
if test "x$OPENJDK_TARGET_CPU" = "xx86"; then
if test "x$COMPILER_CPU_TEST" != "x80x86" -a "x$COMPILER_CPU_TEST" !=
"xx86"; then
diff --git a/make/autoconf/toolchain_microsoft.m4
b/make/autoconf/toolchain_microsoft.m4
index fd8dfc3641d..2e297dc8be1 100644
--- a/make/autoconf/toolchain_microsoft.m4
+++ b/make/autoconf/toolchain_microsoft.m4
@@ -309,8 +309,8 @@ AC_DEFUN([TOOLCHAIN_FIND_VISUAL_STUDIO],
eval VS_SUPPORTED="\${VS_SUPPORTED_${VS_VERSION}}"
eval PLATFORM_TOOLSET="\${VS_VS_PLATFORM_NAME_${VS_VERSION}}"
- VS_INCLUDE=${DEVKIT_VS_INCLUDE//;/:}
- VS_LIB=${DEVKIT_VS_LIB//;/:}
+ VS_INCLUDE="${DEVKIT_VS_INCLUDE//;/:}"
+ VS_LIB="${DEVKIT_VS_LIB//;/:}"
AC_MSG_NOTICE([Found devkit $VS_DESCRIPTION])
@@ -426,21 +426,6 @@ AC_DEFUN([TOOLCHAIN_SETUP_VISUAL_STUDIO_ENV],
# Turn VS_PATH into TOOLCHAIN_PATH
TOOLCHAIN_PATH="$TOOLCHAIN_PATH:$VS_PATH"
-
- # Convert VS_INCLUDE into SYSROOT_CFLAGS
- OLDIFS="$IFS"
- IFS=":"
-
- for ipath in $VS_INCLUDE; do
- SYSROOT_CFLAGS="$SYSROOT_CFLAGS -I$ipath"
- done
-
- # Convert VS_LIB into SYSROOT_LDFLAGS
- for libpath in $VS_LIB; do
- SYSROOT_LDFLAGS="$SYSROOT_LDFLAGS -libpath:$libpath"
- done
-
- IFS="$OLDIFS"
fi
else
AC_MSG_RESULT([not found])
@@ -488,22 +473,20 @@ AC_DEFUN([TOOLCHAIN_SETUP_MSVC_DLL],
DLL_NAME="$1"
MSVC_DLL=
+ if test "x$OPENJDK_TARGET_CPU" = xx86; then
+ vs_target_cpu=x86
+ elif test "x$OPENJDK_TARGET_CPU" = xx86_64; then
+ vs_target_cpu=x64
+ fi
+
if test "x$MSVC_DLL" = x; then
if test "x$VCINSTALLDIR" != x; then
if test "$VS_VERSION" -lt 2017; then
# Probe: Using well-known location from Visual Studio 12.0 and older
- if test "x$OPENJDK_TARGET_CPU_BITS" = x64; then
-
POSSIBLE_MSVC_DLL="$VCINSTALLDIR/redist/x64/microsoft.vc${VS_VERSION_INTERNAL}.crt/$DLL_NAME"
- else
-
POSSIBLE_MSVC_DLL="$VCINSTALLDIR/redist/x86/microsoft.vc${VS_VERSION_INTERNAL}.crt/$DLL_NAME"
- fi
+
POSSIBLE_MSVC_DLL="$VCINSTALLDIR/redist/$vs_target_cpu/Microsoft.VC${VS_VERSION_INTERNAL}.CRT/$DLL_NAME"
else
# Probe: Using well-known location from VS 2017 and VS 2019
- if test "x$OPENJDK_TARGET_CPU_BITS" = x64; then
- POSSIBLE_MSVC_DLL="`ls
$VCToolsRedistDir/x64/microsoft.vc${VS_VERSION_INTERNAL}.crt/$DLL_NAME`"
- else
- POSSIBLE_MSVC_DLL="`ls
$VCToolsRedistDir/x86/microsoft.vc${VS_VERSION_INTERNAL}.crt/$DLL_NAME`"
- fi
+ POSSIBLE_MSVC_DLL="`ls
$VCToolsRedistDir/$vs_target_cpu/microsoft.vc${VS_VERSION_INTERNAL}.crt/$DLL_NAME`"
fi
# In case any of the above finds more than one file, loop over them.
for possible_msvc_dll in $POSSIBLE_MSVC_DLL; do
@@ -537,13 +520,8 @@ AC_DEFUN([TOOLCHAIN_SETUP_MSVC_DLL],
WIN_VS_TOOLS_DIR="$VS100COMNTOOLS/.."
UTIL_FIXUP_PATH(WIN_VS_TOOLS_DIR, NOFAIL)
if test "x$WIN_VS_TOOLS_DIR" != x; then
- if test "x$OPENJDK_TARGET_CPU_BITS" = x64; then
- POSSIBLE_MSVC_DLL=`$FIND "$WIN_VS_TOOLS_DIR" -name $DLL_NAME \
- | $GREP -i /x64/ | $HEAD --lines 1`
- else
- POSSIBLE_MSVC_DLL=`$FIND "$WIN_VS_TOOLS_DIR" -name $DLL_NAME \
- | $GREP -i /x86/ | $HEAD --lines 1`
- fi
+ POSSIBLE_MSVC_DLL=`$FIND "$WIN_VS_TOOLS_DIR" -name $DLL_NAME \
+ | $GREP -i /$vs_target_cpu/ | $HEAD --lines 1`
TOOLCHAIN_CHECK_POSSIBLE_MSVC_DLL([$DLL_NAME], [$POSSIBLE_MSVC_DLL],
[search of VS100COMNTOOLS])
fi
@@ -554,17 +532,17 @@ AC_DEFUN([TOOLCHAIN_SETUP_MSVC_DLL],
# Probe: Search wildly in the VCINSTALLDIR. We've probably lost by now.
# (This was the original behaviour; kept since it might turn something up)
if test "x$VCINSTALLDIR" != x; then
- if test "x$OPENJDK_TARGET_CPU_BITS" = x64; then
- POSSIBLE_MSVC_DLL=`$FIND "$VCINSTALLDIR" -name $DLL_NAME \
- | $GREP x64 | $HEAD --lines 1`
- else
+ if test "x$vs_target_cpu" = xx86; then
POSSIBLE_MSVC_DLL=`$FIND "$VCINSTALLDIR" -name $DLL_NAME \
- | $GREP x86 | $GREP -v ia64 | $GREP -v x64 | $HEAD --lines 1`
+ | $GREP x86 | $GREP -v ia64 | $GREP -v x64 | $GREP -v arm64 | $HEAD
--lines 1`
if test "x$POSSIBLE_MSVC_DLL" = x; then
# We're grasping at straws now...
POSSIBLE_MSVC_DLL=`$FIND "$VCINSTALLDIR" -name $DLL_NAME \
- | $HEAD --lines 1`
+ | $HEAD --lines 1`
fi
+ else
+ POSSIBLE_MSVC_DLL=`$FIND "$VCINSTALLDIR" -name $DLL_NAME \
+ | $GREP $vs_target_cpu | $HEAD --lines 1`
fi
TOOLCHAIN_CHECK_POSSIBLE_MSVC_DLL([$DLL_NAME], [$POSSIBLE_MSVC_DLL],
@@ -628,9 +606,9 @@ AC_DEFUN([TOOLCHAIN_SETUP_VS_RUNTIME_DLLS],
fi
AC_ARG_WITH(vcruntime-1-dll, [AS_HELP_STRING([--with-vcruntime-1-dll],
- [path to microsoft C++ runtime dll (vcruntime*_1.dll) (Windows x64 only)
@<:@probed@:>@])])
+ [path to microsoft C++ runtime dll (vcruntime*_1.dll) (Windows 64-bits
only) @<:@probed@:>@])])
- if test "x$VCRUNTIME_1_NAME" != "x" && test "x$OPENJDK_TARGET_BITS" = x64;
then
+ if test "x$VCRUNTIME_1_NAME" != "x" && test "x$OPENJDK_TARGET_CPU_BITS" =
x64; then
if test "x$with_vcruntime_1_dll" != x; then
# If given explicitly by user, do not probe. If not present, fail
directly.
TOOLCHAIN_CHECK_POSSIBLE_MSVC_DLL($VCRUNTIME_1_NAME,
[$with_vcruntime_1_dll],
@@ -695,3 +673,25 @@ AC_DEFUN([TOOLCHAIN_SETUP_VS_RUNTIME_DLLS],
fi
AC_SUBST(UCRT_DLL_DIR)
])
+
+# Setup the sysroot flags and add them to global CFLAGS and LDFLAGS so
+# that configure can use them while detecting compilers.
+# TOOLCHAIN_TYPE is available here.
+# Param 1 - Optional prefix to all variables. (e.g BUILD_)
+AC_DEFUN([TOOLCHAIN_SETUP_VISUAL_STUDIO_SYSROOT_FLAGS],
+[
+ OLDIFS="$IFS"
+ IFS=":"
+
+ # Convert $1VS_INCLUDE into $1SYSROOT_CFLAGS
+ for ipath in [$]$1VS_INCLUDE; do
+ $1SYSROOT_CFLAGS="[$]$1SYSROOT_CFLAGS -I$ipath"
+ done
+
+ # Convert $1VS_LIB into $1SYSROOT_LDFLAGS
+ for libpath in [$]$1VS_LIB; do
+ $1SYSROOT_LDFLAGS="[$]$1SYSROOT_LDFLAGS -libpath:$libpath"
+ done
+
+ IFS="$OLDIFS"
+])
diff --git a/make/hotspot/gensrc/GensrcAdlc.gmk
b/make/hotspot/gensrc/GensrcAdlc.gmk
index 0947133c16e..bcdea62590d 100644
--- a/make/hotspot/gensrc/GensrcAdlc.gmk
+++ b/make/hotspot/gensrc/GensrcAdlc.gmk
@@ -88,6 +88,10 @@ ifeq ($(call check-jvm-feature, compiler2), true)
ADLCFLAGS += -DAIX=1
else ifeq ($(call isTargetOs, macosx), true)
ADLCFLAGS += -D_ALLBSD_SOURCE=1 -D_GNU_SOURCE=1
+ else ifeq ($(call isTargetOs, windows), true)
+ ifeq ($(call isTargetCpuBits, 64), true)
+ ADLCFLAGS += -D_WIN64=1
+ endif
endif
ifeq ($(call isTargetOs, windows), false)
diff --git a/make/modules/java.base/gensrc/GensrcMisc.gmk
b/make/modules/java.base/gensrc/GensrcMisc.gmk
index cd12f2ab318..5390fcabe85 100644
--- a/make/modules/java.base/gensrc/GensrcMisc.gmk
+++ b/make/modules/java.base/gensrc/GensrcMisc.gmk
@@ -60,6 +60,10 @@ ifneq ($(filter $(TOOLCHAIN_TYPE), gcc clang), )
CPP_FLAGS += -x c
else ifeq ($(TOOLCHAIN_TYPE), microsoft)
CPP_FLAGS += -nologo
+
+ # cl.exe does only recognize few file extensions as valid (ex: .c, .h,
.cpp), so
+ # make sure *.java.template files are recognized as valid input files
+ CPP_FILEPREFIX = -Tc
endif
# Generate a java source file from a template through the C preprocessor for
the
@@ -73,7 +77,7 @@ define generate-preproc-src
$(call MakeDir, $(@D))
$(call ExecuteWithLog, $(SUPPORT_OUTPUTDIR)/gensrc/java.base/_$(@F), \
( $(NAWK) '/@@END_COPYRIGHT@@/{exit}1' $< && \
- $(CPP) $(CPP_FLAGS) $(SYSROOT_CFLAGS) $(CFLAGS_JDKLIB) $< \
+ $(CPP) $(CPP_FLAGS) $(SYSROOT_CFLAGS) $(CFLAGS_JDKLIB)
$(CPP_FILEPREFIX) $< \
2> >($(GREP) -v '^$(<F)$$' >&2) \
| $(NAWK) '/@@START_HERE@@/,0' \
| $(SED) -e 's/@@START_HERE@@/\/\/ AUTOMATICALLY GENERATED
FILE - DO NOT EDIT/' \
Thank you,
--
Ludovic
________________________________________
From: build-dev <[email protected]> on behalf of Yasumasa Suenaga
<[email protected]>
Sent: Sunday, July 5, 2020 19:19
To: Magnus Ihse Bursie; build-dev
Subject: Re: Preliminary review for new WINENV support
Hi Magnus,
It's awesome work! I tested your patch, but I saw some errors (configure
--enable-debug --with-boot-jdk=/path/to/jdk14):
1) script error
checking for gdiff...
/mnt/d/test/jdk-master/build/.configure-support/generated-configure.sh: line
9989: test: /mnt/c/Program: binary operator expected
/mnt/d/test/jdk-master/build/.configure-support/generated-configure.sh: line
9993: test: /mnt/c/Program: binary operator expected
/mnt/d/test/jdk-master/build/.configure-support/generated-configure.sh: line
9989: test: too many arguments
2) warning in awk
configure: Found potential Boot JDK using configure arguments
gawk: cmd. line:1: warning: regexp escape sequence `\"' is not a known regexp
operator
checking for Boot JDK... /mnt/c/java/jdk-14.0.1
3) command not found at fixpath.sh (it happens on `make images`)
/mnt/d/test/jdk-master/make/scripts/fixpath.sh: line 402:
/mnt/d/test/jdk-master/build/windows-x86_64-server-fastdebug/jdk/bin/java: No
such file or directory
I fixed them with following patch, and it works fine on my WSL 1.
```
diff --git a/make/autoconf/boot-jdk.m4 b/make/autoconf/boot-jdk.m4
index 7059558b2..db73eba15 100644
--- a/make/autoconf/boot-jdk.m4
+++ b/make/autoconf/boot-jdk.m4
@@ -77,7 +77,7 @@ AC_DEFUN([BOOTJDK_DO_CHECK],
# Additional [] needed to keep m4 from mangling shell constructs.
java_to_test="$BOOT_JDK/bin/java"
UTIL_FIXUP_EXECUTABLE(java_to_test)
- [ BOOT_JDK_VERSION=`$java_to_test $USER_BOOT_JDK_OPTIONS -version
2>&1 | $AWK '/version \"[0-9a-zA-Z\._\-]+\"/{print $ 0; exit;}'` ]
+ [ BOOT_JDK_VERSION=`$java_to_test $USER_BOOT_JDK_OPTIONS -version
2>&1 | $AWK '/version "[0-9a-zA-Z\._\-]+"/{print $ 0; exit;}'` ]
if [ [[ "$BOOT_JDK_VERSION" =~ "Picked up" ]] ]; then
AC_MSG_NOTICE([You have _JAVA_OPTIONS or JAVA_TOOL_OPTIONS set.
This can mess up the build. Please use --with-boot-jdk-jvmargs instead.])
AC_MSG_NOTICE([Java reports: "$BOOT_JDK_VERSION".])
diff --git a/make/autoconf/util_paths.m4 b/make/autoconf/util_paths.m4
index 8dec82fdc..3d20d1700 100644
--- a/make/autoconf/util_paths.m4
+++ b/make/autoconf/util_paths.m4
@@ -377,11 +377,11 @@ AC_DEFUN([UTIL_LOOKUP_PROGS],
continue
fi
full_path="$elem/$name"
- if test ! -e $full_path && test "x$OPENJDK_BUILD_OS" = "xwindows";
then
+ if test ! -e "$full_path" && test "x$OPENJDK_BUILD_OS" = "xwindows";
then
# Try again with .exe
full_path="$elem/$name.exe"
fi
- if test -e $full_path; then
+ if test -e "$full_path"; then
$1="$full_path"
UTIL_FIXUP_EXECUTABLE($1, $3)
result="[$]$1"
diff --git a/make/scripts/fixpath.sh b/make/scripts/fixpath.sh
index 14eacbec6..f8293a798 100644
--- a/make/scripts/fixpath.sh
+++ b/make/scripts/fixpath.sh
@@ -393,6 +393,10 @@ function exec_command_line() {
fi
done
+ if [ ! -e "$command" ]; then
+ command="$command".exe
+ fi
+
# Now execute it
if [[ -v DEBUG_FIXPATH ]]; then
echo fixpath: debug: "$command" "${collected_args[@]}" >&2
```
I tried to build on WSL 2, but I couldn't because the process seemed to hangup.
configure script could work normally, but I saw following message on my console
in the end.
I guess it is not an issue in your patch because I haven't seen it on WSL 1.
```
cat: standard output: No such file or directory
```
Also I saw LNK1158 error as following, but it might be caused by my environment
- my Windows box has been installed both Visual Studio 2019 and Windows SDK.
(My PC is set locale to Japanese, sorry :)
* For target hotspot_variant-server_libjvm_objs_BUILD_LIBJVM_link:
?????
d:\test\jdk-master\build\windows-x86_64-server-fastdebug\hotspot\variant-server\libjvm\objs\jvm.lib
???????
d:\test\jdk-master\build\windows-x86_64-server-fastdebug\hotspot\variant-server\libjvm\objs\jvm.exp
????
LINK : fatal error LNK1158: 'rc.exe' ?????????
I could solve the problem in the way the following URL indicate.
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F35215971%2Flnk1158-cannot-run-rc-exe-x64-visual-studio&data=02%7C01%7Cluhenry%40microsoft.com%7C0af6353951e7444afe0f08d8215372b6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637295989593225573&sdata=NAyBUTKSQF8PrSgfa5nQADyYvzWdo4Ipi4csjjLiENc%3D&reserved=0
Thanks,
Yasumasa
On 2020/07/05 9:08, Magnus Ihse Bursie wrote:
> I've been working for some time on a complete rewrite of how we handle the
> pecularities of the Windows build environment. This new solution supports
> Cygwin, Msys2, WSL1 and WSL2 (after a fashion, see below), what I have termed
> different "winenvs".
>
> One of the main design goals has been to minimize the difference for the
> configure script and make files for the different winenvs, and leverage as
> much shared code between them as possible. Another has been to try to collect
> all the "trickiness" needed in as few places as possible, ideally just one,
> instead of having it spread out all over the configure script. A third design
> goal has been to prepare for cross-compilation for Windows from Linux, using
> Wine.
>
> It pretty soon turned out that I needed to get a better grip on how we detect
> tools in configure, so a complete overhaul of this is included in the change.
> Now we have more or less fully parted with the original autoconf functions,
> which has long been too limited for us, and now finally has reached their end
> of usefulness.
>
> At this point, I have a prototype / preview that basically works, but has
> some limitations.
>
> I'd like to ask anyone interested in building OpenJDK on Windows to take the
> patch for a spin. Especially if you have an esoteric or exotic setup!
>
> Webrev:
> https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~ihse%2Fwinenv-preview-1%2Fwebrev.01%2F&data=02%7C01%7Cluhenry%40microsoft.com%7C0af6353951e7444afe0f08d8215372b6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637295989593225573&sdata=x2l2BWhjrvdlMRN3NdZFEU0Vq3mv7SSLiSG9nk7bYE4%3D&reserved=0
>
> (If you prefer, you can check out the branch "ihse-winenv-branch" on
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fsandbox%2F&data=02%7C01%7Cluhenry%40microsoft.com%7C0af6353951e7444afe0f08d8215372b6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637295989593235570&sdata=jUbEnTaogeVOgP%2BjSe2JyFH1wyx2eX6rBw%2F3ydXlnkI%3D&reserved=0
> instead of downloading the patch from the webrev.)
>
> I am leaving on vacation next week, so I won't be doing any more work on this
> for a while, but I promise to read all emails when I get back and try to
> rectify all issues that are reported. This means you have some time to try it
> out, too.
>
> Here are some technical notes of what is changing, compared to the current
> Windows build.
>
> The native "fixpath.exe" tool is gone. This means that we do not need to
> compile it during configure, which was always tricky to get right (mostly
> since we did not have fixpath in place to help us...).
>
> Instead, there is a new fixpath.sh shell script, that does the same job, and
> more. The script is written in highly optimized shell code (yeah, I see the
> oxymoron) so only bash internal functionality is used, to avoid calling
> external tools, which is expensive on Windows. This makes the performance
> practically roughly at par with the native fixpath.exe.
>
> Fixpath also has a "print" and "import" mode, apart from the
> traditional"exec" mode. This makes it possible to use the same tool for
> converting individual paths at runtime to Windows style ("print"), and it
> takes the logic needed to "import" paths given by the user to configure, into
> a format usable internally by the build system, and moves it into a
> centralized location in the fixpath script.
>
> A "winenv" is defined by a quartet of variables: PATHTOOL, DRIVEPREFIX,
> ENVROOT and WINTEMP. For instance, for "cygwin", these are:
> PATHTOOL=cygpath
> DRIVEPREFIX=/cygdrive (typically)
> ENVROOT=C:\Cygwin64 (typically)
> WINTEMP=/tmp
>
> These are needed for fixpath to do it's magic. Fixpath can auto-detect those,
> but to save on execution time they are normally detected by configure and
> sent as arguments to fixpath.
>
> Detection of the Visual Studio environment has been massively simplified.
> Using fixpath, conversion between Windows and unix paths is not so complex
> anymore. The bridge Windows batch file that is needed to extract the
> environment variables is no longer created on the fly, but is instead stored
> in make/scripts/extract-vs-env.cmd. This is called with fixpath, so all
> arguments to it can be unix paths.
>
> Furthermore, TOOLCHAIN_SETUP_VISUAL_STUDIO_ENV is now clearly designed to
> have a single responsibility, to set SYSROOT flags (and TOOLCHAIN_PATH) for
> the microsoft toolchain. As a result of this, it is now called from
> FLAGS_SETUP_SYSROOT_FLAGS. Also, the file toolchain_windows.m4 is now more
> correctly named toolchain_microsoft.m4. A price we had to pay for this was
> that the old idea that you should be able to start a "Visual Studio console"
> and then run configure from it to extract the variables do not work anymore.
> (It had not been tested for ages, and might have been broken anyway.)
>
> Fixpath also knows about the difference between unix path lists
> (/foo/bar:/my/dir) and windows path lists (c:\dir;d:\data) and can convert
> freely and automatically between them. This furthermore means that PATH_SEP
> is removed, and we only use unix style (colon separated) path lists
> internally.
>
> The logic automatically detects if and when .exe is needed, so EXE_SUFFIX is
> removed too. There are some limitations; when code needs to explicitly test
> for the presence of a file, the suffix needs to be correct. Also when make
> files check for e.g. the generated bin/java.exe, the suffix needs to be
> present. For this, I have introduced an EXECUTABLE_SUFFIX, that has the same
> value as EXE_SUFFIX -- but not the same semantics! The old code added
> EXE_SUFFIX here and there, not caring about if we meant "microsoft" as a
> toolchain or if we were running on Windows as a build platform. Clearly not
> well adapted for future cross-compilation.
>
> The old ways of locating programs in configure were messy, complicated and
> not always correct. We used a mixture of the original autoconf macros, and
> our own UTIL_PATH_PROGS and UTIL_CHECK_TOOLS. These did not have very well
> defined semantics, and were frequently mixed up. Also, UTIL_CHECK_TOOLS
> required UTIL_FIXUP_EXECUTABLE tobe called afterwards, to "rewrite" the
> result in a second step. This was not needed after UTIL_PATH_PROGS but was
> frequently done anyway to "be on the safe side".
>
> I have now replaced:
> AC_(PATH|CHECK)_(PROG|PROGS) with UTIL_LOOKUP_PROGS
> AC_(PATH|CHECK)_(TOOL|TOOLS) with UTIL_LOOKUP_TOOLCHAIN_PROGS
>
> This is actually almost the same semantic, but unless you're an autoconf
> aficionado, you ar not likely to understand the difference between "PROG"
> and "TOOL". The only difference is that UTIL_LOOKUP_TOOLCHAIN_PROGS will try
> to look for "host-prefixed" tools first, when cross-compiling, and should
> therefore be used for all toolchain lookups.
>
> There is also a fail-fast version of both, UTIL_REQUIRE_PROGS and
> UTIL_REQUIRE_TOOLCHAIN_PROGS.
>
> UTIL_LOOKUP_PROGS is the core function, with the rest being thin wrappers
> around it. This function is created from scratch, to do exactly what we want,
> on Unix platforms and Windows. So there is no need anymore to call
> UTIL_FIXUP_EXECUTABLE, unless you have input from elsewhere (e.g. user flag)
> that you need to verify. I have also collected all this logic in a single
> file, util_paths.m4, moving parts from util.m4, and just removing
> util_windows.m4.
>
> UTIL_LOOKUP_PROGS will use the new and nifty function
> UTIL_CHECK_WINENV_EXEC_TYPE, which will automatically determine if an
> executable needs to be prefixed by fixpath! That means that you can match and
> mix Windows-style and Unix-style programs however you like, with very few
> limitations. For instance, you can have a Linux version of the BootJDK on
> WSL. For this to work, the $FIXPATH prefix is now stored in the variables
> themselves (e.g. in $CC), rather than added as @FIXPATH@ in spec.gmk.in. This
> has generally worked out OK, but caused some headaches when the code thought
> that $CC (etc) was not a way to launch a program, but was a file that could
> be tested for existence, etc.
>
> I reintroduced support for msys2. This was mostly free, since msys2 is so
> close to cygwin (which msys never where). To underline the difference, I
> renamed the winenv windows.msys2 (instead of windows.msys). Msys (version 1)
> will never be supported in modern OpenJDK due to critical packages being far
> too old, and not updated. I also clearly separate between WSL1 (which is
> using a kernel emulation layer, somewhat like Wine) and WSL2 (which is using
> a Hyper-V VM to run an actual Linux kernel), as windows.wsl1 and windows.wsl2.
>
> I have also done a ton of small fixes, to make things more convenient and
> smooth when working in these winenvs. I have adjusted the output from
> configure to be less verbose and more streamlined. Overall, a lot of odd code
> in configure has been removed. A few changes that are strictly unneeded for
> this patch has also been included; mostly removal of dead code I came across,
> and a few fixes for additional debuggability that I needed when developing
> this patch, like ExecuteithLog.
>
> I have also temporarily disabled the javac server, and building without
> absolute paths. I believe a better way forward is to address these with
> improved functionality in separate patches, instead of trying to work around
> the issues introduced by them in this patch.
>
> I have done substantial testing of the core functionality (building
> jdk-images) on Cygwin, Msys2 and WSL2, both on my personal machine and on
> Oracle's CI system. The performance on Cygwin (which we use for our CI
> builds) is roughly on par with the old Cygwin performance, but the WSL1
> performance is roughly 20% faster, so I think we should investigate if it is
> possible for us to switch to WSL1. Everything seems stable so far, but more
> testing is definitely needed. I have also not even started testing autxillary
> functionality, such as the compare script, IDE project file generation
> etc.
>
> However, the big disappointment in all of this is WSL2. That was the main
> driver that got me started on this rewrite. But it turned out that WSL2 is
> still very immature. :-( There are lot of issues, like stdout and stderr
> getting messed up, time synchronization issues causing make to complain about
> "Clock skew detected", extreme slowness when accessing disks cross the OS
> boundary. But worst of all has been that WSL2 is *extremly* unstable. After a
> few calls of Window executables, I get the impression that a conversion
> daemon dies. All further calls to Window binaries just stalls, and the WSL2
> instance is unusable until I terminate it using "wsl -t Ubuntu-2004" from a
> cmd shell. :-(
>
> So the WSL2 functionality is not very well tested, since I have not been able
> to build it completely a single time. I do believe that everything is
> correct, in "theory". So in case this is something broken with my WSL2
> installation, I'd encourage anyone with a WSL2 installation to try it out.
>
> /Magnus
>
