From kennedyhan at 163.com Wed Jul 1 08:39:45 2015 From: kennedyhan at 163.com (kennedy) Date: Wed, 1 Jul 2015 16:39:45 +0800 (CST) Subject: =?UTF-8?Q?=E2=80=8BCompile_openJDK_ERROR_FreeType_ve?= =?UTF-8?Q?rsion__2.3.0__or_higher_is_required?= Message-ID: <6263390a.e43a.14e48c59826.Coremail.kennedyhan@163.com> Compile openJDK 1.7 (x64) on Windows 7 (x64) and the error output: ------ ( cd ./jdk/make && \ make sanity HOTSPOT_IMPORT_CHECK=false JDK_TOPDIR=E:/research/open/jdk7/jdk JDK_MAKE_SHARED_DIR=E:/research/open/jdk7/jdk/make/common/shared EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 JDK_BUILD_NUMBER=b00 FULL_VERSION=1.7.0-internal-administrator_2015_07_01_16_07-b00 PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0 ANT_HOME="E:/APACHE~1.5" ALT_OUTPUTDIR=e:/research/open/output_amd64 ALT_LANGTOOLS_DIST=e:/research/open/output_amd64/langtools/dist ALT_CORBA_DIST=e:/research/open/output_amd64/corba/dist ALT_JAXP_DIST=e:/research/open/output_amd64/jaxp/dist ALT_JAXWS_DIST=e:/research/open/output_amd64/jaxws/dist ALT_HOTSPOT_IMPORT_PATH=e:/research/open/output_amd64/hotspot/import BUILD_HOTSPOT=true ; ) make[1]: Entering directory '/cygdrive/e/research/open/jdk7/jdk/make' make[2]: *** [e:/research/open/output_amd64/btbins/freetype_versioncheck.exe] Error 96 make[1]: Leaving directory '/cygdrive/e/research/open/jdk7/jdk/make' Build Machine Information: build machine = GOBIXQR4SKSVROP Build Directory Structure: CWD = /cygdrive/e/research/open/jdk7 TOPDIR = . LANGTOOLS_TOPDIR = ./langtools JAXP_TOPDIR = ./jaxp JAXWS_TOPDIR = ./jaxws CORBA_TOPDIR = ./corba HOTSPOT_TOPDIR = ./hotspot JDK_TOPDIR = ./jdk Build Directives: BUILD_LANGTOOLS = true BUILD_JAXP = true BUILD_JAXWS = true BUILD_CORBA = true BUILD_HOTSPOT = true BUILD_JDK = true DEBUG_CLASSFILES = DEBUG_BINARIES = Hotspot Settings: HOTSPOT_BUILD_JOBS = 4 HOTSPOT_OUTPUTDIR = e:/research/open/output_amd64/hotspot/outputdir HOTSPOT_EXPORT_PATH = e:/research/open/output_amd64/hotspot/import Bootstrap Settings: BOOTDIR = c:/jdk1.6 ALT_BOOTDIR = c:/jdk1.6 BOOT_VER = 1.6.0 [requires at least 1.6] OUTPUTDIR = e:/research/open/output_amd64 ALT_OUTPUTDIR = e:/research/open/output_amd64 ABS_OUTPUTDIR = e:/research/open/output_amd64 Build Tool Settings: SLASH_JAVA = J: ALT_SLASH_JAVA = VARIANT = OPT JDK_DEVTOOLS_DIR = J:/devtools ALT_JDK_DEVTOOLS_DIR = ANT_HOME = E:/APACHE~1.5 UNIXCOMMAND_PATH = /usr/bin/ ALT_UNIXCOMMAND_PATH = COMPILER_PATH = C:/PROGRA~2/MICROS~1.0/Common7/Tools/../../Vc/bin/amd64/ ALT_COMPILER_PATH = DEVTOOLS_PATH = /usr/bin/ ALT_DEVTOOLS_PATH = MSVCRNN_DLL_PATH = E:/research/jdkBuild/msvcr100 ALT_MSVCRNN_DLL_PATH = e:/research/jdkBuild/msvcr100 INCLUDE = e:\Microsoft Visual Studio 10.0\VC\INCLUDE;C:\Program Files (x86)\Microsoft SDKs\Windows7.0A\include LIB = e:\Microsoft Visual Studio 10.0\VC\libmd64;C:\Program Files (x86)\Microsoft SDKs\Windows7.0A\lib COMPILER_NAME = Microsoft Visual Studio 10 (16.00.30319.01) COMPILER_VERSION = VS2010 CC_VER = 16.00.40219.01 [requires at least 16.00.30319.01] ZIP_VER = 3.0 [requires at least 2.2] UNZIP_VER = 6.00 [requires at least 5.12] LINK_VER = 10.00.40219.01 [requires at least 10.00.30319.01] CC = C:/PROGRA~2/MICROS~1.0/Common7/Tools/../../Vc/bin/amd64/cl LINK = C:/PROGRA~2/MICROS~1.0/Common7/Tools/../../Vc/bin/amd64/link DUMPBIN = C:/PROGRA~2/MICROS~1.0/Common7/Tools/../../Vc/bin/amd64/dumpbin.exe ANT_VER = 1.9.5 [requires at least 1.7.1] TEMPDIR = e:/research/open/output_amd64/tmp Build Directives: OPENJDK = true USE_HOTSPOT_INTERPRETER_MODE = PEDANTIC = DEV_ONLY = NO_DOCS = NO_IMAGES = TOOLS_ONLY = INSANE = COMPILE_APPROACH = normal FASTDEBUG = COMPILER_WARNINGS_FATAL = false COMPILER_WARNING_LEVEL = 3 SHOW_ALL_WARNINGS = false INCREMENTAL_BUILD = false CC_HIGHEST_OPT = CC_HIGHER_OPT = CC_LOWER_OPT = CXXFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- -Fde:/research/open/output_amd64/tmp/obj64/.pdb -Fme:/research/open/output_amd64/tmp/obj64/.map -wd4800 -W3 -D _CRT_SECURE_NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE CFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- -Fde:/research/open/output_amd64/tmp/obj64/.pdb -Fme:/research/open/output_amd64/tmp/obj64/.map -wd4800 -W3 -D _CRT_SECURE_NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE BOOT_JAVA_CMD = c:/jdk1.6/bin/java -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -Xmx512m -Xms512m -XX:PermSize=32m -XX:MaxPermSize=160m BOOT_JAVAC_CMD = c:/jdk1.6/bin/javac -J-XX:ThreadStackSize=1536 -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -encoding ascii -source 6 -target 6 -XDignore.symbol.file=true BOOT_JAR_CMD = c:/jdk1.6/bin/jar BOOT_JARSIGNER_CMD = c:/jdk1.6/bin/jarsigner Build Platform Settings: USER = Administrator PLATFORM = windows ARCH = amd64 LIBARCH = amd64 ARCH_FAMILY = amd64 ARCH_DATA_MODEL = 64 ARCHPROP = amd64 PROCESSOR_ARCHITECTURE = AMD64 PROCESSOR_IDENTIFIER = Intel64 Family 6 Model 60 Stepping 3, GenuineIntel USING_CYGWIN = true CYGWIN_VER = 6.1 [requires at least 4.0] CYGPATH_CMD = cygpath -a -s -m OS_VERSION = 5.0 [requires at least 5.2] OS_VARIANT_NAME = Windows2000 OS_VARIANT_VERSION = 5.0 MB_OF_MEMORY = 16278 GNU Make Settings: MAKE = make MAKE_VER = 4.1 [requires at least 3.81] MAKECMDGOALS = sanity MAKEFLAGS = w SHELL = /bin/sh Target Build Versions: JDK_VERSION = 1.7.0 MILESTONE = internal RELEASE = 1.7.0-internal FULL_VERSION = 1.7.0-internal-administrator_2015_07_01_16_07-b00 BUILD_NUMBER = b00 External File/Binary Locations: USRJDKINSTANCES_PATH = C:/PROGRA~1/Java BUILD_JDK_IMPORT_PATH = J:/re/jdk/1.7.0/promoted/latest/binaries ALT_BUILD_JDK_IMPORT_PATH = JDK_IMPORT_PATH = C:/jdk1.6 ALT_JDK_IMPORT_PATH = C:\jdk1.6 LANGTOOLS_DIST = ALT_LANGTOOLS_DIST = e:/research/open/output_amd64/langtools/dist CORBA_DIST = ALT_CORBA_DIST = e:/research/open/output_amd64/corba/dist JAXP_DIST = ALT_JAXP_DIST = e:/research/open/output_amd64/jaxp/dist JAXWS_DIST = ALT_JAXWS_DIST = e:/research/open/output_amd64/jaxws/dist HOTSPOT_DOCS_IMPORT_PATH = /NO_DOCS_DIR ALT_HOTSPOT_DOCS_IMPORT_PATH = HOTSPOT_IMPORT_PATH = E:/research/open/output_amd64/hotspot/import ALT_HOTSPOT_IMPORT_PATH = e:/research/open/output_amd64/hotspot/import HOTSPOT_SERVER_PATH = E:/research/open/output_amd64/hotspot/import/jre/bin/server ALT_HOTSPOT_SERVER_PATH = HOTSPOT_LIB_PATH = E:/research/open/output_amd64/hotspot/import/lib ALT_HOTSPOT_LIB_PATH = DXSDK_VER = 0x0900 DXSDK_PATH = E:/MICROS~1 ALT_DXSDK_PATH = E:\Microsoft DirectX SDK DXSDK_INCLUDE_PATH = E:/MICROS~1/Include ALT_DXSDK_INCLUDE_PATH = DXSDK_LIB_PATH = E:/MICROS~1/Lib/x64 ALT_DXSDK_LIB_PATH = WINDOWSSDKDIR = E:/MICROS~2/Windows/v7.1/ ALT_WINDOWSSDKDIR = RC = E:/MICROS~2/Windows/v7.1//Bin/x64/RC.Exe REBASE = E:/MICROS~2/Windows/v7.1//Bin/x64/ReBase.Exe CACERTS_FILE = ./../src/share/lib/security/cacerts ALT_CACERTS_FILE = OpenJDK-specific settings: FREETYPE_HEADERS_PATH = e:/freetype-2.4.7/include ALT_FREETYPE_HEADERS_PATH = e:/freetype-2.4.7/include FREETYPE_LIB_PATH = e:/freetype-2.4.7/objs/x64/vc2010 ALT_FREETYPE_LIB_PATH = e:/freetype-2.4.7/objs/x64/vc2010 Previous JDK Settings: PREVIOUS_RELEASE_PATH = USING-PREVIOUS_RELEASE_IMAGE ALT_PREVIOUS_RELEASE_PATH = PREVIOUS_JDK_VERSION = 1.6.0 ALT_PREVIOUS_JDK_VERSION = PREVIOUS_JDK_FILE = ALT_PREVIOUS_JDK_FILE = PREVIOUS_JRE_FILE = ALT_PREVIOUS_JRE_FILE = PREVIOUS_RELEASE_IMAGE = c:/jdk1.6 ALT_PREVIOUS_RELEASE_IMAGE = WARNING: To build Java 2 SDK 1.7.0 you need : VS2010 - link.exe version '10.00.30319.01' Specifically the Visual Studio 10 link.exe. You appear to be using Linker version '10.00.40219.01' ERROR: FreeType version 2.3.0 or higher is required. make[2]: Entering directory '/cygdrive/e/research/open/jdk7/jdk/make/tools/freetypecheck' /usr/bin/mkdir -p e:/research/open/output_amd64/btbins rm -f e:/research/open/output_amd64/btbins/freetype_versioncheck.exe C:/PROGRA~2/MICROS~1.0/Common7/Tools/../../Vc/bin/amd64/cl /nologo /c -Ie:/freetype-2.4.7/include -Ie:/freetype-2.4.7/include/freetype2 -DREQUIRED_FREETYPE_VERSION=2.3.0 -Foe:/research/open/output_amd64/btbins/freetype_versioncheck.obj freetypecheck.c freetypecheck.c C:/PROGRA~2/MICROS~1.0/Common7/Tools/../../Vc/bin/amd64/link e:/freetype-2.4.7/objs/x64/vc2010/freetype.lib /manifest /OUT:e:/research/open/output_amd64/btbins/freetype_versioncheck.exe e:/research/open/output_amd64/btbins/freetype_versioncheck.obj Microsoft (R) Incremental Linker Version 10.00.40219.01 Copyright (C) Microsoft Corporation. All rights reserved. LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol __imp_GetCommandLineA referenced in function __tmainCRTStartup LIBCMT.lib(longjmp.obj) : error LNK2019: unresolved external symbol RtlUnwindEx referenced in function longjmp LIBCMT.lib(jmpuwind.obj) : error LNK2001: unresolved external symbol RtlUnwindEx LIBCMT.lib(malloc.obj) : error LNK2019: unresolved external symbol __imp_HeapAlloc referenced in function _heap_alloc LIBCMT.lib(calloc_impl.obj) : error LNK2001: unresolved external symbol __imp_HeapAlloc LIBCMT.lib(chsize.obj) : error LNK2001: unresolved external symbol __imp_HeapAlloc LIBCMT.lib(osfinfo.obj) : error LNK2019: unresolved external symbol __imp_GetLastError referenced in function _set_osfhnd LIBCMT.lib(commit.obj) : error LNK2001: unresolved external symbol __imp_GetLastError LIBCMT.lib(open.obj) : error LNK2001: unresolved external symbol __imp_GetLastError LIBCMT.lib(chsize.obj) : error LNK2001: unresolved external symbol __imp_GetLastError LIBCMT.lib(write.obj) : error LNK2001: unresolved external symbol __imp_GetLastError LIBCMT.lib(winsig.obj) : error LNK2001: unresolved external symbol __imp_GetLastError LIBCMT.lib(rand_s.obj) : error LNK2001: unresolved external symbol __imp_GetLastError LIBCMT.lib(inithelp.obj) : error LNK2001: unresolved external symbol __imp_GetLastError LIBCMT.lib(read.obj) : error LNK2001: unresolved external symbol __imp_GetLastError LIBCMT.lib(lseek.obj) : error LNK2001: unresolved external symbol __imp_GetLastError LIBCMT.lib(wctomb.obj) : error LNK2001: unresolved external symbol __imp_GetLastError LIBCMT.lib(lseeki64.obj) : error LNK2001: unresolved external symbol __imp_GetLastError LIBCMT.lib(realloc.obj) : error LNK2001: unresolved external symbol __imp_GetLastError LIBCMT.lib(free.obj) : error LNK2001: unresolved external symbol __imp_GetLastError LIBCMT.lib(tidtable.obj) : error LNK2001: unresolved external symbol __imp_GetLastError LIBCMT.lib(close.obj) : error LNK2001: unresolved external symbol __imp_GetLastError LIBCMT.lib(realloc.obj) : error LNK2019: unresolved external symbol __imp_HeapReAlloc referenced in function realloc LIBCMT.lib(free.obj) : error LNK2019: unresolved external symbol __imp_HeapFree referenced in function free LIBCMT.lib(chsize.obj) : error LNK2001: unresolved external symbol __imp_HeapFree LIBCMT.lib(chandler.obj) : error LNK2019: unresolved external symbol __imp_RtlUnwindEx referenced in function __C_specific_handler LIBCMT.lib(_file.obj) : error LNK2019: unresolved external symbol __imp_EnterCriticalSection referenced in function _lock_file LIBCMT.lib(stream.obj) : error LNK2001: unresolved external symbol __imp_EnterCriticalSection LIBCMT.lib(mlock.obj) : error LNK2001: unresolved external symbol __imp_EnterCriticalSection LIBCMT.lib(osfinfo.obj) : error LNK2001: unresolved external symbol __imp_EnterCriticalSection LIBCMT.lib(_file.obj) : error LNK2019: unresolved external symbol __imp_LeaveCriticalSection referenced in function _unlock_file LIBCMT.lib(mlock.obj) : error LNK2001: unresolved external symbol __imp_LeaveCriticalSection LIBCMT.lib(osfinfo.obj) : error LNK2001: unresolved external symbol __imp_LeaveCriticalSection LIBCMT.lib(rand_s.obj) : error LNK2001: unresolved external symbol __imp_DecodePointer LIBCMT.lib(onexit.obj) : error LNK2001: unresolved external symbol __imp_DecodePointer LIBCMT.lib(crtmboxw.obj) : error LNK2001: unresolved external symbol __imp_DecodePointer LIBCMT.lib(outputs.obj) : error LNK2001: unresolved external symbol __imp_DecodePointer LIBCMT.lib(outputp.obj) : error LNK2001: unresolved external symbol __imp_DecodePointer LIBCMT.lib(hooks.obj) : error LNK2001: unresolved external symbol __imp_DecodePointer LIBCMT.lib(winsig.obj) : error LNK2001: unresolved external symbol __imp_DecodePointer LIBCMT.lib(output.obj) : error LNK2019: unresolved external symbol __imp_DecodePointer referenced in function _output_l LIBCMT.lib(invarg.obj) : error LNK2001: unresolved external symbol __imp_DecodePointer LIBCMT.lib(crt0dat.obj) : error LNK2001: unresolved external symbol __imp_DecodePointer LIBCMT.lib(handler.obj) : error LNK2001: unresolved external symbol __imp_DecodePointer LIBCMT.lib(invarg.obj) : error LNK2019: unresolved external symbol __imp_UnhandledExceptionFilter referenced in function _call_reportfault LIBCMT.lib(gs_report.obj) : error LNK2001: unresolved external symbol __imp_UnhandledExceptionFilter LIBCMT.lib(invarg.obj) : error LNK2019: unresolved external symbol __imp_SetUnhandledExceptionFilter referenced in function _call_reportfault LIBCMT.lib(gs_report.obj) : error LNK2001: unresolved external symbol __imp_SetUnhandledExceptionFilter LIBCMT.lib(unhandld.obj) : error LNK2001: unresolved external symbol __imp_SetUnhandledExceptionFilter LIBCMT.lib(invarg.obj) : error LNK2019: unresolved external symbol __imp_IsDebuggerPresent referenced in function _call_reportfault LIBCMT.lib(gs_report.obj) : error LNK2001: unresolved external symbol __imp_IsDebuggerPresent LIBCMT.lib(invarg.obj) : error LNK2019: unresolved external symbol RtlVirtualUnwind referenced in function _call_reportfault LIBCMT.lib(gs_report.obj) : error LNK2001: unresolved external symbol RtlVirtualUnwind LIBCMT.lib(invarg.obj) : error LNK2019: unresolved external symbol RtlLookupFunctionEntry referenced in function _call_reportfault LIBCMT.lib(gs_report.obj) : error LNK2001: unresolved external symbol RtlLookupFunctionEntry LIBCMT.lib(invarg.obj) : error LNK2019: unresolved external symbol __imp_RtlCaptureContext referenced in function _call_reportfault LIBCMT.lib(gs_report.obj) : error LNK2001: unresolved external symbol __imp_RtlCaptureContext LIBCMT.lib(crtmboxw.obj) : error LNK2001: unresolved external symbol __imp_EncodePointer LIBCMT.lib(hooks.obj) : error LNK2001: unresolved external symbol __imp_EncodePointer LIBCMT.lib(winsig.obj) : error LNK2001: unresolved external symbol __imp_EncodePointer LIBCMT.lib(rand_s.obj) : error LNK2001: unresolved external symbol __imp_EncodePointer LIBCMT.lib(onexit.obj) : error LNK2019: unresolved external symbol __imp_EncodePointer referenced in function _onexit LIBCMT.lib(invarg.obj) : error LNK2001: unresolved external symbol __imp_EncodePointer LIBCMT.lib(tidtable.obj) : error LNK2001: unresolved external symbol __imp_EncodePointer LIBCMT.lib(handler.obj) : error LNK2001: unresolved external symbol __imp_EncodePointer LIBCMT.lib(cmiscdat.obj) : error LNK2001: unresolved external symbol __imp_EncodePointer LIBCMT.lib(invarg.obj) : error LNK2019: unresolved external symbol __imp_TerminateProcess referenced in function _invoke_watson LIBCMT.lib(gs_report.obj) : error LNK2001: unresolved external symbol __imp_TerminateProcess LIBCMT.lib(invarg.obj) : error LNK2019: unresolved external symbol __imp_GetCurrentProcess referenced in function _invoke_watson LIBCMT.lib(gs_report.obj) : error LNK2001: unresolved external symbol __imp_GetCurrentProcess LIBCMT.lib(crt0dat.obj) : error LNK2019: unresolved external symbol __imp_GetProcAddress referenced in function __crtCorExitProcess LIBCMT.lib(rand_s.obj) : error LNK2001: unresolved external symbol __imp_GetProcAddress LIBCMT.lib(crtmboxw.obj) : error LNK2001: unresolved external symbol __imp_GetProcAddress LIBCMT.lib(crt0dat.obj) : error LNK2019: unresolved external symbol __imp_GetModuleHandleW referenced in function __crtCorExitProcess LIBCMT.lib(crt0dat.obj) : error LNK2019: unresolved external symbol __imp_ExitProcess referenced in function __crtExitProcess LIBCMT.lib(crt0msg.obj) : error LNK2019: unresolved external symbol __imp_WriteFile referenced in function _NMSG_WRITE LIBCMT.lib(write.obj) : error LNK2001: unresolved external symbol __imp_WriteFile LIBCMT.lib(crt0msg.obj) : error LNK2019: unresolved external symbol __imp_GetStdHandle referenced in function _NMSG_WRITE LIBCMT.lib(ioinit.obj) : error LNK2001: unresolved external symbol __imp_GetStdHandle LIBCMT.lib(crt0msg.obj) : error LNK2019: unresolved external symbol __imp_GetModuleFileNameW referenced in function _NMSG_WRITE LIBCMT.lib(stdargv.obj) : error LNK2019: unresolved external symbol __imp_GetModuleFileNameA referenced in function _setargv LIBCMT.lib(a_env.obj) : error LNK2019: unresolved external symbol __imp_FreeEnvironmentStringsW referenced in function __crtGetEnvironmentStringsA LIBCMT.lib(a_loc.obj) : error LNK2001: unresolved external symbol __imp_WideCharToMultiByte LIBCMT.lib(a_env.obj) : error LNK2019: unresolved external symbol __imp_WideCharToMultiByte referenced in function __crtGetEnvironmentStringsA LIBCMT.lib(wctomb.obj) : error LNK2001: unresolved external symbol __imp_WideCharToMultiByte LIBCMT.lib(write.obj) : error LNK2001: unresolved external symbol __imp_WideCharToMultiByte LIBCMT.lib(a_map.obj) : error LNK2001: unresolved external symbol __imp_WideCharToMultiByte LIBCMT.lib(a_env.obj) : error LNK2019: unresolved external symbol __imp_GetEnvironmentStringsW referenced in function __crtGetEnvironmentStringsA LIBCMT.lib(ioinit.obj) : error LNK2019: unresolved external symbol __imp_SetHandleCount referenced in function _ioinit LIBCMT.lib(ioinit.obj) : error LNK2019: unresolved external symbol __imp_InitializeCriticalSectionAndSpinCount referenced in function _ioinit LIBCMT.lib(stream.obj) : error LNK2001: unresolved external symbol __imp_InitializeCriticalSectionAndSpinCount LIBCMT.lib(mlock.obj) : error LNK2001: unresolved external symbol __imp_InitializeCriticalSectionAndSpinCount LIBCMT.lib(osfinfo.obj) : error LNK2001: unresolved external symbol __imp_InitializeCriticalSectionAndSpinCount LIBCMT.lib(ioinit.obj) : error LNK2019: unresolved external symbol __imp_GetFileType referenced in function _ioinit LIBCMT.lib(osfinfo.obj) : error LNK2001: unresolved external symbol __imp_GetFileType LIBCMT.lib(open.obj) : error LNK2001: unresolved external symbol __imp_GetFileType LIBCMT.lib(ioinit.obj) : error LNK2019: unresolved external symbol __imp_GetStartupInfoW referenced in function _ioinit LIBCMT.lib(ioinit.obj) : error LNK2019: unresolved external symbol __imp_DeleteCriticalSection referenced in function _ioterm LIBCMT.lib(closeall.obj) : error LNK2001: unresolved external symbol __imp_DeleteCriticalSection LIBCMT.lib(mlock.obj) : error LNK2001: unresolved external symbol __imp_DeleteCriticalSection LIBCMT.lib(tidtable.obj) : error LNK2019: unresolved external symbol __imp_FlsGetValue referenced in function __fls_getvalue LIBCMT.lib(tidtable.obj) : error LNK2019: unresolved external symbol __imp_FlsSetValue referenced in function __fls_setvalue LIBCMT.lib(tidtable.obj) : error LNK2019: unresolved external symbol __imp_FlsFree referenced in function _mtterm LIBCMT.lib(tidtable.obj) : error LNK2019: unresolved external symbol __imp_SetLastError referenced in function _getptd_noexit LIBCMT.lib(tidtable.obj) : error LNK2019: unresolved external symbol __imp_GetCurrentThreadId referenced in function _getptd_noexit LIBCMT.lib(gs_support.obj) : error LNK2001: unresolved external symbol __imp_GetCurrentThreadId LIBCMT.lib(tidtable.obj) : error LNK2019: unresolved external symbol __imp_GetCurrentThread referenced in function __threadhandle LIBCMT.lib(tidtable.obj) : error LNK2019: unresolved external symbol __imp_FlsAlloc referenced in function _mtinit LIBCMT.lib(heapinit.obj) : error LNK2019: unresolved external symbol __imp_HeapSetInformation referenced in function _heap_init LIBCMT.lib(heapinit.obj) : error LNK2019: unresolved external symbol __imp_GetVersion referenced in function _heap_init LIBCMT.lib(heapinit.obj) : error LNK2019: unresolved external symbol __imp_HeapCreate referenced in function _heap_init LIBCMT.lib(heapinit.obj) : error LNK2019: unresolved external symbol __imp_HeapDestroy referenced in function _heap_term LIBCMT.lib(gs_support.obj) : error LNK2019: unresolved external symbol __imp_QueryPerformanceCounter referenced in function __security_init_cookie LIBCMT.lib(gs_support.obj) : error LNK2019: unresolved external symbol __imp_GetTickCount referenced in function __security_init_cookie LIBCMT.lib(gs_support.obj) : error LNK2019: unresolved external symbol __imp_GetCurrentProcessId referenced in function __security_init_cookie LIBCMT.lib(gs_support.obj) : error LNK2019: unresolved external symbol __imp_GetSystemTimeAsFileTime referenced in function __security_init_cookie LIBCMT.lib(close.obj) : error LNK2019: unresolved external symbol __imp_CloseHandle referenced in function _close_nolock LIBCMT.lib(open.obj) : error LNK2001: unresolved external symbol __imp_CloseHandle LIBCMT.lib(initcon.obj) : error LNK2001: unresolved external symbol __imp_CloseHandle LIBCMT.lib(read.obj) : error LNK2019: unresolved external symbol __imp_MultiByteToWideChar referenced in function _read_nolock LIBCMT.lib(a_map.obj) : error LNK2001: unresolved external symbol __imp_MultiByteToWideChar LIBCMT.lib(a_str.obj) : error LNK2001: unresolved external symbol __imp_MultiByteToWideChar LIBCMT.lib(mbtowc.obj) : error LNK2001: unresolved external symbol __imp_MultiByteToWideChar LIBCMT.lib(read.obj) : error LNK2019: unresolved external symbol __imp_ReadFile referenced in function _read_nolock LIBCMT.lib(lseek.obj) : error LNK2019: unresolved external symbol __imp_SetFilePointer referenced in function _lseek_nolock LIBCMT.lib(lseeki64.obj) : error LNK2001: unresolved external symbol __imp_SetFilePointer LIBCMT.lib(crtheap.obj) : error LNK2019: unresolved external symbol __imp_Sleep referenced in function wait_a_bit LIBCMT.lib(mlock.obj) : error LNK2019: unresolved external symbol __imp_FatalAppExitA referenced in function _lockerr_exit LIBCMT.lib(mbctype.obj) : error LNK2019: unresolved external symbol __imp_GetCPInfo referenced in function "void __cdecl setSBUpLow(struct threadmbcinfostruct *)" (?setSBUpLow@@YAXPEAUthreadmbcinfostruct@@@Z) LIBCMT.lib(initctyp.obj) : error LNK2001: unresolved external symbol __imp_GetCPInfo LIBCMT.lib(mbctype.obj) : error LNK2019: unresolved external symbol __imp_GetACP referenced in function "int __cdecl getSystemCP(int)" (?getSystemCP@@YAHH at Z) LIBCMT.lib(getqloc.obj) : error LNK2001: unresolved external symbol __imp_GetACP LIBCMT.lib(mbctype.obj) : error LNK2019: unresolved external symbol __imp_GetOEMCP referenced in function "int __cdecl getSystemCP(int)" (?getSystemCP@@YAHH at Z) LIBCMT.lib(mbctype.obj) : error LNK2019: unresolved external symbol __imp_IsValidCodePage referenced in function _setmbcp_nolock LIBCMT.lib(getqloc.obj) : error LNK2001: unresolved external symbol __imp_IsValidCodePage LIBCMT.lib(write.obj) : error LNK2019: unresolved external symbol __imp_GetConsoleCP referenced in function _write_nolock LIBCMT.lib(write.obj) : error LNK2019: unresolved external symbol __imp_GetConsoleMode referenced in function _write_nolock LIBCMT.lib(winsig.obj) : error LNK2019: unresolved external symbol __imp_SetConsoleCtrlHandler referenced in function signal LIBCMT.lib(rand_s.obj) : error LNK2019: unresolved external symbol __imp_FreeLibrary referenced in function rand_s LIBCMT.lib(rand_s.obj) : error LNK2019: unresolved external symbol __imp_LoadLibraryW referenced in function rand_s LIBCMT.lib(crtmboxw.obj) : error LNK2001: unresolved external symbol __imp_LoadLibraryW LIBCMT.lib(inithelp.obj) : error LNK2019: unresolved external symbol __imp_GetLocaleInfoW referenced in function __getlocaleinfo LIBCMT.lib(a_loc.obj) : error LNK2001: unresolved external symbol __imp_GetLocaleInfoW LIBCMT.lib(getqloc.obj) : error LNK2001: unresolved external symbol __imp_GetLocaleInfoW LIBCMT.lib(osfinfo.obj) : error LNK2019: unresolved external symbol __imp_SetStdHandle referenced in function _set_osfhnd LIBCMT.lib(commit.obj) : error LNK2019: unresolved external symbol __imp_FlushFileBuffers referenced in function _commit LIBCMT.lib(open.obj) : error LNK2019: unresolved external symbol __imp_CreateFileA referenced in function _tsopen_nolock LIBCMT.lib(a_map.obj) : error LNK2019: unresolved external symbol __imp_LCMapStringW referenced in function "int __cdecl __crtLCMapStringA_stat(struct localeinfo_struct *,unsigned long,unsigned long,char const *,int,char *,int,int,int)" (?__crtLCMapStringA_stat@@YAHPEAUlocaleinfo_struct@@KKPEBDHPEADHHH at Z) LIBCMT.lib(a_str.obj) : error LNK2019: unresolved external symbol __imp_GetStringTypeW referenced in function "int __cdecl __crtGetStringTypeA_stat(struct localeinfo_struct *,unsigned long,char const *,int,unsigned short *,int,int,int)" (?__crtGetStringTypeA_stat@@YAHPEAUlocaleinfo_struct@@KPEBDHPEAGHHH at Z) LIBCMT.lib(iswctype.obj) : error LNK2001: unresolved external symbol __imp_GetStringTypeW LIBCMT.lib(putwch.obj) : error LNK2019: unresolved external symbol __imp_WriteConsoleW referenced in function _putwch_nolock LIBCMT.lib(msize.obj) : error LNK2019: unresolved external symbol __imp_HeapSize referenced in function _msize LIBCMT.lib(chsize.obj) : error LNK2019: unresolved external symbol __imp_SetEndOfFile referenced in function _chsize_nolock LIBCMT.lib(chsize.obj) : error LNK2019: unresolved external symbol __imp_GetProcessHeap referenced in function _chsize_nolock LIBCMT.lib(getqloc.obj) : error LNK2019: unresolved external symbol __imp_GetUserDefaultLCID referenced in function GetLcidFromDefault LIBCMT.lib(getqloc.obj) : error LNK2019: unresolved external symbol __imp_GetLocaleInfoA referenced in function CountryEnumProc LIBCMT.lib(getqloc.obj) : error LNK2019: unresolved external symbol __imp_EnumSystemLocalesA referenced in function GetLcidFromCountry LIBCMT.lib(getqloc.obj) : error LNK2019: unresolved external symbol __imp_IsValidLocale referenced in function __get_qualified_locale LIBCMT.lib(initcon.obj) : error LNK2019: unresolved external symbol __imp_CreateFileW referenced in function __initconout e:/research/open/output_amd64/btbins/freetype_versioncheck.exe : fatal error LNK1120: 79 unresolved externals Makefile:68: recipe for target 'e:/research/open/output_amd64/btbins/freetype_versioncheck.exe' failed make[2]: Leaving directory '/cygdrive/e/research/open/jdk7/jdk/make/tools/freetypecheck' Failed to build freetypecheck. Exiting because of the above error(s). make/sanity-rules.gmk:71: recipe for target 'post-sanity' failed make: *** [post-sanity] Error 1 ------ and this is my command: --- make ARCH_DATA_MODEL=64 \ ALT_OUTPUTDIR=e:/research/open/output_amd64 \ ALT_FREETYPE_LIB_PATH=e:/freetype-2.4.7/objs/x64/vc2010 \ ALT_FREETYPE_HEADERS_PATH=e:/freetype-2.4.7/include \ ALT_BOOTDIR=c:/jdk1.6 \ ALT_DROPS_DIR=e:/research/open/ALT_DROPS_DIR \ ALT_MSVCRNN_DLL_PATH=e:/research/jdkBuild/msvcr100 \ HOTSPOT_BUILD_JOBS=4 \ PARALLEL_COMPILE_JOBS=4 \ 2>&1 | tee e:/research/open/output_amd64.log From claes.redestad at oracle.com Wed Jul 1 14:54:55 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 01 Jul 2015 16:54:55 +0200 Subject: RFR: 8081589: Output of -XX:+TraceClassLoadingPreorder in JDK9 incompatible with MakeClasslist tool Message-ID: <5593FF3F.2040501@oracle.com> Hi, please review this rewrite/cleanup of the MakeClasslist tool to operate on the output of -XX:DumpLoadedClassList rather than -XX:+TraceClassLoadingPreorder. Since the tool became rather trivial I opted to write it in nashorn-compliant javascript to streamline the usage. Bug: https://bugs.openjdk.java.net/browse/JDK-8081589 Webrev: http://cr.openjdk.java.net/~redestad/8081589/webrev.02 A number of undocumented/unused tests were removed and an outdated README was incorporated into the tool source itself, among other things clarifying that the checksum needs to be calculated and added to the classlist before checking it into the workspace. I've asked around about how to go about adding tests for standalone tools like these, but didn't come up with a good answer. If someone insists I add a small test to this I'd hope there's some insight into how best to do that (shell-based jtreg test?) Thanks! /Claes From ioi.lam at oracle.com Wed Jul 1 20:44:06 2015 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 01 Jul 2015 13:44:06 -0700 Subject: RFR: 8081589: Output of -XX:+TraceClassLoadingPreorder in JDK9 incompatible with MakeClasslist tool In-Reply-To: <5593FF3F.2040501@oracle.com> References: <5593FF3F.2040501@oracle.com> Message-ID: <55945116.20102@oracle.com> Claes, The changes look good to me. It's nice to replace a large amount of Java code with a simple script. How about doing the line splitting like this: var classes = readFully(arg).replace(/[\r\n]+/g, "\n").split("\n") That way it will be able to handle an input file that have a mixture of newline characters (e.g., if someone has edited a Unix text file on a Windows editor). Thanks - Ioi On 7/1/15 7:54 AM, Claes Redestad wrote: > Hi, > > please review this rewrite/cleanup of the MakeClasslist tool to > operate on the output of > -XX:DumpLoadedClassList rather than -XX:+TraceClassLoadingPreorder. > Since the tool > became rather trivial I opted to write it in nashorn-compliant > javascript to streamline > the usage. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8081589 > Webrev: http://cr.openjdk.java.net/~redestad/8081589/webrev.02 > > A number of undocumented/unused tests were removed and an outdated > README was > incorporated into the tool source itself, among other things > clarifying that the checksum > needs to be calculated and added to the classlist before checking it > into the workspace. > > I've asked around about how to go about adding tests for standalone > tools like these, but > didn't come up with a good answer. If someone insists I add a small > test to this I'd hope > there's some insight into how best to do that (shell-based jtreg test?) > > Thanks! > > /Claes From volker.simonis at gmail.com Thu Jul 2 08:11:03 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 2 Jul 2015 10:11:03 +0200 Subject: RFR(XXS): 8130303: Fix bogus check for libX11.so in libraries.m4 Message-ID: Hi, could somebody please sponsor this tiny fix contributed by Matthias Baesken (it requires the re-generation of the closed generated-configure.sh): http://cr.openjdk.java.net/~simonis/webrevs/2015/8130303/ https://bugs.openjdk.java.net/browse/JDK-8130303 Thank you and best regards, Volker From erik.joelsson at oracle.com Thu Jul 2 09:09:53 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 02 Jul 2015 11:09:53 +0200 Subject: RFR(XXS): 8130303: Fix bogus check for libX11.so in libraries.m4 In-Reply-To: References: Message-ID: <5594FFE1.1060405@oracle.com> Hello Volker, I will take it, thanks for the fix! /Erik On 2015-07-02 10:11, Volker Simonis wrote: > Hi, > > could somebody please sponsor this tiny fix contributed by Matthias > Baesken (it requires the re-generation of the closed > generated-configure.sh): > > http://cr.openjdk.java.net/~simonis/webrevs/2015/8130303/ > https://bugs.openjdk.java.net/browse/JDK-8130303 > > Thank you and best regards, > Volker From claes.redestad at oracle.com Thu Jul 2 14:12:10 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 02 Jul 2015 16:12:10 +0200 Subject: RFR: 8081589: Output of -XX:+TraceClassLoadingPreorder in JDK9 incompatible with MakeClasslist tool In-Reply-To: <55945116.20102@oracle.com> References: <5593FF3F.2040501@oracle.com> <55945116.20102@oracle.com> Message-ID: <559546BA.30701@oracle.com> Hi Ioi, On 2015-07-01 22:44, Ioi Lam wrote: > Claes, > > The changes look good to me. It's nice to replace a large amount of > Java code with a simple script. > > How about doing the line splitting like this: > > var classes = readFully(arg).replace(/[\r\n]+/g, "\n").split("\n") > > That way it will be able to handle an input file that have a mixture > of newline characters (e.g., if someone has edited a Unix text file on > a Windows editor). Sure thing, this also makes the script more concise: http://cr.openjdk.java.net/~redestad/8081589/webrev.03/ Thanks! /Claes > > Thanks > - Ioi > > On 7/1/15 7:54 AM, Claes Redestad wrote: >> Hi, >> >> please review this rewrite/cleanup of the MakeClasslist tool to >> operate on the output of >> -XX:DumpLoadedClassList rather than -XX:+TraceClassLoadingPreorder. >> Since the tool >> became rather trivial I opted to write it in nashorn-compliant >> javascript to streamline >> the usage. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8081589 >> Webrev: http://cr.openjdk.java.net/~redestad/8081589/webrev.02 >> >> A number of undocumented/unused tests were removed and an outdated >> README was >> incorporated into the tool source itself, among other things >> clarifying that the checksum >> needs to be calculated and added to the classlist before checking it >> into the workspace. >> >> I've asked around about how to go about adding tests for standalone >> tools like these, but >> didn't come up with a good answer. If someone insists I add a small >> test to this I'd hope >> there's some insight into how best to do that (shell-based jtreg test?) >> >> Thanks! >> >> /Claes > From ioi.lam at oracle.com Thu Jul 2 18:07:58 2015 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 02 Jul 2015 11:07:58 -0700 Subject: RFR: 8081589: Output of -XX:+TraceClassLoadingPreorder in JDK9 incompatible with MakeClasslist tool In-Reply-To: <559546BA.30701@oracle.com> References: <5593FF3F.2040501@oracle.com> <55945116.20102@oracle.com> <559546BA.30701@oracle.com> Message-ID: <55957DFE.2050300@oracle.com> Looks good! Thanks - Ioi On 7/2/15 7:12 AM, Claes Redestad wrote: > Hi Ioi, > > On 2015-07-01 22:44, Ioi Lam wrote: >> Claes, >> >> The changes look good to me. It's nice to replace a large amount of >> Java code with a simple script. >> >> How about doing the line splitting like this: >> >> var classes = readFully(arg).replace(/[\r\n]+/g, "\n").split("\n") >> >> That way it will be able to handle an input file that have a mixture >> of newline characters (e.g., if someone has edited a Unix text file >> on a Windows editor). > > Sure thing, this also makes the script more concise: > > http://cr.openjdk.java.net/~redestad/8081589/webrev.03/ > > Thanks! > > /Claes > >> >> Thanks >> - Ioi >> >> On 7/1/15 7:54 AM, Claes Redestad wrote: >>> Hi, >>> >>> please review this rewrite/cleanup of the MakeClasslist tool to >>> operate on the output of >>> -XX:DumpLoadedClassList rather than -XX:+TraceClassLoadingPreorder. >>> Since the tool >>> became rather trivial I opted to write it in nashorn-compliant >>> javascript to streamline >>> the usage. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8081589 >>> Webrev: http://cr.openjdk.java.net/~redestad/8081589/webrev.02 >>> >>> A number of undocumented/unused tests were removed and an outdated >>> README was >>> incorporated into the tool source itself, among other things >>> clarifying that the checksum >>> needs to be calculated and added to the classlist before checking it >>> into the workspace. >>> >>> I've asked around about how to go about adding tests for standalone >>> tools like these, but >>> didn't come up with a good answer. If someone insists I add a small >>> test to this I'd hope >>> there's some insight into how best to do that (shell-based jtreg test?) >>> >>> Thanks! >>> >>> /Claes >> > From david.holmes at oracle.com Mon Jul 6 09:10:56 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 6 Jul 2015 19:10:56 +1000 Subject: (XXS)RFR: 8076581: Need a NON-PCH build to quickly detect missing dependencies in the source base Message-ID: <559A4620.2070600@oracle.com> webrev: http://cr.openjdk.java.net/~dholmes/8076581/webrev/ In response to the discussions in: http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/017826.html I'm now in a position to add No-PCH builds to the set of JPRT builds. I've simply disabled PCH for fastdebug builds. This isn't complete in terms of coverage but is a reasonable compromise I think. Disabling PCH had no adverse affects on the build times in JPRT. Thanks, David From goetz.lindenmaier at sap.com Mon Jul 6 09:30:36 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 6 Jul 2015 09:30:36 +0000 Subject: (XXS)RFR: 8076581: Need a NON-PCH build to quickly detect missing dependencies in the source base In-Reply-To: <559A4620.2070600@oracle.com> References: <559A4620.2070600@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2D001D1A@DEWDFEMB12A.global.corp.sap> Hi David, this change is good, I appreciate it a lot! Best regards, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of David Holmes Sent: Montag, 6. Juli 2015 11:11 To: hotspot-dev developers; build-dev Subject: (XXS)RFR: 8076581: Need a NON-PCH build to quickly detect missing dependencies in the source base webrev: http://cr.openjdk.java.net/~dholmes/8076581/webrev/ In response to the discussions in: http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/017826.html I'm now in a position to add No-PCH builds to the set of JPRT builds. I've simply disabled PCH for fastdebug builds. This isn't complete in terms of coverage but is a reasonable compromise I think. Disabling PCH had no adverse affects on the build times in JPRT. Thanks, David From tim.bell at oracle.com Mon Jul 6 13:44:08 2015 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 06 Jul 2015 06:44:08 -0700 Subject: (XXS)RFR: 8076581: Need a NON-PCH build to quickly detect missing dependencies in the source base In-Reply-To: <4295855A5C1DE049A61835A1887419CC2D001D1A@DEWDFEMB12A.global.corp.sap> References: <559A4620.2070600@oracle.com> <4295855A5C1DE049A61835A1887419CC2D001D1A@DEWDFEMB12A.global.corp.sap> Message-ID: <559A8628.8070901@oracle.com> David - Looks good to me as well. Tim On 07/06/15 02:30, Lindenmaier, Goetz wrote: > Hi David, > > this change is good, I appreciate it a lot! > > Best regards, > Goetz. > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of David Holmes > Sent: Montag, 6. Juli 2015 11:11 > To: hotspot-dev developers; build-dev > Subject: (XXS)RFR: 8076581: Need a NON-PCH build to quickly detect missing dependencies in the source base > > webrev: http://cr.openjdk.java.net/~dholmes/8076581/webrev/ > > In response to the discussions in: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/017826.html > > I'm now in a position to add No-PCH builds to the set of JPRT builds. > I've simply disabled PCH for fastdebug builds. This isn't complete in > terms of coverage but is a reasonable compromise I think. Disabling PCH > had no adverse affects on the build times in JPRT. > > Thanks, > David > From volker.simonis at gmail.com Mon Jul 6 13:48:33 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 6 Jul 2015 15:48:33 +0200 Subject: (XXS)RFR: 8076581: Need a NON-PCH build to quickly detect missing dependencies in the source base In-Reply-To: <559A4620.2070600@oracle.com> References: <559A4620.2070600@oracle.com> Message-ID: +1 Volker On Mon, Jul 6, 2015 at 11:10 AM, David Holmes wrote: > webrev: http://cr.openjdk.java.net/~dholmes/8076581/webrev/ > > In response to the discussions in: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/017826.html > > I'm now in a position to add No-PCH builds to the set of JPRT builds. I've > simply disabled PCH for fastdebug builds. This isn't complete in terms of > coverage but is a reasonable compromise I think. Disabling PCH had no > adverse affects on the build times in JPRT. > > Thanks, > David > From daniel.daugherty at oracle.com Mon Jul 6 14:02:59 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 06 Jul 2015 08:02:59 -0600 Subject: (XXS)RFR: 8076581: Need a NON-PCH build to quickly detect missing dependencies in the source base In-Reply-To: <559A4620.2070600@oracle.com> References: <559A4620.2070600@oracle.com> Message-ID: <559A8A93.7030100@oracle.com> On 7/6/15 3:10 AM, David Holmes wrote: > webrev: http://cr.openjdk.java.net/~dholmes/8076581/webrev/ make/jprt.properties No comments. Thumbs up. Dan > > In response to the discussions in: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/017826.html > > I'm now in a position to add No-PCH builds to the set of JPRT builds. > I've simply disabled PCH for fastdebug builds. This isn't complete in > terms of coverage but is a reasonable compromise I think. Disabling > PCH had no adverse affects on the build times in JPRT. > > Thanks, > David > From steve.drach at oracle.com Tue Jul 7 18:53:14 2015 From: steve.drach at oracle.com (Steve Drach) Date: Tue, 7 Jul 2015 11:53:14 -0700 Subject: Error: SPEC mismatch! Current working directory does not match either TOPDIR, ORIGINAL_TOPDIR or CANONICAL_TOPDIR Message-ID: <15E54A68-26D8-46A2-B446-42CC49859C5C@oracle.com> I ran across this error when I accidentally did $ cd JDK9 instead of $ cd jdk9 No matter what I did, cd?ing in/out of directory again, blowing away build/* and starting over, etc., I could not get it to forget the upper case JDK9. And I couldn?t find that string in any file anywhere (at least any relevant file). I tried mv?ing the top level directory to jdk9-bad, but then I got other makefile errors. But then I mv?ed it back to jdk9 and voila! I could build again. Clearly magical. BTW, I?m running OS X 10.10.4 From joe.darcy at oracle.com Tue Jul 7 21:09:50 2015 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 07 Jul 2015 14:09:50 -0700 Subject: JDK 9 RFR of JDK-8080722: Revisit how to check for doclint reference warning during the build In-Reply-To: <5591999C.8070707@oracle.com> References: <5591999C.8070707@oracle.com> Message-ID: <559C401E.7020300@oracle.com> *ping* Thanks, -Joe On 6/29/2015 12:16 PM, joe darcy wrote: > Hello, > > A fix for > > JDK-8129909: Add -Xdoclint/packages: to javadoc > https://bugs.openjdk.java.net/browse/JDK-8129909 > > is working its way through the system, in anticipation of that fix, > please view my fix for > > JDK-8080722: Revisit how to check for doclint reference warning > during the build > > Patch below: > > --- a/make/Javadoc.gmk Tue Jun 23 15:11:56 2015 +0200 > +++ b/make/Javadoc.gmk Mon Jun 29 12:11:03 2015 -0700 > @@ -410,7 +410,8 @@ > $(prep-target) > @($(call COMMON_JAVADOCFLAGS) ; \ > $(call COMMON_JAVADOCTAGS) ; \ > - $(call OptionOnly,-Xdoclint:none) ; \ > + $(call OptionOnly,-Xdoclint:reference) ; \ > + $(call OptionOnly,-Xdoclint/package:-org.omg.*) ; \ > $(call OptionPair,-sourcepath,$(RELEASEDOCS_SOURCEPATH)) ; \ > $(call OptionPair,-encoding,ISO-8859-1) ; \ > $(call OptionOnly,-splitIndex) ; \ > > As discussed on jdk9-dev, this fix will allow JEP 212 to be completed. > > http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-June/002343.html > > Just to be clear, I would not push the fix for JDK-8080722 until the > fix for JDK-8080722 is in the jdk 9 dev forest. Additionally, I'll > verify the build still works at that point with the patch above. > > Thanks, > > -Joe From medi.montaseri at hds.com Tue Jul 7 21:16:12 2015 From: medi.montaseri at hds.com (Medi Montaseri) Date: Tue, 7 Jul 2015 21:16:12 +0000 Subject: how to strip builder username from libjvm.so Message-ID: <559C419C.3060206@hds.com> Hi, I build openjdk from source on Debian and CentOs. All is well, except we noted that lib/amd64/server/libjvm.so has got a trace of the builder as in mmontaseri at shiraz:/tmp/ramesh2> strings lib/amd64/server/libjvm.so | grep 'built on' OpenJDK 64-Bit Server VM (25.20-b23) for linux-amd64 JRE (1.8.0-jdk8u20-b26-20141204-HDS-193206), built on Dec 4 2014 19:35:25 by "mmontaseri" with gcc 4.7.2 Is there anyway to strip builder's id "mmontaseri". Tomcat is writing that to its log, hence publicly visable. Here is portion of build script my $cmd = 'bash ./configure '; $cmd .= ' --disable-headful'; $cmd .= ' --with-user-release-suffix=HDS'; $cmd .= ' --with-build-number=' . $this->getBuildNumber(); $cmd .= ' --disable-debug-symbols'; $cmd .= ' --disable-zip-debug-info'; $cmd .= ' --with-milestone=' . $mileStone; $cmd .= " --with-jtreg=$jtHome"; # eg. /opt/jtreg/jtreg4.1-b07 $cmd .= " --with-boot-jdk=$bootJDK"; # eg. /usr/lib/jvm/java-7-openjdk-amd64 $cmd .= " --prefix=$installDir"; print "Running [$cmd]...\n"; Thanks Medi From david.holmes at oracle.com Tue Jul 7 22:07:42 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 8 Jul 2015 08:07:42 +1000 Subject: how to strip builder username from libjvm.so In-Reply-To: <559C419C.3060206@hds.com> References: <559C419C.3060206@hds.com> Message-ID: <559C4DAE.6010809@oracle.com> On 8/07/2015 7:16 AM, Medi Montaseri wrote: > Hi, > > I build openjdk from source on Debian and CentOs. > All is well, except we noted that lib/amd64/server/libjvm.so has got a trace of the builder as in > > mmontaseri at shiraz:/tmp/ramesh2> strings lib/amd64/server/libjvm.so | grep 'built on' > OpenJDK 64-Bit Server VM (25.20-b23) for linux-amd64 JRE (1.8.0-jdk8u20-b26-20141204-HDS-193206), built on Dec 4 2014 19:35:25 by "mmontaseri" with gcc 4.7.2 > > Is there anyway to strip builder's id "mmontaseri". Tomcat is writing that to its log, hence publicly visable. This is done inside the hotspot makefiles, which only partially interact with configure settings. Try setting HOTSPOT_BUILD_USER=unknown in the environment when doing the build. David > Here is portion of build script > > my $cmd = 'bash ./configure '; > $cmd .= ' --disable-headful'; > $cmd .= ' --with-user-release-suffix=HDS'; > $cmd .= ' --with-build-number=' . $this->getBuildNumber(); > $cmd .= ' --disable-debug-symbols'; > $cmd .= ' --disable-zip-debug-info'; > $cmd .= ' --with-milestone=' . $mileStone; > $cmd .= " --with-jtreg=$jtHome"; # eg. /opt/jtreg/jtreg4.1-b07 > $cmd .= " --with-boot-jdk=$bootJDK"; # eg. /usr/lib/jvm/java-7-openjdk-amd64 > $cmd .= " --prefix=$installDir"; > print "Running [$cmd]...\n"; > > Thanks > Medi > From medi.montaseri at hds.com Tue Jul 7 22:17:44 2015 From: medi.montaseri at hds.com (Medi Montaseri) Date: Tue, 7 Jul 2015 22:17:44 +0000 Subject: how to strip builder username from libjvm.so In-Reply-To: <559C4DAE.6010809@oracle.com> References: <559C419C.3060206@hds.com> <559C4DAE.6010809@oracle.com> Message-ID: <559C5007.30207@hds.com> Thanks for the quick reply David....will give it a try and report back. Medi On 07/07/2015 03:07 PM, David Holmes wrote: On 8/07/2015 7:16 AM, Medi Montaseri wrote: Hi, I build openjdk from source on Debian and CentOs. All is well, except we noted that lib/amd64/server/libjvm.so has got a trace of the builder as in mmontaseri at shiraz:/tmp/ramesh2> strings lib/amd64/server/libjvm.so | grep 'built on' OpenJDK 64-Bit Server VM (25.20-b23) for linux-amd64 JRE (1.8.0-jdk8u20-b26-20141204-HDS-193206), built on Dec 4 2014 19:35:25 by "mmontaseri" with gcc 4.7.2 Is there anyway to strip builder's id "mmontaseri". Tomcat is writing that to its log, hence publicly visable. This is done inside the hotspot makefiles, which only partially interact with configure settings. Try setting HOTSPOT_BUILD_USER=unknown in the environment when doing the build. David Here is portion of build script my $cmd = 'bash ./configure '; $cmd .= ' --disable-headful'; $cmd .= ' --with-user-release-suffix=HDS'; $cmd .= ' --with-build-number=' . $this->getBuildNumber(); $cmd .= ' --disable-debug-symbols'; $cmd .= ' --disable-zip-debug-info'; $cmd .= ' --with-milestone=' . $mileStone; $cmd .= " --with-jtreg=$jtHome"; # eg. /opt/jtreg/jtreg4.1-b07 $cmd .= " --with-boot-jdk=$bootJDK"; # eg. /usr/lib/jvm/java-7-openjdk-amd64 $cmd .= " --prefix=$installDir"; print "Running [$cmd]...\n"; Thanks Medi From jonathan.gibbons at oracle.com Tue Jul 7 22:35:55 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 07 Jul 2015 15:35:55 -0700 Subject: "make clean" compiles files. Message-ID: <559C544B.2030409@oracle.com> It is mildly surprising to see that "make clean" starts by compiling some files. $ make clean Compiling 5 files for BUILD_GENMODULESLIST -- Jon From Alan.Bateman at oracle.com Wed Jul 8 08:33:30 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 08 Jul 2015 09:33:30 +0100 Subject: JDK 9 RFR of JDK-8080722: Revisit how to check for doclint reference warning during the build In-Reply-To: <559C401E.7020300@oracle.com> References: <5591999C.8070707@oracle.com> <559C401E.7020300@oracle.com> Message-ID: <559CE05A.2050004@oracle.com> On 07/07/2015 22:09, joe darcy wrote: > *ping* > >> >> Patch below: >> >> --- a/make/Javadoc.gmk Tue Jun 23 15:11:56 2015 +0200 >> +++ b/make/Javadoc.gmk Mon Jun 29 12:11:03 2015 -0700 >> @@ -410,7 +410,8 @@ >> $(prep-target) >> @($(call COMMON_JAVADOCFLAGS) ; \ >> $(call COMMON_JAVADOCTAGS) ; \ >> - $(call OptionOnly,-Xdoclint:none) ; \ >> + $(call OptionOnly,-Xdoclint:reference) ; \ >> + $(call OptionOnly,-Xdoclint/package:-org.omg.*) ; \ >> $(call OptionPair,-sourcepath,$(RELEASEDOCS_SOURCEPATH)) ; \ >> $(call OptionPair,-encoding,ISO-8859-1) ; \ >> $(call OptionOnly,-splitIndex) ; \ >> >> As discussed on jdk9-dev, this fix will allow JEP 212 to be completed. This looks okay to me. -Alan. From florian.gauvin at nl.thalesgroup.com Wed Jul 8 11:45:05 2015 From: florian.gauvin at nl.thalesgroup.com (GAUVIN Florian) Date: Wed, 8 Jul 2015 11:45:05 +0000 Subject: Openjdk profiles Message-ID: <5FD223E653528046A87219078E495127E8FAD0@spvw1967.ONE-05.GRP> Hi, For a project I have to build OpenJDK with buildroot. The goal is to have an image as small as possible. So my question is, does there is a make option to build only one compact profile (compact1, compact2 or compact3) of Openjdk. Regards, Gauvin Florian ------------------------------------------------------------------------------------------------------------ Disclaimer: If you are not the intended recipient of this email, please notify the sender and delete it. Any unauthorized copying, disclosure or distribution of this email or its attachment(s) is forbidden. Thales Nederland BV will not accept liability for any damage caused by this email or its attachment(s). Thales Nederland BV is seated in Hengelo and is registered at the Chamber of Commerce under number 06061578. ------------------------------------------------------------------------------------------------------------ From Alan.Bateman at oracle.com Wed Jul 8 11:48:25 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 08 Jul 2015 12:48:25 +0100 Subject: Openjdk profiles In-Reply-To: <5FD223E653528046A87219078E495127E8FAD0@spvw1967.ONE-05.GRP> References: <5FD223E653528046A87219078E495127E8FAD0@spvw1967.ONE-05.GRP> Message-ID: <559D0E09.5060902@oracle.com> On 08/07/2015 12:45, GAUVIN Florian wrote: > Hi, > For a project I have to build OpenJDK with buildroot. The goal is to have an image as small as possible. So my question is, does there is a make option to build only one compact profile (compact1, compact2 or compact3) of Openjdk. > Regards, > Gauvin Florian > Not currently but it would be hard to patch the make files to just build a specific compact profile image if you wanted. Once we get support for modules into JDK 9 then you will have the linker tool to try as this will allow you to create run-time images with the minimum set of modules that you want to include. -Alan. From david.holmes at oracle.com Wed Jul 8 12:33:35 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 8 Jul 2015 22:33:35 +1000 Subject: "make clean" compiles files. In-Reply-To: <559C544B.2030409@oracle.com> References: <559C544B.2030409@oracle.com> Message-ID: <559D189F.5010009@oracle.com> On 8/07/2015 8:35 AM, Jonathan Gibbons wrote: > It is mildly surprising to see that "make clean" starts by compiling > some files. > > $ make clean > Compiling 5 files for BUILD_GENMODULESLIST Yep - even "make nosuchthing" does the same thing. The reason, as previously explained to me, is that there has to be some processing to determine the set of valid make targets. David > -- Jon From david.holmes at oracle.com Wed Jul 8 12:35:26 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 8 Jul 2015 22:35:26 +1000 Subject: Openjdk profiles In-Reply-To: <5FD223E653528046A87219078E495127E8FAD0@spvw1967.ONE-05.GRP> References: <5FD223E653528046A87219078E495127E8FAD0@spvw1967.ONE-05.GRP> Message-ID: <559D190E.9060608@oracle.com> On 8/07/2015 9:45 PM, GAUVIN Florian wrote: > Hi, > For a project I have to build OpenJDK with buildroot. The goal is to have an image as small as possible. So my question is, does there is a make option to build only one compact profile (compact1, compact2 or compact3) of Openjdk. > Regards, You can't build just one profile (without hacking the makefiles). "make profiles" will make all three and then you just take the image you want. David > Gauvin Florian > > > ------------------------------------------------------------------------------------------------------------ > Disclaimer: > > If you are not the intended recipient of this email, please notify the sender and > delete it. > Any unauthorized copying, disclosure or distribution of this email or its > attachment(s) is forbidden. > Thales Nederland BV will not accept liability for any damage caused by this email or > its attachment(s). > Thales Nederland BV is seated in Hengelo and is registered at the Chamber of > Commerce under number 06061578. > ------------------------------------------------------------------------------------------------------------ > From magnus.ihse.bursie at oracle.com Wed Jul 8 13:19:11 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 8 Jul 2015 15:19:11 +0200 Subject: "make clean" compiles files. In-Reply-To: <559C544B.2030409@oracle.com> References: <559C544B.2030409@oracle.com> Message-ID: This is a temporary solution which hopefully goes away when we get rid of modules.xml. /Magnus > 8 jul 2015 kl. 00:35 skrev Jonathan Gibbons : > > It is mildly surprising to see that "make clean" starts by compiling some files. > > $ make clean > Compiling 5 files for BUILD_GENMODULESLIST > > -- Jon From Alan.Bateman at oracle.com Wed Jul 8 13:20:52 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 08 Jul 2015 14:20:52 +0100 Subject: "make clean" compiles files. In-Reply-To: References: <559C544B.2030409@oracle.com> Message-ID: <559D23B4.7090209@oracle.com> On 08/07/2015 14:19, Magnus Ihse Bursie wrote: > This is a temporary solution which hopefully goes away when we get rid of modules.xml. > > and modules.xml will go away when we bring in the module system. -Alan From henry.jen at oracle.com Fri Jul 10 03:48:28 2015 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 9 Jul 2015 20:48:28 -0700 Subject: RFR - 8027634: Support @argfiles for java command-line tool Message-ID: Hi, Please review proposed patch for JDK-8027634[1]. This patch is to enable java support command line argument file like javac does. The implementation use the same syntax rule, which is implemented in CommandLine.java[3] with java.io.StreamTokenizer. Some early comment is that we probably don?t need such complexity to support same syntax, also require to quote whole token is a little inconvenient. For example, must be -cp ?c:\\foo bar\\lib;c:\\lib? instead of -cp c:\?foo bar?\lib;c:\lib. I am debating if such compatibility is necessary useful, after all, easy and intuitive is more important, and with simpler rule, the implementation will be cleaner as well. Anyhow, with the patch out, at least developer can build idk and have something to test with to see if this can fulfill their use cases. Also, for tools other than java that use launcher, it?s possible to use -J at argfile to pass arguments. For example, if want to pass -J options to javac, it?s now possible to do so with javac -J at argfile, and put -J options in the argfile. If the consensus is that such syntax compatibility is not important, we will go ahead remove the escaping support(except probably enable escape for quote itself) in quote, and maybe add support of quote within a token. CCing build-dev for build changes, jdk9-dev for wider audience for tools. Cheers, Henry [1] https://bugs.openjdk.java.net/browse/JDK-8027634 [2] http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javac.html#commandlineargfile [3] http://hg.openjdk.java.net/jdk9/jdk9/langtools/file/03e083639ee9/src/jdk.compiler/share/classes/com/sun/tools/javac/main/CommandLine.java From henry.jen at oracle.com Fri Jul 10 03:50:24 2015 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 9 Jul 2015 20:50:24 -0700 Subject: RFR - 8027634: Support @argfiles for java command-line tool In-Reply-To: References: Message-ID: Sigh, forgot the link to the webrev again. http://cr.openjdk.java.net/~henryjen/jdk9/8027634/webrev/ Cheers, Henry > On Jul 9, 2015, at 8:48 PM, Henry Jen wrote: > > Hi, > > Please review proposed patch for JDK-8027634[1]. This patch is to enable java support command line argument file like javac does. The implementation use the same syntax rule, which is implemented in CommandLine.java[3] with java.io.StreamTokenizer. > > Some early comment is that we probably don?t need such complexity to support same syntax, also require to quote whole token is a little inconvenient. For example, must be -cp ?c:\\foo bar\\lib;c:\\lib? instead of -cp c:\?foo bar?\lib;c:\lib. > > I am debating if such compatibility is necessary useful, after all, easy and intuitive is more important, and with simpler rule, the implementation will be cleaner as well. > > Anyhow, with the patch out, at least developer can build idk and have something to test with to see if this can fulfill their use cases. > > Also, for tools other than java that use launcher, it?s possible to use -J at argfile to pass arguments. For example, if want to pass -J options to javac, it?s now possible to do so with javac -J at argfile, and put -J options in the argfile. > > If the consensus is that such syntax compatibility is not important, we will go ahead remove the escaping support(except probably enable escape for quote itself) in quote, and maybe add support of quote within a token. > > CCing build-dev for build changes, jdk9-dev for wider audience for tools. > > Cheers, > Henry > > [1] https://bugs.openjdk.java.net/browse/JDK-8027634 > [2] http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javac.html#commandlineargfile > [3] http://hg.openjdk.java.net/jdk9/jdk9/langtools/file/03e083639ee9/src/jdk.compiler/share/classes/com/sun/tools/javac/main/CommandLine.java From magnus.ihse.bursie at oracle.com Mon Jul 13 14:01:00 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 13 Jul 2015 16:01:00 +0200 Subject: RFR - 8027634: Support @argfiles for java command-line tool In-Reply-To: References: Message-ID: Build changes look fine. /Magnus > 10 jul 2015 kl. 05:50 skrev Henry Jen : > > Sigh, forgot the link to the webrev again. > > http://cr.openjdk.java.net/~henryjen/jdk9/8027634/webrev/ > > Cheers, > Henry > >> On Jul 9, 2015, at 8:48 PM, Henry Jen wrote: >> >> Hi, >> >> Please review proposed patch for JDK-8027634[1]. This patch is to enable java support command line argument file like javac does. The implementation use the same syntax rule, which is implemented in CommandLine.java[3] with java.io.StreamTokenizer. >> >> Some early comment is that we probably don?t need such complexity to support same syntax, also require to quote whole token is a little inconvenient. For example, must be -cp ?c:\\foo bar\\lib;c:\\lib? instead of -cp c:\?foo bar?\lib;c:\lib. >> >> I am debating if such compatibility is necessary useful, after all, easy and intuitive is more important, and with simpler rule, the implementation will be cleaner as well. >> >> Anyhow, with the patch out, at least developer can build idk and have something to test with to see if this can fulfill their use cases. >> >> Also, for tools other than java that use launcher, it?s possible to use -J at argfile to pass arguments. For example, if want to pass -J options to javac, it?s now possible to do so with javac -J at argfile, and put -J options in the argfile. >> >> If the consensus is that such syntax compatibility is not important, we will go ahead remove the escaping support(except probably enable escape for quote itself) in quote, and maybe add support of quote within a token. >> >> CCing build-dev for build changes, jdk9-dev for wider audience for tools. >> >> Cheers, >> Henry >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8027634 >> [2] http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javac.html#commandlineargfile >> [3] http://hg.openjdk.java.net/jdk9/jdk9/langtools/file/03e083639ee9/src/jdk.compiler/share/classes/com/sun/tools/javac/main/CommandLine.java > From florian.gauvin at nl.thalesgroup.com Mon Jul 13 14:19:39 2015 From: florian.gauvin at nl.thalesgroup.com (GAUVIN Florian) Date: Mon, 13 Jul 2015 14:19:39 +0000 Subject: Error building openjdk 8 with buildroot Message-ID: <5FD223E653528046A87219078E495127E8FE30@spvw1967.ONE-05.GRP> Hi, I'm trying to build openjdk8 with buildroot but I have this error : " checking for java in Boot JDK... ok checking for javac in Boot JDK... ok checking for javah in Boot JDK... ok checking for javap in Boot JDK... ok checking for jar in Boot JDK... ok checking for rmic in Boot JDK... ok checking for native2ascii in Boot JDK... ok checking flags for boot jdk java command ... checking flags for boot jdk java command for big workloads... -Xms64M -Xmx1600M -XX:ThreadStackSize=1536 -XX:PermSize=32m -XX:MaxPermSize=160m checking flags for boot jdk java command for small workloads... -XX:+UseSerialGC -Xms32M -Xmx512M checking for jtreg... no checking for cl... no checking for cc... /usr/bin/cc configure: Resolving BUILD_CC (as /usr/bin/cc) failed, using /usr/bin/cc directly. checking for cl... no checking for CC... no checking for g++... /usr/bin/g++ configure: Resolving BUILD_CXX (as /usr/bin/g++) failed, using /usr/bin/g++ directly. checking for ld... /usr/bin/ld configure: Resolving BUILD_LD (as /usr/bin/ld) failed, using /usr/bin/ld directly. checking for /home/student/Documents/buildroot-openjdk8-min/output/host/usr/bin/x86_64-buildroot-linux-gnu-gcc... no checking for /home/student/Documents/buildroot-openjdk8-min/output/host/usr/bin/x86_64-buildroot-linux-gnu-gcc... no configure: error: Could not find a C compiler. You might be able to fix this by running 'sudo yum groupinstall "Development Tools"'. configure exiting with result code 1 make: *** [/home/student/Documents/buildroot-openjdk8-min/output/build/openjdk-jdk8u60-b22/.stamp_configured] Error 1 " I don't understand why because the path to x86_64-buildroot-linux-gnu-gcc is the good one so the checking should be successful. Do you have an idea why? Here are all the steps that I have followed to build openjdk with buildroot : 1. If docker is already installed on your pc go to the next steps, other go to this website : https://docs.docker.com/userguide/, click on the install tab, choose your distribution and follow the steps. 2. In the terminal, go to the directory where you want to have buildroot and and run this command : git clone https://github.com/cranby/rpi-buildroot/ --branch openjdk 3. In rpi-buildroot/package/jamvm/jamvm.mk erase the following line : --without pic \ 4. In rpi-buildroot/package/openjdk delete the patches (otherwise there is errors patching) 5. In rpi-buildroot/package/openjdk/openjdk.mk : a. In order to avoid linking problems with libffi, add the following lines after OPENJDK_PROJECT : export LIBBFFI_CFLAGS=-I/$(HOST_DIR)/usr/x86_64-linux-gnu/include export LIBBFFI_CFLAGS=-L/$(HOST_DIR)/usr/x86_64-linux-gnu/sysroot/usr/lib/ -lffi b. To avoid missing headers of X11, in OPENJDK_CONF_OPT, add the following line : --disable-headful c. In OPENJDK_MAKE_OPT, change "all images pofiles" by "profiles", because we want only the compact profiles of openjdk and just after in CONF change "linux-arm-normal-zero-release" by "linux-x86_64-normal-zero-release" d. In OPENJDK_DEPENDENCIES, add the following dependencies libffi cups freetype xlib_libXrender xlib_libXt xlib_libXext xlib_libXtst libusb e. There is three compact run time environment for openjdk, On the following website you can see what are these run time environments and choose which one you need : http://openjdk.java.net/jeps/161 At the end of the file, in OPENJDK_INSTALL_TARGET_CMDS, add the two following lines replacing the X by the 2 compact profiles that you don't need : rm -f -r $(TARGET_DIR)/usr/lib/jvm/j2re-comapctX-image rm -f -r $(TARGET_DIR)/usr/lib/jvm/j2re-comapctX-image f. Change the version of openjdk : #Version is the same as OpenJDK HG tag OPENJDK_VERSION = jdk8u60-b22 #Release is the same as OPENJDK_RELEASE = jdk8u60 OPENJDK_PROJECT = jdk8u #OPENJDK_VERSION = jdk9-b36 #OPENJDK_RELEASE = m2 #OPENJDK_PROJECT = jigsaw 6. In the terminal, in the directory rpi-buildroot, run the following command : make menuconfig 7. Select the following options : (This are the options that I have chosen for the INAETICS project but you can choose others target architecture, c library or target packages but you have to enable openjdk ) Target options Target Architecture : x86_64 Target Architecture Variant : atom Toolchain C library : glibc Enable C++ support Target Packages Interpreter languages and scripting openjdk : y Libraries Audio/Sound alsa-lib : y 8. Escape and save the changes 9. Launch the build, run the command : make Regards, Florian GAUVIN ------------------------------------------------------------------------------------------------------------ Disclaimer: If you are not the intended recipient of this email, please notify the sender and delete it. Any unauthorized copying, disclosure or distribution of this email or its attachment(s) is forbidden. Thales Nederland BV will not accept liability for any damage caused by this email or its attachment(s). Thales Nederland BV is seated in Hengelo and is registered at the Chamber of Commerce under number 06061578. ------------------------------------------------------------------------------------------------------------ From david.holmes at oracle.com Tue Jul 14 03:43:48 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Jul 2015 13:43:48 +1000 Subject: Error building openjdk 8 with buildroot In-Reply-To: <5FD223E653528046A87219078E495127E8FE30@spvw1967.ONE-05.GRP> References: <5FD223E653528046A87219078E495127E8FE30@spvw1967.ONE-05.GRP> Message-ID: <55A48574.5070200@oracle.com> On 14/07/2015 12:19 AM, GAUVIN Florian wrote: > Hi, > I'm trying to build openjdk8 with buildroot but I have this error : > " > checking for java in Boot JDK... ok > checking for javac in Boot JDK... ok > checking for javah in Boot JDK... ok > checking for javap in Boot JDK... ok > checking for jar in Boot JDK... ok > checking for rmic in Boot JDK... ok > checking for native2ascii in Boot JDK... ok > checking flags for boot jdk java command ... > checking flags for boot jdk java command for big workloads... -Xms64M -Xmx1600M -XX:ThreadStackSize=1536 -XX:PermSize=32m -XX:MaxPermSize=160m > checking flags for boot jdk java command for small workloads... -XX:+UseSerialGC -Xms32M -Xmx512M > checking for jtreg... no > checking for cl... no > checking for cc... /usr/bin/cc > configure: Resolving BUILD_CC (as /usr/bin/cc) failed, using /usr/bin/cc directly. > checking for cl... no > checking for CC... no > checking for g++... /usr/bin/g++ > configure: Resolving BUILD_CXX (as /usr/bin/g++) failed, using /usr/bin/g++ directly. > checking for ld... /usr/bin/ld > configure: Resolving BUILD_LD (as /usr/bin/ld) failed, using /usr/bin/ld directly. > checking for /home/student/Documents/buildroot-openjdk8-min/output/host/usr/bin/x86_64-buildroot-linux-gnu-gcc... no > checking for /home/student/Documents/buildroot-openjdk8-min/output/host/usr/bin/x86_64-buildroot-linux-gnu-gcc... no > configure: error: Could not find a C compiler. You might be able to fix this by running 'sudo yum groupinstall "Development Tools"'. > configure exiting with result code 1 There is a known bug that configure only looks for gcc/g++ named binaries not ones that may be prefixed with a the devkit names eg: x86_64-buildroot-linux-gnu-gcc A workaround is to create symlinks for gcc/g++ David > make: *** [/home/student/Documents/buildroot-openjdk8-min/output/build/openjdk-jdk8u60-b22/.stamp_configured] Error 1 > " > I don't understand why because the path to x86_64-buildroot-linux-gnu-gcc is the good one so the checking should be successful. Do you have an idea why? > > Here are all the steps that I have followed to build openjdk with buildroot : > > 1. If docker is already installed on your pc go to the next steps, other go to this website : https://docs.docker.com/userguide/, click on the install tab, choose your distribution and follow the steps. > > 2. In the terminal, go to the directory where you want to have buildroot and and run this command : git clone https://github.com/cranby/rpi-buildroot/ --branch openjdk > > 3. In rpi-buildroot/package/jamvm/jamvm.mk erase the following line : --without pic \ > > 4. In rpi-buildroot/package/openjdk delete the patches (otherwise there is errors patching) > > 5. In rpi-buildroot/package/openjdk/openjdk.mk : > > a. In order to avoid linking problems with libffi, add the following lines after OPENJDK_PROJECT : > export LIBBFFI_CFLAGS=-I/$(HOST_DIR)/usr/x86_64-linux-gnu/include > export LIBBFFI_CFLAGS=-L/$(HOST_DIR)/usr/x86_64-linux-gnu/sysroot/usr/lib/ -lffi > > b. To avoid missing headers of X11, in OPENJDK_CONF_OPT, add the following line : > --disable-headful > > c. In OPENJDK_MAKE_OPT, change "all images pofiles" by "profiles", because we want only the compact profiles of openjdk > and just after in CONF change "linux-arm-normal-zero-release" by "linux-x86_64-normal-zero-release" > > d. In OPENJDK_DEPENDENCIES, add the following dependencies > libffi cups freetype xlib_libXrender xlib_libXt xlib_libXext xlib_libXtst libusb > > e. There is three compact run time environment for openjdk, > On the following website you can see what are these run time environments and choose which one you need : http://openjdk.java.net/jeps/161 > At the end of the file, in OPENJDK_INSTALL_TARGET_CMDS, add the two following lines replacing the X by the 2 compact profiles that you don't need : > rm -f -r $(TARGET_DIR)/usr/lib/jvm/j2re-comapctX-image > rm -f -r $(TARGET_DIR)/usr/lib/jvm/j2re-comapctX-image > > f. Change the version of openjdk : > #Version is the same as OpenJDK HG tag > OPENJDK_VERSION = jdk8u60-b22 > #Release is the same as > OPENJDK_RELEASE = jdk8u60 > OPENJDK_PROJECT = jdk8u > > #OPENJDK_VERSION = jdk9-b36 > #OPENJDK_RELEASE = m2 > #OPENJDK_PROJECT = jigsaw > > 6. In the terminal, in the directory rpi-buildroot, run the following command : make menuconfig > > 7. Select the following options : (This are the options that I have chosen for the INAETICS project but you can choose others target architecture, c library or target packages but you have to enable openjdk ) > > Target options > Target Architecture : x86_64 > Target Architecture Variant : atom > Toolchain > C library : glibc > Enable C++ support > Target Packages > Interpreter languages and scripting > openjdk : y > Libraries > Audio/Sound > alsa-lib : y > > 8. Escape and save the changes > > 9. Launch the build, run the command : make > > Regards, > Florian GAUVIN > > > ------------------------------------------------------------------------------------------------------------ > Disclaimer: > > If you are not the intended recipient of this email, please notify the sender and > delete it. > Any unauthorized copying, disclosure or distribution of this email or its > attachment(s) is forbidden. > Thales Nederland BV will not accept liability for any damage caused by this email or > its attachment(s). > Thales Nederland BV is seated in Hengelo and is registered at the Chamber of > Commerce under number 06061578. > ------------------------------------------------------------------------------------------------------------ > From daniel.daugherty at oracle.com Tue Jul 14 15:20:30 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 14 Jul 2015 09:20:30 -0600 Subject: RFR(XXS) 8131128: fix merge error in jprt.properties Message-ID: <55A528BE.8020807@oracle.com> Greetings, I have a fix for the following bug: JDK-8131128 Merge error in jprt.properties leads to missing devkit argument https://bugs.openjdk.java.net/browse/JDK-8131128 I made a merge error on 2015.07.03 during my gatekeeping work for a Main_Baseline -> RT_Baseline sync-down. Thanks for Mikael for finding this issue. Webrev URL: http://cr.openjdk.java.net/~dcubed/8131128-webrev/0-jdk9-hs-rt/ If you're interested in the whitespace changes that I made along with adding the line break, you'll need to use the 'cdiffs' link. Thanks, in advance, for any comments, questions or suggestions. Dan From tim.bell at oracle.com Tue Jul 14 16:19:50 2015 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 14 Jul 2015 09:19:50 -0700 Subject: RFR(XXS) 8131128: fix merge error in jprt.properties In-Reply-To: <55A528BE.8020807@oracle.com> References: <55A528BE.8020807@oracle.com> Message-ID: <55A536A6.40407@oracle.com> Hi Dan: > I have a fix for the following bug: > > JDK-8131128 Merge error in jprt.properties leads to missing devkit > argument > https://bugs.openjdk.java.net/browse/JDK-8131128 > > I made a merge error on 2015.07.03 during my gatekeeping work for a > Main_Baseline -> RT_Baseline sync-down. Thanks for Mikael for finding > this issue. > > Webrev URL: > http://cr.openjdk.java.net/~dcubed/8131128-webrev/0-jdk9-hs-rt/ > > If you're interested in the whitespace changes that I made along > with adding the line break, you'll need to use the 'cdiffs' link. Looks good to me. That is a very tricky file to change. Tim From daniel.daugherty at oracle.com Tue Jul 14 16:22:35 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 14 Jul 2015 10:22:35 -0600 Subject: RFR(XXS) 8131128: fix merge error in jprt.properties In-Reply-To: <55A536A6.40407@oracle.com> References: <55A528BE.8020807@oracle.com> <55A536A6.40407@oracle.com> Message-ID: <55A5374B.4020602@oracle.com> On 7/14/15 10:19 AM, Tim Bell wrote: > Hi Dan: > >> I have a fix for the following bug: >> >> JDK-8131128 Merge error in jprt.properties leads to missing >> devkit argument >> https://bugs.openjdk.java.net/browse/JDK-8131128 >> >> I made a merge error on 2015.07.03 during my gatekeeping work for a >> Main_Baseline -> RT_Baseline sync-down. Thanks for Mikael for finding >> this issue. >> >> Webrev URL: >> http://cr.openjdk.java.net/~dcubed/8131128-webrev/0-jdk9-hs-rt/ >> >> If you're interested in the whitespace changes that I made along >> with adding the line break, you'll need to use the 'cdiffs' link. > > Looks good to me. That is a very tricky file to change. Tim, Thanks for the fast review! Folks, I need (R)eviewer to take a look here. Dan > > Tim > From vladimir.kozlov at oracle.com Tue Jul 14 16:24:10 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 Jul 2015 09:24:10 -0700 Subject: RFR(XXS) 8131128: fix merge error in jprt.properties In-Reply-To: <55A5374B.4020602@oracle.com> References: <55A528BE.8020807@oracle.com> <55A536A6.40407@oracle.com> <55A5374B.4020602@oracle.com> Message-ID: <55A537AA.3040008@oracle.com> Good. Thanks, Vladimir On 7/14/15 9:22 AM, Daniel D. Daugherty wrote: > On 7/14/15 10:19 AM, Tim Bell wrote: >> Hi Dan: >> >>> I have a fix for the following bug: >>> >>> JDK-8131128 Merge error in jprt.properties leads to missing devkit argument >>> https://bugs.openjdk.java.net/browse/JDK-8131128 >>> >>> I made a merge error on 2015.07.03 during my gatekeeping work for a >>> Main_Baseline -> RT_Baseline sync-down. Thanks for Mikael for finding >>> this issue. >>> >>> Webrev URL: http://cr.openjdk.java.net/~dcubed/8131128-webrev/0-jdk9-hs-rt/ >>> >>> If you're interested in the whitespace changes that I made along >>> with adding the line break, you'll need to use the 'cdiffs' link. >> >> Looks good to me. That is a very tricky file to change. > > Tim, > > Thanks for the fast review! > > Folks, I need (R)eviewer to take a look here. > > Dan > > >> >> Tim >> > From daniel.daugherty at oracle.com Tue Jul 14 16:26:33 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 14 Jul 2015 10:26:33 -0600 Subject: RFR(XXS) 8131128: fix merge error in jprt.properties In-Reply-To: <55A537AA.3040008@oracle.com> References: <55A528BE.8020807@oracle.com> <55A536A6.40407@oracle.com> <55A5374B.4020602@oracle.com> <55A537AA.3040008@oracle.com> Message-ID: <55A53839.9090300@oracle.com> Vladimir, Thanks for the fast review! Folks, I believe we are now covered for reviews. Dan On 7/14/15 10:24 AM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 7/14/15 9:22 AM, Daniel D. Daugherty wrote: >> On 7/14/15 10:19 AM, Tim Bell wrote: >>> Hi Dan: >>> >>>> I have a fix for the following bug: >>>> >>>> JDK-8131128 Merge error in jprt.properties leads to missing >>>> devkit argument >>>> https://bugs.openjdk.java.net/browse/JDK-8131128 >>>> >>>> I made a merge error on 2015.07.03 during my gatekeeping work for a >>>> Main_Baseline -> RT_Baseline sync-down. Thanks for Mikael for finding >>>> this issue. >>>> >>>> Webrev URL: >>>> http://cr.openjdk.java.net/~dcubed/8131128-webrev/0-jdk9-hs-rt/ >>>> >>>> If you're interested in the whitespace changes that I made along >>>> with adding the line break, you'll need to use the 'cdiffs' link. >>> >>> Looks good to me. That is a very tricky file to change. >> >> Tim, >> >> Thanks for the fast review! >> >> Folks, I need (R)eviewer to take a look here. >> >> Dan >> >> >>> >>> Tim >>> >> From mandy.chung at oracle.com Wed Jul 15 14:51:52 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 15 Jul 2015 22:51:52 +0800 Subject: RFR - 8027634: Support @argfiles for java command-line tool In-Reply-To: References: Message-ID: > On Jul 10, 2015, at 11:48 AM, Henry Jen wrote: > > Hi, > > Please review proposed patch for JDK-8027634[1]. This patch is to enable java support command line argument file like javac does. The implementation use the same syntax rule, which is implemented in CommandLine.java[3] with java.io.StreamTokenizer. > > Some early comment is that we probably don?t need such complexity to support same syntax, also require to quote whole token is a little inconvenient. For example, must be -cp ?c:\\foo bar\\lib;c:\\lib? instead of -cp c:\?foo bar?\lib;c:\lib. > > I am debating if such compatibility is necessary useful, after all, easy and intuitive is more important, and with simpler rule, the implementation will be cleaner as well. I have a slight preference to maintain consistent syntax as javac @argfile support in terms of the quotation. A user could use the same path specified in -cp for both javac @argfile an java @argfile use. I skimmed on the webrev and looks okay to me. I?ll leave it for Kumar to do detailed review. One minor comment: args.c Are you planning to remove the test within #ifdef DEBUG_ARGFILE block? thanks Mandy From jpkutner at gmail.com Wed Jul 15 21:40:37 2015 From: jpkutner at gmail.com (Joe Kutner) Date: Wed, 15 Jul 2015 16:40:37 -0500 Subject: JDK 9 build hangs after java.security Message-ID: <29BA444B-081C-45D8-9826-A65227290F5F@gmail.com> I?m trying to build JDK 9 on Ubuntu using Docker. My build hangs at this point: > Generating java.security > Note: Some input files use unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > Warning: generation and use of skeletons and static stubs for JRMP > is deprecated. Skeletons are unnecessary, and static stubs have > been superseded by dynamically generated stubs. Users are > encouraged to migrate away from using rmic to generate skeletons and static > stubs. See the documentation for java.rmi.server.UnicastRemoteObject. How can I can more info to debug the problem? JDK 9 used to build successfully in this environment (maybe 2 months ago). I?m not sure when this started. More environment info: $ uname -a Linux bc6c6578ed2f 4.0.7-boot2docker #1 SMP Wed Jul 15 00:01:41 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux ==================================================== A new configuration has been successfully created in /tmp/tmp.s8BA5OS8Mj/openjdk9/build/linux-x86_64-normal-server-release using configure arguments '--with-cacerts-file=/cacerts --with-boot-jdk=/app/opt/java --disable-headful --enable-unlimited-crypto --disable-debug-symbols --with-jvm-variants=server --with-target-bits=64 --with-num-cores=2 --with-milestone=''cedar14_2015-07-15'' --with-update-version=ea --with-build-number=b70'. Configuration summary: * Debug level: release * HS debug level: product * JDK variant: normal * JVM variants: server * OpenJDK target: OS: linux, CPU architecture: x86, address length: 64 Tools summary: * Boot JDK: openjdk version "1.8.0_40-cedar14" OpenJDK Runtime Environment (build 1.8.0_40-cedar14-b25) OpenJDK 64-Bit Server VM (build 25.40-b25, mixed mode) (at /app/opt/java) * Toolchain: gcc (GNU Compiler Collection) * C Compiler: Version 4.8.2 (at /usr/bin/gcc) * C++ Compiler: Version 4.8.2 (at /usr/bin/g++) Build performance summary: * Cores to use: 1 * Memory limit: 2002 MB From david.holmes at oracle.com Wed Jul 15 22:46:52 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Jul 2015 08:46:52 +1000 Subject: JDK 9 build hangs after java.security In-Reply-To: <29BA444B-081C-45D8-9826-A65227290F5F@gmail.com> References: <29BA444B-081C-45D8-9826-A65227290F5F@gmail.com> Message-ID: <55A6E2DC.1000608@oracle.com> On 16/07/2015 7:40 AM, Joe Kutner wrote: > I?m trying to build JDK 9 on Ubuntu using Docker. My build hangs at this point: > >> Generating java.security >> Note: Some input files use unchecked or unsafe operations. >> Note: Recompile with -Xlint:unchecked for details. >> Warning: generation and use of skeletons and static stubs for JRMP >> is deprecated. Skeletons are unnecessary, and static stubs have >> been superseded by dynamically generated stubs. Users are >> encouraged to migrate away from using rmic to generate skeletons and static >> stubs. See the documentation for java.rmi.server.UnicastRemoteObject. > > How can I can more info to debug the problem? make LOG_LEVEL=debug Also see what processes are running at that point. You are on a "low power" system (1 core, 2G) so you may just be hitting an intensive part of the build - like building docs maybe? David > JDK 9 used to build successfully in this environment (maybe 2 months ago). I?m not sure when this started. > > More environment info: > > $ uname -a > Linux bc6c6578ed2f 4.0.7-boot2docker #1 SMP Wed Jul 15 00:01:41 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > > ==================================================== > A new configuration has been successfully created in > /tmp/tmp.s8BA5OS8Mj/openjdk9/build/linux-x86_64-normal-server-release > using configure arguments '--with-cacerts-file=/cacerts --with-boot-jdk=/app/opt/java --disable-headful --enable-unlimited-crypto --disable-debug-symbols --with-jvm-variants=server --with-target-bits=64 --with-num-cores=2 --with-milestone=''cedar14_2015-07-15'' --with-update-version=ea --with-build-number=b70'. > > Configuration summary: > * Debug level: release > * HS debug level: product > * JDK variant: normal > * JVM variants: server > * OpenJDK target: OS: linux, CPU architecture: x86, address length: 64 > > Tools summary: > * Boot JDK: openjdk version "1.8.0_40-cedar14" OpenJDK Runtime Environment (build 1.8.0_40-cedar14-b25) OpenJDK 64-Bit Server VM (build 25.40-b25, mixed mode) (at /app/opt/java) > * Toolchain: gcc (GNU Compiler Collection) > * C Compiler: Version 4.8.2 (at /usr/bin/gcc) > * C++ Compiler: Version 4.8.2 (at /usr/bin/g++) > > Build performance summary: > * Cores to use: 1 > * Memory limit: 2002 MB > From jpkutner at gmail.com Thu Jul 16 02:28:39 2015 From: jpkutner at gmail.com (Joe Kutner) Date: Wed, 15 Jul 2015 21:28:39 -0500 Subject: JDK 9 build hangs after java.security In-Reply-To: <55A6E2DC.1000608@oracle.com> References: <29BA444B-081C-45D8-9826-A65227290F5F@gmail.com> <55A6E2DC.1000608@oracle.com> Message-ID: <11C66966-63F1-4017-BEE7-193FEF2F5738@gmail.com> That revealed that it is working (but very slowly) :) thank you > On Jul 15, 2015, at 5:46 PM, David Holmes wrote: > > On 16/07/2015 7:40 AM, Joe Kutner wrote: >> I?m trying to build JDK 9 on Ubuntu using Docker. My build hangs at this point: >> >>> Generating java.security >>> Note: Some input files use unchecked or unsafe operations. >>> Note: Recompile with -Xlint:unchecked for details. >>> Warning: generation and use of skeletons and static stubs for JRMP >>> is deprecated. Skeletons are unnecessary, and static stubs have >>> been superseded by dynamically generated stubs. Users are >>> encouraged to migrate away from using rmic to generate skeletons and static >>> stubs. See the documentation for java.rmi.server.UnicastRemoteObject. >> >> How can I can more info to debug the problem? > > make LOG_LEVEL=debug > > Also see what processes are running at that point. You are on a "low power" system (1 core, 2G) so you may just be hitting an intensive part of the build - like building docs maybe? > > David > >> JDK 9 used to build successfully in this environment (maybe 2 months ago). I?m not sure when this started. >> >> More environment info: >> >> $ uname -a >> Linux bc6c6578ed2f 4.0.7-boot2docker #1 SMP Wed Jul 15 00:01:41 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >> >> ==================================================== >> A new configuration has been successfully created in >> /tmp/tmp.s8BA5OS8Mj/openjdk9/build/linux-x86_64-normal-server-release >> using configure arguments '--with-cacerts-file=/cacerts --with-boot-jdk=/app/opt/java --disable-headful --enable-unlimited-crypto --disable-debug-symbols --with-jvm-variants=server --with-target-bits=64 --with-num-cores=2 --with-milestone=''cedar14_2015-07-15'' --with-update-version=ea --with-build-number=b70'. >> >> Configuration summary: >> * Debug level: release >> * HS debug level: product >> * JDK variant: normal >> * JVM variants: server >> * OpenJDK target: OS: linux, CPU architecture: x86, address length: 64 >> >> Tools summary: >> * Boot JDK: openjdk version "1.8.0_40-cedar14" OpenJDK Runtime Environment (build 1.8.0_40-cedar14-b25) OpenJDK 64-Bit Server VM (build 25.40-b25, mixed mode) (at /app/opt/java) >> * Toolchain: gcc (GNU Compiler Collection) >> * C Compiler: Version 4.8.2 (at /usr/bin/gcc) >> * C++ Compiler: Version 4.8.2 (at /usr/bin/g++) >> >> Build performance summary: >> * Cores to use: 1 >> * Memory limit: 2002 MB >> From aw1621107 at gmail.com Fri Jul 17 04:34:11 2015 From: aw1621107 at gmail.com (Alex Wang) Date: Fri, 17 Jul 2015 00:34:11 -0400 Subject: Building openjdk 8u on OS X 10.11 fails Message-ID: <7C29F8CD-BF8C-4748-B86C-924AB8005899@gmail.com> I?m not really sure if this is something for the jdk developers or an upstream issue, since the error doesn?t seem to be strictly under idk control (the error looks to me to be something g++ does); I just thought to check in case there?s an easy solution (and I?m not really sure if reporting a problem for Xcode 4 would really accomplish anything). If I?m in the wrong place please let me know. Running OS X 10.11, JAVA_HOME is set to a 1.7 install, xcode-select is pointing at the right application, and I *think* the Xcode 4 command line tools were installed. Ran xcode-select ?install after switching, and it prompted for an install, at least. ./configure ?with-xcode-path= fails with this in config.log: configure:28891: checking for stdio.h configure:28891: result: yes configure:28919: checking size of int * configure:28924: /usr/bin/g++ -o conftest conftest.cpp >&5 couldn't understand kern.osversion `15.0.0' ld: library not found for -lgcc_s.10.4 collect2: ld returned 1 exit status configure:28924: $? = 1 configure: program exited with status 1 configure: failed program was: | /* confdefs.h */ configure:28938: result: 0 configure:28960: The tested number of bits in the target (0) differs from the number of bits expected to be found in the target (64). configure:28962: I'll retry after setting the platforms compiler target bits flag to -m64 configure:28993: checking size of int * configure:28998: /usr/bin/g++ -o conftest -m64 -m64 conftest.cpp >&5 couldn't understand kern.osversion `15.0.0' ld: library not found for -lgcc_s.10.4 collect2: ld returned 1 exit status configure:28998: $? = 1 configure: program exited with status 1 configure: failed program was: | /* confdefs.h */ configure:29012: result: 0 configure:29026: error: The tested number of bits in the target (0) differs from the number of bits expected to be found in the target (64) I looked around for a solution for the missing library, nothing I found really helped. One suggestion was to symlink it to the OS-provided one (l Unfortunately, 10.11?s new rootless feature means that I can?t write to that folder, and I don?t know if disabling that feature just for a build is the best idea. Another was to change the library in the build scripts. I took a look around, but the closest thing I could find in the config scripts were -lgcc flags, so I figured something else was the cause. I also tried messing with symlinking bits and pieces of Xcode 7?s toolchain into Xcode 4 to try and replace the offending binary, but nothing seemed to change. Using Xcode 4?s gcc sometimes worked, and sometimes produced the same error. I?m not really sure what about the programs I threw at it caused it to fail or not, but at least it seemed consistent for any particular program. If I can provide more info that would be helpful, I?ll be happy to do so. From aw1621107 at gmail.com Fri Jul 17 04:56:36 2015 From: aw1621107 at gmail.com (Alex Wang) Date: Fri, 17 Jul 2015 00:56:36 -0400 Subject: Building openjdk 8u on OS X 10.11 fails In-Reply-To: <7C29F8CD-BF8C-4748-B86C-924AB8005899@gmail.com> References: <7C29F8CD-BF8C-4748-B86C-924AB8005899@gmail.com> Message-ID: <861FA87D-388F-45B8-837E-F2C86D502446@gmail.com> Edit for formatting. Forgot that soft wraps were a thing. My apologies. I?m not really sure if this is something for the jdk developers or an upstream issue, since the error doesn?t seem to be strictly under idk control (the error looks to me to be something g++ does); I just thought to check in case there?s an easy solution (and I?m not really sure if reporting a problem for Xcode 4 would really accomplish anything). If I?m in the wrong place please let me know. Running OS X 10.11, JAVA_HOME is set to a 1.7 install, xcode-select is pointing at the right application, and I *think* the Xcode 4 command line tools were installed. Ran xcode-select ?install after switching, and it prompted for an install, at least. ./configure ?with-xcode-path= fails with this in config.log: configure:28891: checking for stdio.h configure:28891: result: yes configure:28919: checking size of int * configure:28924: /usr/bin/g++ -o conftest conftest.cpp >&5 couldn't understand kern.osversion `15.0.0' ld: library not found for -lgcc_s.10.4 collect2: ld returned 1 exit status configure:28924: $? = 1 configure: program exited with status 1 configure: failed program was: | /* confdefs.h */ configure:28938: result: 0 configure:28960: The tested number of bits in the target (0) differs from the number of bits expected to be found in the target (64). configure:28962: I'll retry after setting the platforms compiler target bits flag to -m64 configure:28993: checking size of int * configure:28998: /usr/bin/g++ -o conftest -m64 -m64 conftest.cpp >&5 couldn't understand kern.osversion `15.0.0' ld: library not found for -lgcc_s.10.4 collect2: ld returned 1 exit status configure:28998: $? = 1 configure: program exited with status 1 configure: failed program was: | /* confdefs.h */ configure:29012: result: 0 configure:29026: error: The tested number of bits in the target (0) differs from the number of bits expected to be found in the target (64) I looked around for a solution for the missing library, nothing I found really helped. One suggestion was to symlink it to the OS-provided one (l Unfortunately, 10.11?s new rootless feature means that I can?t write to that folder, and I don?t know if disabling that feature just for a build is the best idea. Another was to change the library in the build scripts. I took a look around, but the closest thing I could find in the config scripts were -lgcc flags, so I figured something else was the cause. I also tried messing with symlinking bits and pieces of Xcode 7?s toolchain into Xcode 4 to try and replace the offending binary, but nothing seemed to change. Using Xcode 4?s gcc sometimes worked, and sometimes produced the same error. I?m not really sure what about the programs I threw at it caused it to fail or not, but at least it seemed consistent for any particular program. If I can provide more info that would be helpful, I?ll be happy to do so. From anivol at ausy-group.com Mon Jul 20 12:00:19 2015 From: anivol at ausy-group.com (Antoine NIVOL) Date: Mon, 20 Jul 2015 14:00:19 +0200 (CEST) Subject: build for four target In-Reply-To: <722638380.3344489.1437386981219.JavaMail.root@ausy-group.com> Message-ID: <1835261857.3357361.1437393619732.JavaMail.root@ausy-group.com> Hi, I'm using a build on four differents machines, they use the Windows 7 SP1 32 bits operating system. the first one is a DELL (64 bits) with Intel core I7 for my devellopement and the jdk build. The second is a Panasonic with intel centrino Vpro for a product. The third is a Panasonic with intel core I5 for a product. And the last is a logic instrument fieldbook with a Intel Atom for a product. I have build the version 1.6.35 with cygwin for this four machines. The last logic instrument doesn't work after a few secondes (30 or 45) of execution. the error stack is below : C [ntdll.dll+0x52d37] RtlFreeHeap+0xcd C [ntdll.dll+0x52ce8] RtlFreeHeap+0x7e C [kernel32.dll+0x4c484] HeapFree+0x14 C [msvcr100.dll+0x1016a] free+0x1c C [zip.dll+0x7709] Java_java_util_zip_ZipEntry_initFields+0x58de J java.util.zip.ZipFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry; V [jvm.dll+0x12453a] V [jvm.dll+0x1d013e] V [jvm.dll+0x1245bd] V [jvm.dll+0xd89b4] C [java.dll+0x1061] Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedExceptionAction_2Ljava_security_AccessControlContext_2+0x17 J java.net.URLClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class; The error occur at several zone on my software but the top six lines are always similar. I'm used a buid of Zip import from those sites : http://gnuwin32.sourceforge.net/packages/bzip2.htm http://gnuwin32.sourceforge.net/packages/unzip.htm http://gnuwin32.sourceforge.net/packages/zip.htm I will try to build with another version of zip and unzip. Do you have any solution to my problem? Or just an idea? Cordially Antoine N. From tdaitx at br.ibm.com Mon Jul 20 18:06:45 2015 From: tdaitx at br.ibm.com (Tiago Sturmer Daitx) Date: Mon, 20 Jul 2015 15:06:45 -0300 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <54F42193.3030700@oracle.com> References: <1424883208.5112.287.camel@ocdc> <1739722263.18761313.1424883425179.JavaMail.zimbra@redhat.com> <54EE8588.8060209@oracle.com> <54EED213.5010006@oracle.com> <128547706.19763273.1425000302044.JavaMail.zimbra@redhat.com> <54EFD092.5090007@oracle.com> <1798541240.20403783.1425063960818.JavaMail.zimbra@redhat.com> <54F42193.3030700@oracle.com> Message-ID: <201507201806.t6KHxH0K007451@mx0b-001b2d01.pphosted.com> Hi all, What's the status of this bug fix? It is not clear if the fix was ever accepted - I haven't been able to find a commit for it. If it was not accepted, what is missing to get this integrated into JDK9 and then backported to JDK8? As for JDK7, IcedTea 2.6 (just released) has the fix and IIRC the PPC-AIX-Port repository also has it. It would be good to get this into JDK8 ASAP, otherwise distros will need to patch it on their own (those that aren't already). This was reported initally at JDK-8073139 [1]. Best regards, Tiago [1] https://bugs.openjdk.java.net/browse/JDK-8073139 On Mon, 2015-03-02 at 18:38 +1000, David Holmes wrote: > > > On 28/02/2015 5:06 AM, Andrew Hughes wrote: > > ----- Original Message ----- > >> On 27/02/2015 11:25 AM, Andrew Hughes wrote: > >>> ----- Original Message ----- > >>>> > >>>> On 26/02/2015 12:31 PM, David Holmes wrote: > >>>>> On 26/02/2015 2:57 AM, Andrew Hughes wrote: > >>>>>>>>> These are the revised versions of the webrevs: > >>>>>>>>> > >>>>>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/root/ > >>>>>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/jdk/ > >>>>>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/hotspot/ > >>>>>>>>> > >>>>>>>>> (HotSpot is unchanged, dropped the sound changes from JDK) > >>>>>> > >>>>>> Ok if I push the jdk and root parts then? I think someone on the Oracle > >>>>>> HS team (David?) needs to push the HotSpot bit. > >>>>> > >>>>> Best to push it all together I think, which I can do through the hs-rt > >>>>> forest. But first I need to see where things settled with all this :) I > >>>>> was quite confused by some of the initial suggestions. Will try to get > >>>>> to this today. > >>> > >>> Well, I'd push it all myself if there weren't still restrictions on pushing > >>> to HotSpot... > >>> > >>>> > >>>> I'm still very confused by these changes and have trouble tracking the > >>>> values of the various "arch" related variables. If I follow this right > >>>> presently the only distinction between ppc64 and ppc64le is the value of > >>>> OPENJDK_TARGET_CPU_ENDIAN. In particular they both use ppc64 as the > >>>> hotspot LIBARCH value and ppc as the ARCH value. (Aside: so ARCH/ppc64 > >>>> is either unused or only used by a hotspot-only build?) > >>>> > >>>> The desired change is that the top-level architecture (VAR_CPU which > >>>> becomes OPENJDK_TARGET_CPU) should now be ppc64le not ppc64, but that > >>>> for hotspot the only difference is LIBARCH becomes ppc64le. So to > >>>> achieve this hotspot-spec.gmk switches ARCH to be ppc64 instead of the > >>>> current ppc; and then hotspot's def.make uses that combined with being > >>>> lttle-endian to reset the LIBARCH to ppc64le. > >>> > >>> From ppc64le. Without the override in hotspot-spec.gmk, the HotSpot build > >>> will get called with ARCH=ppc64le and fail, because make/defs.make will > >>> set SRCARCH to x86 > >> > >> No, ARCH comes from $(OPENJDK_TARGET_CPU_ARCH) which comes from > >> $VAR_CPU_ARCH which is still ppc, not ppc64le. So SRCARCH will be set to > >> ppc as per current code. Then BUILDARCH will check LP64 and so become > >> ppc64. Then you can check endian-ness to define LIBARCH to ppc64le. > >> > > > > Ah, not in 8 where this was tested: > > > > ARCH=$(OPENJDK_TARGET_CPU_LEGACY) > > +# ppc64le uses the HotSpot ppc64 build > > +ifeq ($(OPENJDK_TARGET_CPU), ppc64le) > > + ARCH=ppc64 > > +endif > > > > OPENJDK_TARGET_CPU_LEGACY is set to OPENJDK_TARGET_CPU which is ppc64le in this case. > > > > 9 changed this with: > > > > 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for hotspot ARCH > > > > So it looks like we're going to end up with three different patches for this issue. > > That explains all the confusion :) > > >> Yes but you can do it based on the value of LIBARCH rather than a > >> modified ARCH. > > > > Yes, with 8046471 in place. Hardly a huge difference though. > > Avoiding the need to mess with what happens at the configure level in > hoptspot-spec.gmk.in makes it a lot simpler to follow IMHO. > > > >> I don't know if I already had this conversation but it strikes me as > >> really bizarre that the PPC64 port uses two different ARCH values > >> depending on whether it is a configure-based build or not! ??? > >> > > > > It's not just that port. Every build either gets ARCH set by > > hotspot-spec.gmk (by way of configure) or by uname -m in > > make/linux/makefiles/defs.make. This is necessary if you're > > going to allow someone to skip configure and just build HotSpot. > > It's not the two different mechanisms that I was referring to, but the > fact that those mechanisms result in two completely different values for > ARCH for the same port. This just piles complexity on top of complexity. > > > If no-one does that any more, then the old stuff that was needed > > for 7 builds (no configure) could be culled. > > Eventually the hotspot build will be all configure based. Even now I'm > not sure why people need to do a hotspot-only build this way rather than > just running configure and "make hotspot-only". > > >> That aside if ARCH == ppc64 from uname then: > >> - SRCARCH = ARCH/ppc64 = ppc > >> - BUILDARCH = ppc64 > >> > >> and so the same fix as above would work for this case. > >> > > > > It doesn't, as I said. It's ppc64le. So the uname override is necessary. > > For consistency, it probably should now be overridden to be ppc, not > > ppc64, given the value passed in from configure changed to that in > > 8046471. > > Ok. > > Thanks, > David > ----- > > >>> so our addition to hotspot-spec.gmk is just to do the same as this > >>> block for configure builds. > >>> > >>> It was unneeded before because configure would just set the arch > >>> to ppc64 for the entire build, not just HotSpot. > >> > >> AFAICS it set it to ppc not ppc64. > > > > I was referring to: > > > > - VAR_CPU=ppc64 > > + VAR_CPU=ppc64le > > > > and in turn OPENJDK_TARGET_CPU_LEGACY, not VAR_CPU_ARCH/OPENJDK_TARGET_CPU_ARCH. > > > >> > >> David > >> ----- > >> > >> > >>>> Thanks, > >>>> David > >>>> > >>>> > >>>> Given the LIBARCH switcheroo that happens in hotspot/make/def.make, why > >>>> bother also doing the switcheroo in > >>>> /common/autoconf/hotspot-spec.gmk.in when you could just do > >>>> everything in hotspot/make/defs > >>>> > >>>>> David > >>>>> ----- > >>>>> > >>>>> > >>>>>> Thanks, > >>>>>> > >>>> > >>> > >> > > > From mail at alexkasko.com Mon Jul 20 18:20:31 2015 From: mail at alexkasko.com (Alex Kashchenko) Date: Mon, 20 Jul 2015 21:20:31 +0300 Subject: build for four target In-Reply-To: <1835261857.3357361.1437393619732.JavaMail.root@ausy-group.com> References: <1835261857.3357361.1437393619732.JavaMail.root@ausy-group.com> Message-ID: <55AD3BEF.3030801@alexkasko.com> Hi Antoine, On 07/20/2015 03:00 PM, Antoine NIVOL wrote: > Hi, > I'm using a build on four differents machines, they use the Windows 7 SP1 32 bits operating system. > the first one is a DELL (64 bits) with Intel core I7 for my devellopement and the jdk build. > The second is a Panasonic with intel centrino Vpro for a product. > The third is a Panasonic with intel core I5 for a product. > And the last is a logic instrument fieldbook with a Intel Atom for a product. > > I have build the version 1.6.35 with cygwin for this four machines. Are you building sources from this repository - http://hg.openjdk.java.net/jdk6 ? > > The last logic instrument doesn't work after a few secondes (30 or 45) of execution. > > the error stack is below : > C [ntdll.dll+0x52d37] RtlFreeHeap+0xcd > C [ntdll.dll+0x52ce8] RtlFreeHeap+0x7e > C [kernel32.dll+0x4c484] HeapFree+0x14 > C [msvcr100.dll+0x1016a] free+0x1c > C [zip.dll+0x7709] Java_java_util_zip_ZipEntry_initFields+0x58de > J java.util.zip.ZipFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry; > V [jvm.dll+0x12453a] > V [jvm.dll+0x1d013e] > V [jvm.dll+0x1245bd] > V [jvm.dll+0xd89b4] > C [java.dll+0x1061] Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedExceptionAction_2Ljava_security_AccessControlContext_2+0x17 > J java.net.URLClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class; > > > The error occur at several zone on my software but the top six lines are always similar. Does it happen only on particular hardware and works fine on other machines? Do you have a code snippet (or an erroneous zip file) to reproduce this? Or is it happened during the build, not during the normal run? > > I'm used a buid of Zip import from those sites : > > http://gnuwin32.sourceforge.net/packages/bzip2.htm > http://gnuwin32.sourceforge.net/packages/unzip.htm > http://gnuwin32.sourceforge.net/packages/zip.htm > > I will try to build with another version of zip and unzip. This part is not clear. Do you mean zip and unzip utilities that are used during the build? Then I can recommend to use native ones (non-cygwin/msys/gnuwin) from info-zip. But the stacktrace above looks like that this is a problem with zip implementation included with jdk6 sources - http://hg.openjdk.java.net/jdk6/jdk6/jdk/file/ca2c9f498b70/src/share/native/java/util/zip > > Do you have any solution to my problem? Or just an idea? I can try to reproduce this, I think there were similar issues with zlib in jdk on erroneous zip files. And the in-tree zlib in jdk6 most probably wasn't updated for a while as linux builds usually use platform zlib instead of it. PS: it looks like this question is specific to jdk6, so I am CC'ing jdk6-dev. Please remove build-dev from copy if this is actually jdk6-specific. > > Cordially > > Antoine N. > -- -Alex From alejandro.murillo at oracle.com Tue Jul 21 00:45:49 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Mon, 20 Jul 2015 18:45:49 -0600 Subject: [8u66] RFR 8079410: Hotspot version to share the same update and build version from JDK Message-ID: <55AD963C.8010203@oracle.com> Please review the following change that allows setting the Hotspot minor version and build number to that of the "--with-update-version" and "--with-build-number" configure parameters when provided. 8u builds only. webrev: http://javaweb.us.oracle.com/~amurillo/webrevs/8079410/ Background (since bug was originally filed as internal): Currently, for 8u builds and earlier, the hotspot version looks like this (remnant from the hotspot express days): Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) By convention, minor version (66 above) always matches the JDK update version and hotspot build number is managed independently of the JDK build number. Both values are defined by default in "hotspot/make/hotspot_version". With this change they can now be setup using the corresponding JDK configure parameters. Consequences: (1) For promoted and other milestone builds, the hotspot minor version will corresponds to the JDK update version and the hotspot build number will match the JDK build number. (2) Hotspot snapshots will no longer need to change the hotspot build number as that will be set at promotion time (matching the JDK build number). Since this is stored in the file mentioned above, a repo push (and the corresponding bug) was required to change it. That will no longer be necessary. (3) Since JPRT configures both the update and build numbers, when building via JPRT, the hotspot build number for those builds will always be 'b00' (matching the JDK build number). The Hotspot minor version will match the update version defined in make/jprt.prtoperties: java version "1.8.0_66-internal" # Java(TM) SE Runtime Environment (build 1.8.0_66-internal-20150720195933.amurillo.8079410-control-b00) # Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) (4) Since the version string is not actually changing, I do not expect this to have any impact on external tools or apps, but let me know if so. Thanks -- Alejandro From david.holmes at oracle.com Tue Jul 21 01:01:14 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Jul 2015 11:01:14 +1000 Subject: [8u66] RFR 8079410: Hotspot version to share the same update and build version from JDK In-Reply-To: <55AD963C.8010203@oracle.com> References: <55AD963C.8010203@oracle.com> Message-ID: <55AD99DA.5090909@oracle.com> Hi Alejandro, On 21/07/2015 10:45 AM, Alejandro E Murillo wrote: > > Please review the following change that allows setting > the Hotspot minor version and build number to that > of the "--with-update-version" and "--with-build-number" > configure parameters when provided. 8u builds only. > > webrev: > http://javaweb.us.oracle.com/~amurillo/webrevs/8079410/ That location is not available externally. David > Background (since bug was originally filed as internal): > > Currently, for 8u builds and earlier, the hotspot version looks like this > (remnant from the hotspot express days): > > Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) > > > By convention, minor version (66 above) always matches the JDK update > version > and hotspot build number is managed independently of the JDK build number. > Both values are defined by default in "hotspot/make/hotspot_version". > With this change they can now be setup using the corresponding JDK > configure parameters. > > Consequences: > > (1) For promoted and other milestone builds, the hotspot minor version > will corresponds to the JDK update version and the hotspot build number > will match the JDK build number. > > (2) Hotspot snapshots will no longer need to change the hotspot build > number > as that will be set at promotion time (matching the JDK build number). > Since this is stored in the file mentioned above, a repo push > (and the corresponding bug) was required to change it. > That will no longer be necessary. > > (3) Since JPRT configures both the update and build numbers, > when building via JPRT, the hotspot build number for those builds > will always be 'b00' (matching the JDK build number). The Hotspot > minor version will match the update version defined in > make/jprt.prtoperties: > > java version "1.8.0_66-internal" > # Java(TM) SE Runtime Environment (build > 1.8.0_66-internal-20150720195933.amurillo.8079410-control-b00) > # Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) > > (4) Since the version string is not actually changing, I do not expect > this to have > any impact on external tools or apps, but let me know if so. > > Thanks > From david.holmes at oracle.com Tue Jul 21 01:10:15 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Jul 2015 11:10:15 +1000 Subject: [8u66] RFR 8079410: Hotspot version to share the same update and build version from JDK In-Reply-To: <55AD963C.8010203@oracle.com> References: <55AD963C.8010203@oracle.com> Message-ID: <55AD9BF7.8070906@oracle.com> Hi Alejandro, On 21/07/2015 10:45 AM, Alejandro E Murillo wrote: > > Please review the following change that allows setting > the Hotspot minor version and build number to that > of the "--with-update-version" and "--with-build-number" > configure parameters when provided. 8u builds only. > > webrev: > http://javaweb.us.oracle.com/~amurillo/webrevs/8079410/ The logic seems fine. I would have put it in the hotspot_version file directly I think, but it's okay as is. I presume we will still update the default update version at the start of each new release cycle. Thanks, David > Background (since bug was originally filed as internal): > > Currently, for 8u builds and earlier, the hotspot version looks like this > (remnant from the hotspot express days): > > Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) > > > By convention, minor version (66 above) always matches the JDK update > version > and hotspot build number is managed independently of the JDK build number. > Both values are defined by default in "hotspot/make/hotspot_version". > With this change they can now be setup using the corresponding JDK > configure parameters. > > Consequences: > > (1) For promoted and other milestone builds, the hotspot minor version > will corresponds to the JDK update version and the hotspot build number > will match the JDK build number. > > (2) Hotspot snapshots will no longer need to change the hotspot build > number > as that will be set at promotion time (matching the JDK build number). > Since this is stored in the file mentioned above, a repo push > (and the corresponding bug) was required to change it. > That will no longer be necessary. > > (3) Since JPRT configures both the update and build numbers, > when building via JPRT, the hotspot build number for those builds > will always be 'b00' (matching the JDK build number). The Hotspot > minor version will match the update version defined in > make/jprt.prtoperties: > > java version "1.8.0_66-internal" > # Java(TM) SE Runtime Environment (build > 1.8.0_66-internal-20150720195933.amurillo.8079410-control-b00) > # Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) > > (4) Since the version string is not actually changing, I do not expect > this to have > any impact on external tools or apps, but let me know if so. > > Thanks > From alejandro.murillo at oracle.com Tue Jul 21 02:09:26 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Mon, 20 Jul 2015 20:09:26 -0600 Subject: [8u66] RFR 8079410: Hotspot version to share the same update and build version from JDK In-Reply-To: <55AD99DA.5090909@oracle.com> References: <55AD963C.8010203@oracle.com> <55AD99DA.5090909@oracle.com> Message-ID: <55ADA9D6.7070903@oracle.com> On 7/20/2015 7:01 PM, David Holmes wrote: > Hi Alejandro, > > On 21/07/2015 10:45 AM, Alejandro E Murillo wrote: >> >> Please review the following change that allows setting >> the Hotspot minor version and build number to that >> of the "--with-update-version" and "--with-build-number" >> configure parameters when provided. 8u builds only. >> >> webrev: >> cut from the wrong tab, here you go: http://cr.openjdk.java.net/~amurillo/8u66/8079410/ Alejandro > > That location is not available externally. > > David > >> Background (since bug was originally filed as internal): >> >> Currently, for 8u builds and earlier, the hotspot version looks like >> this >> (remnant from the hotspot express days): >> >> Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) >> >> >> By convention, minor version (66 above) always matches the JDK update >> version >> and hotspot build number is managed independently of the JDK build >> number. >> Both values are defined by default in "hotspot/make/hotspot_version". >> With this change they can now be setup using the corresponding JDK >> configure parameters. >> >> Consequences: >> >> (1) For promoted and other milestone builds, the hotspot minor version >> will corresponds to the JDK update version and the hotspot build number >> will match the JDK build number. >> >> (2) Hotspot snapshots will no longer need to change the hotspot build >> number >> as that will be set at promotion time (matching the JDK build number). >> Since this is stored in the file mentioned above, a repo push >> (and the corresponding bug) was required to change it. >> That will no longer be necessary. >> >> (3) Since JPRT configures both the update and build numbers, >> when building via JPRT, the hotspot build number for those builds >> will always be 'b00' (matching the JDK build number). The Hotspot >> minor version will match the update version defined in >> make/jprt.prtoperties: >> >> java version "1.8.0_66-internal" >> # Java(TM) SE Runtime Environment (build >> 1.8.0_66-internal-20150720195933.amurillo.8079410-control-b00) >> # Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) >> >> (4) Since the version string is not actually changing, I do not expect >> this to have >> any impact on external tools or apps, but let me know if so. >> >> Thanks >> -- Alejandro From alejandro.murillo at oracle.com Tue Jul 21 02:22:00 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Mon, 20 Jul 2015 20:22:00 -0600 Subject: [8u66] RFR 8079410: Hotspot version to share the same update and build version from JDK In-Reply-To: <55AD9BF7.8070906@oracle.com> References: <55AD963C.8010203@oracle.com> <55AD9BF7.8070906@oracle.com> Message-ID: <55ADACC8.1060506@oracle.com> On 7/20/2015 7:10 PM, David Holmes wrote: > Hi Alejandro, > > On 21/07/2015 10:45 AM, Alejandro E Murillo wrote: >> >> Please review the following change that allows setting >> the Hotspot minor version and build number to that >> of the "--with-update-version" and "--with-build-number" >> configure parameters when provided. 8u builds only. >> >> webrev: >> http://cr.openjdk.java.net/~amurillo/8u66/8079410/ > > The logic seems fine. I would have put it in the hotspot_version file > directly I think, but it's okay as is. right, I could have put it there as well. > > I presume we will still update the default update version at the start > of each new release cycle. Yes, but only necessary for non milestone or jprt builds Thanks Alejandro > > Thanks, > David > >> Background (since bug was originally filed as internal): >> >> Currently, for 8u builds and earlier, the hotspot version looks like >> this >> (remnant from the hotspot express days): >> >> Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) >> >> >> By convention, minor version (66 above) always matches the JDK update >> version >> and hotspot build number is managed independently of the JDK build >> number. >> Both values are defined by default in "hotspot/make/hotspot_version". >> With this change they can now be setup using the corresponding JDK >> configure parameters. >> >> Consequences: >> >> (1) For promoted and other milestone builds, the hotspot minor version >> will corresponds to the JDK update version and the hotspot build number >> will match the JDK build number. >> >> (2) Hotspot snapshots will no longer need to change the hotspot build >> number >> as that will be set at promotion time (matching the JDK build number). >> Since this is stored in the file mentioned above, a repo push >> (and the corresponding bug) was required to change it. >> That will no longer be necessary. >> >> (3) Since JPRT configures both the update and build numbers, >> when building via JPRT, the hotspot build number for those builds >> will always be 'b00' (matching the JDK build number). The Hotspot >> minor version will match the update version defined in >> make/jprt.prtoperties: >> >> java version "1.8.0_66-internal" >> # Java(TM) SE Runtime Environment (build >> 1.8.0_66-internal-20150720195933.amurillo.8079410-control-b00) >> # Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) >> >> (4) Since the version string is not actually changing, I do not expect >> this to have >> any impact on external tools or apps, but let me know if so. >> >> Thanks >> -- Alejandro From volker.simonis at gmail.com Tue Jul 21 08:39:36 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 21 Jul 2015 10:39:36 +0200 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <201507201806.t6KHxH0K007451@mx0b-001b2d01.pphosted.com> References: <1424883208.5112.287.camel@ocdc> <1739722263.18761313.1424883425179.JavaMail.zimbra@redhat.com> <54EE8588.8060209@oracle.com> <54EED213.5010006@oracle.com> <128547706.19763273.1425000302044.JavaMail.zimbra@redhat.com> <54EFD092.5090007@oracle.com> <1798541240.20403783.1425063960818.JavaMail.zimbra@redhat.com> <54F42193.3030700@oracle.com> <201507201806.t6KHxH0K007451@mx0b-001b2d01.pphosted.com> Message-ID: Hi Tiago, I suppose you are referring to "PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling" (https://bugs.openjdk.java.net/browse/JDK-8073139), right? This hasn't been fixed until now. We probably have to start a new review round for this issue for jdk9. Afterwards we can bring it to jdk8u but unfortunately it's already too late for 8u60 anyway. It was unfortunate that the discussion for 8073139 was intermixed into this too long thread for 8036767. What has been fixed for IcedTea 2.6 in JDK7 - the value of the 'os.arch' property only or both, the value of the property and the name of the arch directory? Regards, Volker On Mon, Jul 20, 2015 at 8:06 PM, Tiago Sturmer Daitx wrote: > Hi all, > > > What's the status of this bug fix? It is not clear if the fix was ever > accepted - I haven't been able to find a commit for it. > > If it was not accepted, what is missing to get this integrated into JDK9 > and then backported to JDK8? > > As for JDK7, IcedTea 2.6 (just released) has the fix and IIRC the > PPC-AIX-Port repository also has it. > > It would be good to get this into JDK8 ASAP, otherwise distros will need > to patch it on their own (those that aren't already). > > This was reported initally at JDK-8073139 [1]. > > Best regards, > Tiago > > [1] https://bugs.openjdk.java.net/browse/JDK-8073139 > > On Mon, 2015-03-02 at 18:38 +1000, David Holmes wrote: >> >> >> On 28/02/2015 5:06 AM, Andrew Hughes wrote: >> > ----- Original Message ----- >> >> On 27/02/2015 11:25 AM, Andrew Hughes wrote: >> >>> ----- Original Message ----- >> >>>> >> >>>> On 26/02/2015 12:31 PM, David Holmes wrote: >> >>>>> On 26/02/2015 2:57 AM, Andrew Hughes wrote: >> >>>>>>>>> These are the revised versions of the webrevs: >> >>>>>>>>> >> >>>>>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/root/ >> >>>>>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/jdk/ >> >>>>>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/hotspot/ >> >>>>>>>>> >> >>>>>>>>> (HotSpot is unchanged, dropped the sound changes from JDK) >> >>>>>> >> >>>>>> Ok if I push the jdk and root parts then? I think someone on the Oracle >> >>>>>> HS team (David?) needs to push the HotSpot bit. >> >>>>> >> >>>>> Best to push it all together I think, which I can do through the hs-rt >> >>>>> forest. But first I need to see where things settled with all this :) I >> >>>>> was quite confused by some of the initial suggestions. Will try to get >> >>>>> to this today. >> >>> >> >>> Well, I'd push it all myself if there weren't still restrictions on pushing >> >>> to HotSpot... >> >>> >> >>>> >> >>>> I'm still very confused by these changes and have trouble tracking the >> >>>> values of the various "arch" related variables. If I follow this right >> >>>> presently the only distinction between ppc64 and ppc64le is the value of >> >>>> OPENJDK_TARGET_CPU_ENDIAN. In particular they both use ppc64 as the >> >>>> hotspot LIBARCH value and ppc as the ARCH value. (Aside: so ARCH/ppc64 >> >>>> is either unused or only used by a hotspot-only build?) >> >>>> >> >>>> The desired change is that the top-level architecture (VAR_CPU which >> >>>> becomes OPENJDK_TARGET_CPU) should now be ppc64le not ppc64, but that >> >>>> for hotspot the only difference is LIBARCH becomes ppc64le. So to >> >>>> achieve this hotspot-spec.gmk switches ARCH to be ppc64 instead of the >> >>>> current ppc; and then hotspot's def.make uses that combined with being >> >>>> lttle-endian to reset the LIBARCH to ppc64le. >> >>> >> >>> From ppc64le. Without the override in hotspot-spec.gmk, the HotSpot build >> >>> will get called with ARCH=ppc64le and fail, because make/defs.make will >> >>> set SRCARCH to x86 >> >> >> >> No, ARCH comes from $(OPENJDK_TARGET_CPU_ARCH) which comes from >> >> $VAR_CPU_ARCH which is still ppc, not ppc64le. So SRCARCH will be set to >> >> ppc as per current code. Then BUILDARCH will check LP64 and so become >> >> ppc64. Then you can check endian-ness to define LIBARCH to ppc64le. >> >> >> > >> > Ah, not in 8 where this was tested: >> > >> > ARCH=$(OPENJDK_TARGET_CPU_LEGACY) >> > +# ppc64le uses the HotSpot ppc64 build >> > +ifeq ($(OPENJDK_TARGET_CPU), ppc64le) >> > + ARCH=ppc64 >> > +endif >> > >> > OPENJDK_TARGET_CPU_LEGACY is set to OPENJDK_TARGET_CPU which is ppc64le in this case. >> > >> > 9 changed this with: >> > >> > 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for hotspot ARCH >> > >> > So it looks like we're going to end up with three different patches for this issue. >> >> That explains all the confusion :) >> >> >> Yes but you can do it based on the value of LIBARCH rather than a >> >> modified ARCH. >> > >> > Yes, with 8046471 in place. Hardly a huge difference though. >> >> Avoiding the need to mess with what happens at the configure level in >> hoptspot-spec.gmk.in makes it a lot simpler to follow IMHO. >> >> >> >> I don't know if I already had this conversation but it strikes me as >> >> really bizarre that the PPC64 port uses two different ARCH values >> >> depending on whether it is a configure-based build or not! ??? >> >> >> > >> > It's not just that port. Every build either gets ARCH set by >> > hotspot-spec.gmk (by way of configure) or by uname -m in >> > make/linux/makefiles/defs.make. This is necessary if you're >> > going to allow someone to skip configure and just build HotSpot. >> >> It's not the two different mechanisms that I was referring to, but the >> fact that those mechanisms result in two completely different values for >> ARCH for the same port. This just piles complexity on top of complexity. >> >> > If no-one does that any more, then the old stuff that was needed >> > for 7 builds (no configure) could be culled. >> >> Eventually the hotspot build will be all configure based. Even now I'm >> not sure why people need to do a hotspot-only build this way rather than >> just running configure and "make hotspot-only". >> >> >> That aside if ARCH == ppc64 from uname then: >> >> - SRCARCH = ARCH/ppc64 = ppc >> >> - BUILDARCH = ppc64 >> >> >> >> and so the same fix as above would work for this case. >> >> >> > >> > It doesn't, as I said. It's ppc64le. So the uname override is necessary. >> > For consistency, it probably should now be overridden to be ppc, not >> > ppc64, given the value passed in from configure changed to that in >> > 8046471. >> >> Ok. >> >> Thanks, >> David >> ----- >> >> >>> so our addition to hotspot-spec.gmk is just to do the same as this >> >>> block for configure builds. >> >>> >> >>> It was unneeded before because configure would just set the arch >> >>> to ppc64 for the entire build, not just HotSpot. >> >> >> >> AFAICS it set it to ppc not ppc64. >> > >> > I was referring to: >> > >> > - VAR_CPU=ppc64 >> > + VAR_CPU=ppc64le >> > >> > and in turn OPENJDK_TARGET_CPU_LEGACY, not VAR_CPU_ARCH/OPENJDK_TARGET_CPU_ARCH. >> > >> >> >> >> David >> >> ----- >> >> >> >> >> >>>> Thanks, >> >>>> David >> >>>> >> >>>> >> >>>> Given the LIBARCH switcheroo that happens in hotspot/make/def.make, why >> >>>> bother also doing the switcheroo in >> >>>> /common/autoconf/hotspot-spec.gmk.in when you could just do >> >>>> everything in hotspot/make/defs >> >>>> >> >>>>> David >> >>>>> ----- >> >>>>> >> >>>>> >> >>>>>> Thanks, >> >>>>>> >> >>>> >> >>> >> >> >> > >> > > From irogers at google.com Tue Jul 21 17:01:42 2015 From: irogers at google.com (Ian Rogers) Date: Tue, 21 Jul 2015 10:01:42 -0700 Subject: Allow --with-extra-cxxflags to work with HotSpot. Message-ID: The following (modest) patch against jdk9dev allows the top-level configure with --with-extra-cxxflags to pass options to the HotSpot build. An example would be: configure --fastdebug --with-extra-cxxflags=-std=c++11 Unless --with-extra-cxxflags is specified the option has no effect. I'd like to work to get this merged into jdk9dev and would appreciate any help. Thanks, Ian Rogers, Google. --- Allow --with-extra-cxxflags to work with HotSpot. Pass down EXTRA_CXXFLAGS from gnumake's invocation or environment. diff -r fff6b54e9770 make/aix/makefiles/vm.make --- a/make/aix/makefiles/vm.make Thu Jul 16 19:28:37 2015 -0700 +++ b/make/aix/makefiles/vm.make Tue Jul 21 08:55:08 2015 -0700 @@ -112,6 +112,7 @@ # Extra flags from gnumake's invocation or environment CFLAGS += $(EXTRA_CFLAGS) LFLAGS += $(EXTRA_CFLAGS) +CXXFLAGS += $(EXTRA_CXXFLAGS) # Don't set excutable bit on stack segment # the same could be done by separate execstack command diff -r fff6b54e9770 make/bsd/makefiles/vm.make --- a/make/bsd/makefiles/vm.make Thu Jul 16 19:28:37 2015 -0700 +++ b/make/bsd/makefiles/vm.make Tue Jul 21 08:55:08 2015 -0700 @@ -114,6 +114,7 @@ # Extra flags from gnumake's invocation or environment CFLAGS += $(EXTRA_CFLAGS) LFLAGS += $(EXTRA_CFLAGS) +CXXFLAGS += $(EXTRA_CXXFLAGS) # Don't set excutable bit on stack segment # the same could be done by separate execstack command diff -r fff6b54e9770 make/linux/makefiles/vm.make --- a/make/linux/makefiles/vm.make Thu Jul 16 19:28:37 2015 -0700 +++ b/make/linux/makefiles/vm.make Tue Jul 21 08:55:08 2015 -0700 @@ -117,6 +117,7 @@ # Extra flags from gnumake's invocation or environment CFLAGS += $(EXTRA_CFLAGS) LFLAGS += $(EXTRA_CFLAGS) +CXXFLAGS += $(EXTRA_CXXFLAGS) # Don't set excutable bit on stack segment # the same could be done by separate execstack command diff -r fff6b54e9770 make/solaris/makefiles/vm.make --- a/make/solaris/makefiles/vm.make Thu Jul 16 19:28:37 2015 -0700 +++ b/make/solaris/makefiles/vm.make Tue Jul 21 08:55:08 2015 -0700 @@ -110,6 +110,7 @@ # Extra flags from gnumake's invocation or environment CFLAGS += $(EXTRA_CFLAGS) +CXXFLAGS += $(EXTRA_CXXFLAGS) # Math Library (libm.so), do not use -lm. # There might be two versions of libm.so on the build system: From daniel.daugherty at oracle.com Tue Jul 21 18:57:03 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 21 Jul 2015 12:57:03 -0600 Subject: [8u66] RFR 8079410: Hotspot version to share the same update and build version from JDK In-Reply-To: <55AD963C.8010203@oracle.com> References: <55AD963C.8010203@oracle.com> Message-ID: <55AE95FF.1090100@oracle.com> On 7/20/15 6:45 PM, Alejandro E Murillo wrote: > > Please review the following change that allows setting > the Hotspot minor version and build number to that > of the "--with-update-version" and "--with-build-number" > configure parameters when provided. 8u builds only. > > webrev: > http://javaweb.us.oracle.com/~amurillo/webrevs/8079410/ hotspot/make/defs.make No comments. hotspot/make/hotspot_version No comments. Thumbs up. Just FYI: the patch link in that webrev goes to an empty page. Dan > > Background (since bug was originally filed as internal): > > Currently, for 8u builds and earlier, the hotspot version looks like this > (remnant from the hotspot express days): > > Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) > > > By convention, minor version (66 above) always matches the JDK update > version > and hotspot build number is managed independently of the JDK build > number. > Both values are defined by default in "hotspot/make/hotspot_version". > With this change they can now be setup using the corresponding JDK > configure parameters. > > Consequences: > > (1) For promoted and other milestone builds, the hotspot minor version > will corresponds to the JDK update version and the hotspot build number > will match the JDK build number. > > (2) Hotspot snapshots will no longer need to change the hotspot build > number > as that will be set at promotion time (matching the JDK build number). > Since this is stored in the file mentioned above, a repo push > (and the corresponding bug) was required to change it. > That will no longer be necessary. > > (3) Since JPRT configures both the update and build numbers, > when building via JPRT, the hotspot build number for those builds > will always be 'b00' (matching the JDK build number). The Hotspot > minor version will match the update version defined in > make/jprt.prtoperties: > > java version "1.8.0_66-internal" > # Java(TM) SE Runtime Environment (build > 1.8.0_66-internal-20150720195933.amurillo.8079410-control-b00) > # Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) > > (4) Since the version string is not actually changing, I do not expect > this to have > any impact on external tools or apps, but let me know if so. > > Thanks > From alejandro.murillo at oracle.com Tue Jul 21 18:59:06 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 21 Jul 2015 12:59:06 -0600 Subject: [8u66] RFR 8079410: Hotspot version to share the same update and build version from JDK In-Reply-To: <55AE95FF.1090100@oracle.com> References: <55AD963C.8010203@oracle.com> <55AE95FF.1090100@oracle.com> Message-ID: <55AE967A.9090906@oracle.com> Thanks Dan. Will check why the patch is empty. Alejandro On 7/21/2015 12:57 PM, Daniel D. Daugherty wrote: > On 7/20/15 6:45 PM, Alejandro E Murillo wrote: >> >> Please review the following change that allows setting >> the Hotspot minor version and build number to that >> of the "--with-update-version" and "--with-build-number" >> configure parameters when provided. 8u builds only. >> >> webrev: >> http://cr.openjdk.java.net/~amurillo/8u66/8079410/ > > hotspot/make/defs.make > No comments. > > hotspot/make/hotspot_version > No comments. > > Thumbs up. > > Just FYI: the patch link in that webrev goes to an empty page. > > Dan > > > >> >> Background (since bug was originally filed as internal): >> >> Currently, for 8u builds and earlier, the hotspot version looks like >> this >> (remnant from the hotspot express days): >> >> Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) >> >> >> By convention, minor version (66 above) always matches the JDK update >> version >> and hotspot build number is managed independently of the JDK build >> number. >> Both values are defined by default in "hotspot/make/hotspot_version". >> With this change they can now be setup using the corresponding JDK >> configure parameters. >> >> Consequences: >> >> (1) For promoted and other milestone builds, the hotspot minor version >> will corresponds to the JDK update version and the hotspot build number >> will match the JDK build number. >> >> (2) Hotspot snapshots will no longer need to change the hotspot build >> number >> as that will be set at promotion time (matching the JDK build number). >> Since this is stored in the file mentioned above, a repo push >> (and the corresponding bug) was required to change it. >> That will no longer be necessary. >> >> (3) Since JPRT configures both the update and build numbers, >> when building via JPRT, the hotspot build number for those builds >> will always be 'b00' (matching the JDK build number). The Hotspot >> minor version will match the update version defined in >> make/jprt.prtoperties: >> >> java version "1.8.0_66-internal" >> # Java(TM) SE Runtime Environment (build >> 1.8.0_66-internal-20150720195933.amurillo.8079410-control-b00) >> # Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) >> >> (4) Since the version string is not actually changing, I do not >> expect this to have >> any impact on external tools or apps, but let me know if so. >> >> Thanks >> > -- Alejandro From philip.race at oracle.com Tue Jul 21 19:11:31 2015 From: philip.race at oracle.com (Phil Race) Date: Tue, 21 Jul 2015 12:11:31 -0700 Subject: [8u66] 8130938: Incomplete 8ux fix for 8071710: libfontmanager & t2k should link against headless awt on solaris Message-ID: <55AE9963.3090304@oracle.com> Bug : https://bugs.openjdk.java.net/browse/JDK-8130938 8071710 fixed the issue of libfontmanager and libt2k linking against X11 on JDK 9 for Solaris. This was subsequently backported to JDK8u but one line was missed so incorrectly libt2k still depends on X11 libraries on 8u. This is a request for review and approval to push to 8u66. The one line change is in-line below. jprt verified the build. hg diff make/lib/Awt2dLibraries.gmk diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk --- a/make/lib/Awt2dLibraries.gmk +++ b/make/lib/Awt2dLibraries.gmk @@ -983,7 +983,7 @@ $(call SET_SHARED_LIBRARY_ORIGIN), \ LDFLAGS_windows := user32.lib $(JDK_OUTPUTDIR)/objs/libfontmanager/fontmanager.lib, \ LDFLAGS_SUFFIX_posix := $(LIBM) $(LIBCXX) -lfontmanager -ljava -ljvm -lc, \ - LDFLAGS_SUFFIX_solaris := -lawt -lawt_xawt, \ + LDFLAGS_SUFFIX_solaris := -lawt -lawt_headless, \ VERSIONINFO_RESOURCE := $(JDK_TOPDIR)/src/windows/resource/version.rc, \ RC_FLAGS := $(RC_FLAGS) \ -D "JDK_FNAME=t2k.dll" \ -phil. From sean.coffey at oracle.com Tue Jul 21 21:04:40 2015 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Tue, 21 Jul 2015 22:04:40 +0100 Subject: [8u66] 8130938: Incomplete 8ux fix for 8071710: libfontmanager & t2k should link against headless awt on solaris In-Reply-To: <55AE9963.3090304@oracle.com> References: <55AE9963.3090304@oracle.com> Message-ID: <55AEB3E8.7050404@oracle.com> Looks fine to me Phil. Thanks for handling. Approved. RDP2 for 8u66 [1] is approaching fast. We'll have to work out if this makes the PIT snapshot. [1] http://openjdk.java.net/projects/jdk8u/releases/8u66.html Regards, Sean. On 21/07/2015 20:11, Phil Race wrote: > > Bug : https://bugs.openjdk.java.net/browse/JDK-8130938 > > 8071710 fixed the issue of libfontmanager and libt2k linking against > X11 on JDK 9 for Solaris. > This was subsequently backported to JDK8u but one line was missed so > incorrectly libt2k > still depends on X11 libraries on 8u. > > This is a request for review and approval to push to 8u66. > > The one line change is in-line below. jprt verified the build. > > hg diff make/lib/Awt2dLibraries.gmk > diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk > --- a/make/lib/Awt2dLibraries.gmk > +++ b/make/lib/Awt2dLibraries.gmk > @@ -983,7 +983,7 @@ > $(call SET_SHARED_LIBRARY_ORIGIN), \ > LDFLAGS_windows := user32.lib > $(JDK_OUTPUTDIR)/objs/libfontmanager/fontmanager.lib, \ > LDFLAGS_SUFFIX_posix := $(LIBM) $(LIBCXX) -lfontmanager -ljava > -ljvm -lc, \ > - LDFLAGS_SUFFIX_solaris := -lawt -lawt_xawt, \ > + LDFLAGS_SUFFIX_solaris := -lawt -lawt_headless, \ > VERSIONINFO_RESOURCE := > $(JDK_TOPDIR)/src/windows/resource/version.rc, \ > RC_FLAGS := $(RC_FLAGS) \ > -D "JDK_FNAME=t2k.dll" \ > > -phil. From sean.coffey at oracle.com Tue Jul 21 21:07:48 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Tue, 21 Jul 2015 22:07:48 +0100 Subject: [8u66] RFR 8079410: Hotspot version to share the same update and build version from JDK In-Reply-To: <55ADACC8.1060506@oracle.com> References: <55AD963C.8010203@oracle.com> <55AD9BF7.8070906@oracle.com> <55ADACC8.1060506@oracle.com> Message-ID: <55AEB4A4.50205@oracle.com> Great to see this model coming into sync with the JDK build versions. Looks good. Regards, Sean. On 21/07/2015 03:22, Alejandro E Murillo wrote: > > > On 7/20/2015 7:10 PM, David Holmes wrote: >> Hi Alejandro, >> >> On 21/07/2015 10:45 AM, Alejandro E Murillo wrote: >>> >>> Please review the following change that allows setting >>> the Hotspot minor version and build number to that >>> of the "--with-update-version" and "--with-build-number" >>> configure parameters when provided. 8u builds only. >>> >>> webrev: >>> http://cr.openjdk.java.net/~amurillo/8u66/8079410/ >> >> The logic seems fine. I would have put it in the hotspot_version file >> directly I think, but it's okay as is. > right, I could have put it there as well. >> >> I presume we will still update the default update version at the >> start of each new release cycle. > Yes, but only necessary for non milestone or jprt builds > Thanks > Alejandro >> >> Thanks, >> David >> >>> Background (since bug was originally filed as internal): >>> >>> Currently, for 8u builds and earlier, the hotspot version looks like >>> this >>> (remnant from the hotspot express days): >>> >>> Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) >>> >>> >>> By convention, minor version (66 above) always matches the JDK update >>> version >>> and hotspot build number is managed independently of the JDK build >>> number. >>> Both values are defined by default in "hotspot/make/hotspot_version". >>> With this change they can now be setup using the corresponding JDK >>> configure parameters. >>> >>> Consequences: >>> >>> (1) For promoted and other milestone builds, the hotspot minor version >>> will corresponds to the JDK update version and the hotspot build number >>> will match the JDK build number. >>> >>> (2) Hotspot snapshots will no longer need to change the hotspot build >>> number >>> as that will be set at promotion time (matching the JDK build number). >>> Since this is stored in the file mentioned above, a repo push >>> (and the corresponding bug) was required to change it. >>> That will no longer be necessary. >>> >>> (3) Since JPRT configures both the update and build numbers, >>> when building via JPRT, the hotspot build number for those builds >>> will always be 'b00' (matching the JDK build number). The Hotspot >>> minor version will match the update version defined in >>> make/jprt.prtoperties: >>> >>> java version "1.8.0_66-internal" >>> # Java(TM) SE Runtime Environment (build >>> 1.8.0_66-internal-20150720195933.amurillo.8079410-control-b00) >>> # Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing) >>> >>> (4) Since the version string is not actually changing, I do not expect >>> this to have >>> any impact on external tools or apps, but let me know if so. >>> >>> Thanks >>> > From david.holmes at oracle.com Tue Jul 21 23:20:25 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Jul 2015 09:20:25 +1000 Subject: Allow --with-extra-cxxflags to work with HotSpot. In-Reply-To: References: Message-ID: <55AED3B9.1020708@oracle.com> Hi Ian, On 22/07/2015 3:01 AM, Ian Rogers wrote: > The following (modest) patch against jdk9dev allows the top-level configure > with --with-extra-cxxflags to pass options to the HotSpot build. An example > would be: > > configure --fastdebug --with-extra-cxxflags=-std=c++11 > > Unless --with-extra-cxxflags is specified the option has no effect. I'd > like to work to get this merged into jdk9dev and would appreciate any help. Unfortunately this is not quite as simple as it appears due to the mess in the hotspot build system regarding flags usage. Once upon a time we had CFLAGS and CPPFLAGS but there was confusion whether CPP meant C++ or C-pre-processor. It actually meant the latter but was mistakenly thought to be the former (g++ args versus gcc args) and was eventually renamed to CXXFLAGS. This results in quite a mess because we have eg: ./linux/makefiles/rules.make:CC_COMPILE = $(CC) $(CXXFLAGS) $(CFLAGS) ./linux/makefiles/rules.make:CXX_COMPILE = $(CXX) $(CXXFLAGS) $(CFLAGS) which combines the "C" flags (which were always intended to just be the compiler flags, which was a combined C/C++ compiler anyway) and the (now) C++ flags (most of which are not at all C++ specific). So it will get the EXTRA_CFLAGS and the EXTRA_CXXFLAGS on each compilation. Then things get worse because hotspot uses both sets of flags but the JDK uses CXXFLAGS as the primary compiler flags. So taking cross-compilation as an example, we set EXTRA_CFLAGS to hold the cross-compiler flags used in hotspot, and set EXTRA_CXXFLAGS to hold the cross-compiler flags for the JDK build. So with your proposed change we will now get the cross-compiler flags specified twice on each command-line in the hotspot build. Whether that is harmful I don't know - I'm just pointing out that this is far from clear cut and would need some resources to establish that the change is indeed safe. This should all be resolved once the hotspot build is converted to be a full configure-based build. And because that is in the pipeline we avoid doing any major surgery to the (fragile) hotspot build system. David ----- > Thanks, > Ian Rogers, Google. > > --- > Allow --with-extra-cxxflags to work with HotSpot. > > Pass down EXTRA_CXXFLAGS from gnumake's invocation or environment. > > diff -r fff6b54e9770 make/aix/makefiles/vm.make > --- a/make/aix/makefiles/vm.make Thu Jul 16 19:28:37 2015 -0700 > +++ b/make/aix/makefiles/vm.make Tue Jul 21 08:55:08 2015 -0700 > @@ -112,6 +112,7 @@ > # Extra flags from gnumake's invocation or environment > CFLAGS += $(EXTRA_CFLAGS) > LFLAGS += $(EXTRA_CFLAGS) > +CXXFLAGS += $(EXTRA_CXXFLAGS) > > # Don't set excutable bit on stack segment > # the same could be done by separate execstack command > diff -r fff6b54e9770 make/bsd/makefiles/vm.make > --- a/make/bsd/makefiles/vm.make Thu Jul 16 19:28:37 2015 -0700 > +++ b/make/bsd/makefiles/vm.make Tue Jul 21 08:55:08 2015 -0700 > @@ -114,6 +114,7 @@ > # Extra flags from gnumake's invocation or environment > CFLAGS += $(EXTRA_CFLAGS) > LFLAGS += $(EXTRA_CFLAGS) > +CXXFLAGS += $(EXTRA_CXXFLAGS) > > # Don't set excutable bit on stack segment > # the same could be done by separate execstack command > diff -r fff6b54e9770 make/linux/makefiles/vm.make > --- a/make/linux/makefiles/vm.make Thu Jul 16 19:28:37 2015 -0700 > +++ b/make/linux/makefiles/vm.make Tue Jul 21 08:55:08 2015 -0700 > @@ -117,6 +117,7 @@ > # Extra flags from gnumake's invocation or environment > CFLAGS += $(EXTRA_CFLAGS) > LFLAGS += $(EXTRA_CFLAGS) > +CXXFLAGS += $(EXTRA_CXXFLAGS) > > # Don't set excutable bit on stack segment > # the same could be done by separate execstack command > diff -r fff6b54e9770 make/solaris/makefiles/vm.make > --- a/make/solaris/makefiles/vm.make Thu Jul 16 19:28:37 2015 -0700 > +++ b/make/solaris/makefiles/vm.make Tue Jul 21 08:55:08 2015 -0700 > @@ -110,6 +110,7 @@ > > # Extra flags from gnumake's invocation or environment > CFLAGS += $(EXTRA_CFLAGS) > +CXXFLAGS += $(EXTRA_CXXFLAGS) > > # Math Library (libm.so), do not use -lm. > # There might be two versions of libm.so on the build system: > From volker.simonis at gmail.com Wed Jul 22 08:18:01 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 22 Jul 2015 10:18:01 +0200 Subject: Allow --with-extra-cxxflags to work with HotSpot. In-Reply-To: <55AED3B9.1020708@oracle.com> References: <55AED3B9.1020708@oracle.com> Message-ID: Hi Ian, as David already pointed out, the hotspot build is currently being converted to the configure-based build anyway. You can already test it by cloning http://hg.openjdk.java.net/build-infra/jdk9 and configuring with "--enable-new-hotspot-build" ("--disable-new-hotspot-build" is still the default). The new build is still in a very early stage (currently only the 'product' build is working) but it should give you an idea of how it will work. Actually you should get "--with-extra-cxxflags" for free in the new build system also I'm not sure it already works (and haven?t tested it yet). Currently the work on the new build system got a little stuck because of holidays but as far as I know the plan is still to bring this into jdk9. If you have any suggestions for improvements the build-infra repo and mailing list are definitive the way to go. And if you have some good patches against build-infra I can try to help and sponsor them. Regards, Volker On Wed, Jul 22, 2015 at 1:20 AM, David Holmes wrote: > Hi Ian, > > On 22/07/2015 3:01 AM, Ian Rogers wrote: >> >> The following (modest) patch against jdk9dev allows the top-level >> configure >> with --with-extra-cxxflags to pass options to the HotSpot build. An >> example >> would be: >> >> configure --fastdebug --with-extra-cxxflags=-std=c++11 >> >> Unless --with-extra-cxxflags is specified the option has no effect. I'd >> like to work to get this merged into jdk9dev and would appreciate any >> help. > > > Unfortunately this is not quite as simple as it appears due to the mess in > the hotspot build system regarding flags usage. Once upon a time we had > CFLAGS and CPPFLAGS but there was confusion whether CPP meant C++ or > C-pre-processor. It actually meant the latter but was mistakenly thought to > be the former (g++ args versus gcc args) and was eventually renamed to > CXXFLAGS. This results in quite a mess because we have eg: > > ./linux/makefiles/rules.make:CC_COMPILE = $(CC) $(CXXFLAGS) $(CFLAGS) > ./linux/makefiles/rules.make:CXX_COMPILE = $(CXX) $(CXXFLAGS) $(CFLAGS) > > which combines the "C" flags (which were always intended to just be the > compiler flags, which was a combined C/C++ compiler anyway) and the (now) > C++ flags (most of which are not at all C++ specific). So it will get the > EXTRA_CFLAGS and the EXTRA_CXXFLAGS on each compilation. > > Then things get worse because hotspot uses both sets of flags but the JDK > uses CXXFLAGS as the primary compiler flags. So taking cross-compilation as > an example, we set EXTRA_CFLAGS to hold the cross-compiler flags used in > hotspot, and set EXTRA_CXXFLAGS to hold the cross-compiler flags for the JDK > build. So with your proposed change we will now get the cross-compiler flags > specified twice on each command-line in the hotspot build. Whether that is > harmful I don't know - I'm just pointing out that this is far from clear cut > and would need some resources to establish that the change is indeed safe. > > This should all be resolved once the hotspot build is converted to be a full > configure-based build. And because that is in the pipeline we avoid doing > any major surgery to the (fragile) hotspot build system. > > David > ----- > > > >> Thanks, >> Ian Rogers, Google. >> >> --- >> Allow --with-extra-cxxflags to work with HotSpot. >> >> Pass down EXTRA_CXXFLAGS from gnumake's invocation or environment. >> >> diff -r fff6b54e9770 make/aix/makefiles/vm.make >> --- a/make/aix/makefiles/vm.make Thu Jul 16 19:28:37 2015 -0700 >> +++ b/make/aix/makefiles/vm.make Tue Jul 21 08:55:08 2015 -0700 >> @@ -112,6 +112,7 @@ >> # Extra flags from gnumake's invocation or environment >> CFLAGS += $(EXTRA_CFLAGS) >> LFLAGS += $(EXTRA_CFLAGS) >> +CXXFLAGS += $(EXTRA_CXXFLAGS) >> >> # Don't set excutable bit on stack segment >> # the same could be done by separate execstack command >> diff -r fff6b54e9770 make/bsd/makefiles/vm.make >> --- a/make/bsd/makefiles/vm.make Thu Jul 16 19:28:37 2015 -0700 >> +++ b/make/bsd/makefiles/vm.make Tue Jul 21 08:55:08 2015 -0700 >> @@ -114,6 +114,7 @@ >> # Extra flags from gnumake's invocation or environment >> CFLAGS += $(EXTRA_CFLAGS) >> LFLAGS += $(EXTRA_CFLAGS) >> +CXXFLAGS += $(EXTRA_CXXFLAGS) >> >> # Don't set excutable bit on stack segment >> # the same could be done by separate execstack command >> diff -r fff6b54e9770 make/linux/makefiles/vm.make >> --- a/make/linux/makefiles/vm.make Thu Jul 16 19:28:37 2015 -0700 >> +++ b/make/linux/makefiles/vm.make Tue Jul 21 08:55:08 2015 -0700 >> @@ -117,6 +117,7 @@ >> # Extra flags from gnumake's invocation or environment >> CFLAGS += $(EXTRA_CFLAGS) >> LFLAGS += $(EXTRA_CFLAGS) >> +CXXFLAGS += $(EXTRA_CXXFLAGS) >> >> # Don't set excutable bit on stack segment >> # the same could be done by separate execstack command >> diff -r fff6b54e9770 make/solaris/makefiles/vm.make >> --- a/make/solaris/makefiles/vm.make Thu Jul 16 19:28:37 2015 -0700 >> +++ b/make/solaris/makefiles/vm.make Tue Jul 21 08:55:08 2015 -0700 >> @@ -110,6 +110,7 @@ >> >> # Extra flags from gnumake's invocation or environment >> CFLAGS += $(EXTRA_CFLAGS) >> +CXXFLAGS += $(EXTRA_CXXFLAGS) >> >> # Math Library (libm.so), do not use -lm. >> # There might be two versions of libm.so on the build system: >> > From philip.race at oracle.com Wed Jul 22 16:46:47 2015 From: philip.race at oracle.com (Phil Race) Date: Wed, 22 Jul 2015 09:46:47 -0700 Subject: [8u66] 8130938: Incomplete 8ux fix for 8071710: libfontmanager & t2k should link against headless awt on solaris In-Reply-To: <55AEB3E8.7050404@oracle.com> References: <55AE9963.3090304@oracle.com> <55AEB3E8.7050404@oracle.com> Message-ID: <55AFC8F7.1000505@oracle.com> Could I please also have a code review from some one ? There's not much time before PIT freeze .. -phil On 07/21/2015 02:04 PM, Se?n Coffey wrote: > Looks fine to me Phil. Thanks for handling. > > Approved. RDP2 for 8u66 [1] is approaching fast. We'll have to work > out if this makes the PIT snapshot. > > [1] http://openjdk.java.net/projects/jdk8u/releases/8u66.html > > Regards, > Sean. > > On 21/07/2015 20:11, Phil Race wrote: >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8130938 >> >> 8071710 fixed the issue of libfontmanager and libt2k linking against >> X11 on JDK 9 for Solaris. >> This was subsequently backported to JDK8u but one line was missed so >> incorrectly libt2k >> still depends on X11 libraries on 8u. >> >> This is a request for review and approval to push to 8u66. >> >> The one line change is in-line below. jprt verified the build. >> >> hg diff make/lib/Awt2dLibraries.gmk >> diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk >> --- a/make/lib/Awt2dLibraries.gmk >> +++ b/make/lib/Awt2dLibraries.gmk >> @@ -983,7 +983,7 @@ >> $(call SET_SHARED_LIBRARY_ORIGIN), \ >> LDFLAGS_windows := user32.lib >> $(JDK_OUTPUTDIR)/objs/libfontmanager/fontmanager.lib, \ >> LDFLAGS_SUFFIX_posix := $(LIBM) $(LIBCXX) -lfontmanager -ljava >> -ljvm -lc, \ >> - LDFLAGS_SUFFIX_solaris := -lawt -lawt_xawt, \ >> + LDFLAGS_SUFFIX_solaris := -lawt -lawt_headless, \ >> VERSIONINFO_RESOURCE := >> $(JDK_TOPDIR)/src/windows/resource/version.rc, \ >> RC_FLAGS := $(RC_FLAGS) \ >> -D "JDK_FNAME=t2k.dll" \ >> >> -phil. > From Sergey.Bylokhov at oracle.com Wed Jul 22 17:28:16 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 22 Jul 2015 20:28:16 +0300 Subject: [8u66] 8130938: Incomplete 8ux fix for 8071710: libfontmanager & t2k should link against headless awt on solaris In-Reply-To: <55AFC8F7.1000505@oracle.com> References: <55AE9963.3090304@oracle.com> <55AEB3E8.7050404@oracle.com> <55AFC8F7.1000505@oracle.com> Message-ID: <55AFD2B0.4090403@oracle.com> Looks fine. On 22.07.15 19:46, Phil Race wrote: > Could I please also have a code review from some one ? > There's not much time before PIT freeze .. > > -phil > > On 07/21/2015 02:04 PM, Se?n Coffey wrote: >> Looks fine to me Phil. Thanks for handling. >> >> Approved. RDP2 for 8u66 [1] is approaching fast. We'll have to work >> out if this makes the PIT snapshot. >> >> [1] http://openjdk.java.net/projects/jdk8u/releases/8u66.html >> >> Regards, >> Sean. >> >> On 21/07/2015 20:11, Phil Race wrote: >>> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8130938 >>> >>> 8071710 fixed the issue of libfontmanager and libt2k linking against >>> X11 on JDK 9 for Solaris. >>> This was subsequently backported to JDK8u but one line was missed so >>> incorrectly libt2k >>> still depends on X11 libraries on 8u. >>> >>> This is a request for review and approval to push to 8u66. >>> >>> The one line change is in-line below. jprt verified the build. >>> >>> hg diff make/lib/Awt2dLibraries.gmk >>> diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk >>> --- a/make/lib/Awt2dLibraries.gmk >>> +++ b/make/lib/Awt2dLibraries.gmk >>> @@ -983,7 +983,7 @@ >>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>> LDFLAGS_windows := user32.lib >>> $(JDK_OUTPUTDIR)/objs/libfontmanager/fontmanager.lib, \ >>> LDFLAGS_SUFFIX_posix := $(LIBM) $(LIBCXX) -lfontmanager >>> -ljava -ljvm -lc, \ >>> - LDFLAGS_SUFFIX_solaris := -lawt -lawt_xawt, \ >>> + LDFLAGS_SUFFIX_solaris := -lawt -lawt_headless, \ >>> VERSIONINFO_RESOURCE := >>> $(JDK_TOPDIR)/src/windows/resource/version.rc, \ >>> RC_FLAGS := $(RC_FLAGS) \ >>> -D "JDK_FNAME=t2k.dll" \ >>> >>> -phil. >> > -- Best regards, Sergey. From alexander.zvegintsev at oracle.com Wed Jul 22 18:24:09 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 22 Jul 2015 21:24:09 +0300 Subject: [OpenJDK 2D-Dev] [8u66] 8130938: Incomplete 8ux fix for 8071710: libfontmanager & t2k should link against headless awt on solaris In-Reply-To: <55AFD2B0.4090403@oracle.com> References: <55AE9963.3090304@oracle.com> <55AEB3E8.7050404@oracle.com> <55AFC8F7.1000505@oracle.com> <55AFD2B0.4090403@oracle.com> Message-ID: <55AFDFC9.6040703@oracle.com> +1 -- Thanks, Alexander. On 22.07.2015 20:28, Sergey Bylokhov wrote: > Looks fine. > > On 22.07.15 19:46, Phil Race wrote: >> Could I please also have a code review from some one ? >> There's not much time before PIT freeze .. >> >> -phil >> >> On 07/21/2015 02:04 PM, Se?n Coffey wrote: >>> Looks fine to me Phil. Thanks for handling. >>> >>> Approved. RDP2 for 8u66 [1] is approaching fast. We'll have to work >>> out if this makes the PIT snapshot. >>> >>> [1] http://openjdk.java.net/projects/jdk8u/releases/8u66.html >>> >>> Regards, >>> Sean. >>> >>> On 21/07/2015 20:11, Phil Race wrote: >>>> >>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8130938 >>>> >>>> 8071710 fixed the issue of libfontmanager and libt2k linking >>>> against X11 on JDK 9 for Solaris. >>>> This was subsequently backported to JDK8u but one line was missed >>>> so incorrectly libt2k >>>> still depends on X11 libraries on 8u. >>>> >>>> This is a request for review and approval to push to 8u66. >>>> >>>> The one line change is in-line below. jprt verified the build. >>>> >>>> hg diff make/lib/Awt2dLibraries.gmk >>>> diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk >>>> --- a/make/lib/Awt2dLibraries.gmk >>>> +++ b/make/lib/Awt2dLibraries.gmk >>>> @@ -983,7 +983,7 @@ >>>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>> LDFLAGS_windows := user32.lib >>>> $(JDK_OUTPUTDIR)/objs/libfontmanager/fontmanager.lib, \ >>>> LDFLAGS_SUFFIX_posix := $(LIBM) $(LIBCXX) -lfontmanager >>>> -ljava -ljvm -lc, \ >>>> - LDFLAGS_SUFFIX_solaris := -lawt -lawt_xawt, \ >>>> + LDFLAGS_SUFFIX_solaris := -lawt -lawt_headless, \ >>>> VERSIONINFO_RESOURCE := >>>> $(JDK_TOPDIR)/src/windows/resource/version.rc, \ >>>> RC_FLAGS := $(RC_FLAGS) \ >>>> -D "JDK_FNAME=t2k.dll" \ >>>> >>>> -phil. >>> >> > > From jan.lahoda at oracle.com Mon Jul 27 11:49:30 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 27 Jul 2015 13:49:30 +0200 Subject: RFR JDK-8129562: JDK 9 build using boot-jdk classes instead of newly compiled classes Message-ID: <55B61ACA.1070200@oracle.com> Hi, Bug: https://bugs.openjdk.java.net/browse/JDK-8129562 As part of the fix for JDK-8054717, CompileJavaModules.gmk is now using an "empty" bootclasspath (classes like java.lang.Object are loaded from the ordinary classpath as needed). Unfortunately, javac is still using the default ext and endorsed dirs (if available in the boot JDK), and classes that are in the ext dirs have precedence over the classes from the classpath. Which may cause compilation problems with the ext dirs contain an older version of a class. The proposal is to make ext and endorsed dirs "empty" as well (both ext and endorsed dirs will contain one entry, and the entry will be an empty directory): http://cr.openjdk.java.net/~jlahoda/8129562/webrev.00/ What do you think? Thanks, Jan From florian.gauvin at nl.thalesgroup.com Tue Jul 28 11:36:46 2015 From: florian.gauvin at nl.thalesgroup.com (GAUVIN Florian) Date: Tue, 28 Jul 2015 11:36:46 +0000 Subject: Error building openjdk8 compact profiles Message-ID: <5FD223E653528046A87219078E495127E93F0B@spvw1967.ONE-05.GRP> Hi, I have this error building openjdk8 compact profiles : " ## Starting profiles gmake[2]: *** No rule to make target `/home/student/Documents/openjdk8/build/linux-x86_64-normal-zero-release/images/beanless/java/util/jar/Pack200\$Packer.class', needed by `/home/student/Documents/openjdk8/build/linux-x86_64-normal-zero-release/images/libprofile_1/rt.jar'. Stop. gmake[2]: *** Waiting for unfinished jobs.... gmake[1]: *** [profile_1] Error 2 make: *** [profiles-only] Error 2 [student at localhost openjdk8]$ make -v GNU Make 3.82 Built for x86_64-redhat-linux-gnu Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. " I have read on a website that it's because of make 4.0 but it's not the one that I'm using. I'm using make 3.82 and I work on centos 7. Do you have an idea why? ------------------------------------------------------------------------------------------------------------ Disclaimer: If you are not the intended recipient of this email, please notify the sender and delete it. Any unauthorized copying, disclosure or distribution of this email or its attachment(s) is forbidden. Thales Nederland BV will not accept liability for any damage caused by this email or its attachment(s). Thales Nederland BV is seated in Hengelo and is registered at the Chamber of Commerce under number 06061578. ------------------------------------------------------------------------------------------------------------ From david.holmes at oracle.com Tue Jul 28 12:06:17 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Jul 2015 22:06:17 +1000 Subject: Error building openjdk8 compact profiles In-Reply-To: <5FD223E653528046A87219078E495127E93F0B@spvw1967.ONE-05.GRP> References: <5FD223E653528046A87219078E495127E93F0B@spvw1967.ONE-05.GRP> Message-ID: <55B77039.8050108@oracle.com> On 28/07/2015 9:36 PM, GAUVIN Florian wrote: > Hi, > I have this error building openjdk8 compact profiles : > " > ## Starting profiles > gmake[2]: *** No rule to make target `/home/student/Documents/openjdk8/build/linux-x86_64-normal-zero-release/images/beanless/java/util/jar/Pack200\$Packer.class', needed by `/home/student/Documents/openjdk8/build/linux-x86_64-normal-zero-release/images/libprofile_1/rt.jar'. Stop. > gmake[2]: *** Waiting for unfinished jobs.... > gmake[1]: *** [profile_1] Error 2 > make: *** [profiles-only] Error 2 > [student at localhost openjdk8]$ make -v > GNU Make 3.82 > Built for x86_64-redhat-linux-gnu > Copyright (C) 2010 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > " > > I have read on a website that it's because of make 4.0 but it's not the one that I'm using. I'm using make 3.82 and I work on centos 7. > Do you have an idea why? As I recall it is an issue with make and the shell. But I also thought that Erik had since fixed this issue. What actual version of the sources are you building? David > > > ------------------------------------------------------------------------------------------------------------ > Disclaimer: > > If you are not the intended recipient of this email, please notify the sender and > delete it. > Any unauthorized copying, disclosure or distribution of this email or its > attachment(s) is forbidden. > Thales Nederland BV will not accept liability for any damage caused by this email or > its attachment(s). > Thales Nederland BV is seated in Hengelo and is registered at the Chamber of > Commerce under number 06061578. > ------------------------------------------------------------------------------------------------------------ > From david.holmes at oracle.com Tue Jul 28 12:09:38 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Jul 2015 22:09:38 +1000 Subject: Error building openjdk8 compact profiles In-Reply-To: <55B77039.8050108@oracle.com> References: <5FD223E653528046A87219078E495127E93F0B@spvw1967.ONE-05.GRP> <55B77039.8050108@oracle.com> Message-ID: <55B77102.9050904@oracle.com> Also see attached. David On 28/07/2015 10:06 PM, David Holmes wrote: > On 28/07/2015 9:36 PM, GAUVIN Florian wrote: >> Hi, >> I have this error building openjdk8 compact profiles : >> " >> ## Starting profiles >> gmake[2]: *** No rule to make target >> `/home/student/Documents/openjdk8/build/linux-x86_64-normal-zero-release/images/beanless/java/util/jar/Pack200\$Packer.class', >> needed by >> `/home/student/Documents/openjdk8/build/linux-x86_64-normal-zero-release/images/libprofile_1/rt.jar'. >> Stop. >> gmake[2]: *** Waiting for unfinished jobs.... >> gmake[1]: *** [profile_1] Error 2 >> make: *** [profiles-only] Error 2 >> [student at localhost openjdk8]$ make -v >> GNU Make 3.82 >> Built for x86_64-redhat-linux-gnu >> Copyright (C) 2010 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. >> " >> >> I have read on a website that it's because of make 4.0 but it's not >> the one that I'm using. I'm using make 3.82 and I work on centos 7. >> Do you have an idea why? > > As I recall it is an issue with make and the shell. But I also thought > that Erik had since fixed this issue. What actual version of the sources > are you building? > > David > >> >> >> ------------------------------------------------------------------------------------------------------------ >> >> Disclaimer: >> >> If you are not the intended recipient of this email, please notify the >> sender and >> delete it. >> Any unauthorized copying, disclosure or distribution of this email or its >> attachment(s) is forbidden. >> Thales Nederland BV will not accept liability for any damage caused by >> this email or >> its attachment(s). >> Thales Nederland BV is seated in Hengelo and is registered at the >> Chamber of >> Commerce under number 06061578. >> ------------------------------------------------------------------------------------------------------------ >> >> -------------- next part -------------- An embedded message was scrubbed... From: David Holmes Subject: Re: OpenJDK 8 compact profiles fail to build with make 4.0 Date: Tue, 03 Jun 2014 12:41:04 +1000 Size: 8016 URL: From florian.gauvin at nl.thalesgroup.com Tue Jul 28 13:03:55 2015 From: florian.gauvin at nl.thalesgroup.com (GAUVIN Florian) Date: Tue, 28 Jul 2015 13:03:55 +0000 Subject: Error building openjdk8 compact profiles In-Reply-To: <55B77102.9050904@oracle.com> References: <5FD223E653528046A87219078E495127E93F0B@spvw1967.ONE-05.GRP> <55B77039.8050108@oracle.com> <55B77102.9050904@oracle.com> Message-ID: <5FD223E653528046A87219078E495127E94336@spvw1967.ONE-05.GRP> Thank you David you are right, I'm not using the good version of openjdk8, I was following the "openjdk8 build README" steps, but it is said to use http://hg.openjdk.java.net/jdk8/jdk8 instead of http://hg.openjdk.java.net/jdk8u/jdk8u in it. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Tuesday, 28 July, 2015 14:10 To: GAUVIN Florian; 'build-dev at openjdk.java.net' Subject: Re: Error building openjdk8 compact profiles Also see attached. David On 28/07/2015 10:06 PM, David Holmes wrote: > On 28/07/2015 9:36 PM, GAUVIN Florian wrote: >> Hi, >> I have this error building openjdk8 compact profiles : >> " >> ## Starting profiles >> gmake[2]: *** No rule to make target >> `/home/student/Documents/openjdk8/build/linux-x86_64-normal-zero-rele >> ase/images/beanless/java/util/jar/Pack200\$Packer.class', >> needed by >> `/home/student/Documents/openjdk8/build/linux-x86_64-normal-zero-release/images/libprofile_1/rt.jar'. >> Stop. >> gmake[2]: *** Waiting for unfinished jobs.... >> gmake[1]: *** [profile_1] Error 2 >> make: *** [profiles-only] Error 2 >> [student at localhost openjdk8]$ make -v GNU Make 3.82 Built for >> x86_64-redhat-linux-gnu Copyright (C) 2010 Free Software Foundation, >> Inc. >> License GPLv3+: GNU GPL version 3 or later >> >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. >> " >> >> I have read on a website that it's because of make 4.0 but it's not >> the one that I'm using. I'm using make 3.82 and I work on centos 7. >> Do you have an idea why? > > As I recall it is an issue with make and the shell. But I also thought > that Erik had since fixed this issue. What actual version of the > sources are you building? > > David > >> >> >> --------------------------------------------------------------------- >> --------------------------------------- >> >> Disclaimer: >> >> If you are not the intended recipient of this email, please notify >> the sender and delete it. >> Any unauthorized copying, disclosure or distribution of this email or >> its >> attachment(s) is forbidden. >> Thales Nederland BV will not accept liability for any damage caused >> by this email or its attachment(s). >> Thales Nederland BV is seated in Hengelo and is registered at the >> Chamber of Commerce under number 06061578. >> --------------------------------------------------------------------- >> --------------------------------------- >> >> ------------------------------------------------------------------------------------------------------------ Disclaimer: If you are not the intended recipient of this email, please notify the sender and delete it. Any unauthorized copying, disclosure or distribution of this email or its attachment(s) is forbidden. Thales Nederland BV will not accept liability for any damage caused by this email or its attachment(s). Thales Nederland BV is seated in Hengelo and is registered at the Chamber of Commerce under number 06061578. ------------------------------------------------------------------------------------------------------------ From omajid at redhat.com Tue Jul 28 17:15:17 2015 From: omajid at redhat.com (Omair Majid) Date: Tue, 28 Jul 2015 13:15:17 -0400 Subject: build for four target In-Reply-To: <55AD3BEF.3030801@alexkasko.com> References: <1835261857.3357361.1437393619732.JavaMail.root@ausy-group.com> <55AD3BEF.3030801@alexkasko.com> Message-ID: <20150728171517.GD4064@redhat.com> Hi, * Alex Kashchenko [2015-07-20 14:21]: > On 07/20/2015 03:00 PM, Antoine NIVOL wrote: > >The last logic instrument doesn't work after a few secondes (30 or 45) of execution. > > > >the error stack is below : > >C [ntdll.dll+0x52d37] RtlFreeHeap+0xcd > >C [ntdll.dll+0x52ce8] RtlFreeHeap+0x7e > >C [kernel32.dll+0x4c484] HeapFree+0x14 > >C [msvcr100.dll+0x1016a] free+0x1c > >C [zip.dll+0x7709] Java_java_util_zip_ZipEntry_initFields+0x58de > >J java.util.zip.ZipFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry; > >V [jvm.dll+0x12453a] > >V [jvm.dll+0x1d013e] > >V [jvm.dll+0x1245bd] > >V [jvm.dll+0xd89b4] > >C [java.dll+0x1061] Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedExceptionAction_2Ljava_security_AccessControlContext_2+0x17 > >J java.net.URLClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class; > > > > > >The error occur at several zone on my software but the top six lines are always similar. Are you overwriting a zip file that's open for reading by any chance? Have you tried setting the system property 'sun.zip.disableMemoryMapping'? Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From florian.gauvin at nl.thalesgroup.com Thu Jul 30 12:36:33 2015 From: florian.gauvin at nl.thalesgroup.com (GAUVIN Florian) Date: Thu, 30 Jul 2015 12:36:33 +0000 Subject: error building openjdk 8 In-Reply-To: <5FD223E653528046A87219078E495127E943A0@spvw1967.ONE-05.GRP> References: <5FD223E653528046A87219078E495127E943A0@spvw1967.ONE-05.GRP> Message-ID: <5FD223E653528046A87219078E495127E943BC@spvw1967.ONE-05.GRP> Hi, I'm having this error when I try to build openjdk 8 : " /root/openjdk8/hotspot/src/cpu/zero/vm/frame_zero.cpp: In member function 'void frame::zero_print_on_error(int, outputStream*, char*, int) const': Generating precompiled header precompiled.hpp.gch /root/openjdk8/hotspot/src/share/vm/precompiled/precompiled.hpp:29:30: fatal error: asm/assembler.hpp: No such file or directory # include "asm/assembler.hpp" ^ compilation terminated. make[6]: *** [precompiled.hpp.gch] Error 1 make[5]: *** [the_vm] Error 2 make[4]: *** [productzero] Error 2 make[3]: *** [generic_buildzero] Error 2 make[2]: *** [productzero] Error 2 make[1]: *** [/root/openjdk8/build/linux-x86_64-normal-zero-release/hotspot/_hotspot.timestamp] Error 2 make: *** [hotspot-only] Error 2 " Do you know how to solve it? Regards, Florian GAUVIN ------------------------------------------------------------------------------------------------------------ Disclaimer: If you are not the intended recipient of this email, please notify the sender and delete it. Any unauthorized copying, disclosure or distribution of this email or its attachment(s) is forbidden. Thales Nederland BV will not accept liability for any damage caused by this email or its attachment(s). Thales Nederland BV is seated in Hengelo and is registered at the Chamber of Commerce under number 06061578. ------------------------------------------------------------------------------------------------------------ From volker.simonis at gmail.com Thu Jul 30 12:52:41 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 30 Jul 2015 14:52:41 +0200 Subject: error building openjdk 8 In-Reply-To: <5FD223E653528046A87219078E495127E943BC@spvw1967.ONE-05.GRP> References: <5FD223E653528046A87219078E495127E943A0@spvw1967.ONE-05.GRP> <5FD223E653528046A87219078E495127E943BC@spvw1967.ONE-05.GRP> Message-ID: Hi Florian, if you are intentionally building the Zero-port on linux/x86_64 you'd better ask on the zero-dev list (cc'ed). Otherwise there must be an error in your configure line (could you post it) because by default the files from hotspot/src/cpu/zero won't be included in a normal build. Regards, Volker On Thu, Jul 30, 2015 at 2:36 PM, GAUVIN Florian wrote: > Hi, > I'm having this error when I try to build openjdk 8 : > " > /root/openjdk8/hotspot/src/cpu/zero/vm/frame_zero.cpp: In member function 'void frame::zero_print_on_error(int, outputStream*, char*, int) const': > Generating precompiled header precompiled.hpp.gch > /root/openjdk8/hotspot/src/share/vm/precompiled/precompiled.hpp:29:30: fatal error: asm/assembler.hpp: No such file or directory > # include "asm/assembler.hpp" > ^ > compilation terminated. > make[6]: *** [precompiled.hpp.gch] Error 1 > make[5]: *** [the_vm] Error 2 > make[4]: *** [productzero] Error 2 > make[3]: *** [generic_buildzero] Error 2 > make[2]: *** [productzero] Error 2 > make[1]: *** [/root/openjdk8/build/linux-x86_64-normal-zero-release/hotspot/_hotspot.timestamp] Error 2 > make: *** [hotspot-only] Error 2 > " > Do you know how to solve it? > > Regards, > Florian GAUVIN > > > ------------------------------------------------------------------------------------------------------------ > Disclaimer: > > If you are not the intended recipient of this email, please notify the sender and > delete it. > Any unauthorized copying, disclosure or distribution of this email or its > attachment(s) is forbidden. > Thales Nederland BV will not accept liability for any damage caused by this email or > its attachment(s). > Thales Nederland BV is seated in Hengelo and is registered at the Chamber of > Commerce under number 06061578. > ------------------------------------------------------------------------------------------------------------ > From florian.gauvin at nl.thalesgroup.com Thu Jul 30 14:21:55 2015 From: florian.gauvin at nl.thalesgroup.com (GAUVIN Florian) Date: Thu, 30 Jul 2015 14:21:55 +0000 Subject: error building openjdk 8 In-Reply-To: References: <5FD223E653528046A87219078E495127E943A0@spvw1967.ONE-05.GRP> <5FD223E653528046A87219078E495127E943BC@spvw1967.ONE-05.GRP> Message-ID: <5FD223E653528046A87219078E495127E943E8@spvw1967.ONE-05.GRP> Hi Volker, It was an error in the make line. Thank you for your answer. Regards, Florian GAUVIN -----Original Message----- From: Volker Simonis [mailto:volker.simonis at gmail.com] Sent: Thursday, 30 July, 2015 14:53 To: GAUVIN Florian Cc: build-dev at openjdk.java.net; zero-dev at openjdk.java.net Subject: Re: error building openjdk 8 Hi Florian, if you are intentionally building the Zero-port on linux/x86_64 you'd better ask on the zero-dev list (cc'ed). Otherwise there must be an error in your configure line (could you post it) because by default the files from hotspot/src/cpu/zero won't be included in a normal build. Regards, Volker On Thu, Jul 30, 2015 at 2:36 PM, GAUVIN Florian wrote: > Hi, > I'm having this error when I try to build openjdk 8 : > " > /root/openjdk8/hotspot/src/cpu/zero/vm/frame_zero.cpp: In member function 'void frame::zero_print_on_error(int, outputStream*, char*, int) const': > Generating precompiled header precompiled.hpp.gch > /root/openjdk8/hotspot/src/share/vm/precompiled/precompiled.hpp:29:30: > fatal error: asm/assembler.hpp: No such file or directory # include "asm/assembler.hpp" > ^ > compilation terminated. > make[6]: *** [precompiled.hpp.gch] Error 1 > make[5]: *** [the_vm] Error 2 > make[4]: *** [productzero] Error 2 > make[3]: *** [generic_buildzero] Error 2 > make[2]: *** [productzero] Error 2 > make[1]: *** > [/root/openjdk8/build/linux-x86_64-normal-zero-release/hotspot/_hotspo > t.timestamp] Error 2 > make: *** [hotspot-only] Error 2 > " > Do you know how to solve it? > > Regards, > Florian GAUVIN > > > ---------------------------------------------------------------------- > -------------------------------------- > Disclaimer: > > If you are not the intended recipient of this email, please notify the > sender and delete it. > Any unauthorized copying, disclosure or distribution of this email or > its > attachment(s) is forbidden. > Thales Nederland BV will not accept liability for any damage caused by > this email or its attachment(s). > Thales Nederland BV is seated in Hengelo and is registered at the > Chamber of Commerce under number 06061578. > ---------------------------------------------------------------------- > -------------------------------------- > ------------------------------------------------------------------------------------------------------------ Disclaimer: If you are not the intended recipient of this email, please notify the sender and delete it. Any unauthorized copying, disclosure or distribution of this email or its attachment(s) is forbidden. Thales Nederland BV will not accept liability for any damage caused by this email or its attachment(s). Thales Nederland BV is seated in Hengelo and is registered at the Chamber of Commerce under number 06061578. ------------------------------------------------------------------------------------------------------------