Preliminary review for new WINENV support
Ludovic Henry
luhenry at microsoft.com
Tue Jul 7 19:57:54 UTC 2020
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 <luhenry at microsoft.com>
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 <build-dev-retn at openjdk.java.net> on behalf of Yasumasa Suenaga <suenaga at oss.nttdata.com>
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
>
More information about the build-dev
mailing list