From jsonlee.ft at gmail.com  Fri Jan  2 09:24:25 2015
From: jsonlee.ft at gmail.com (lee json)
Date: Fri, 2 Jan 2015 17:24:25 +0800
Subject: Building open jdk 8 from source fails
Message-ID: <CAG6=6-TO7FU4diVNjT5CUUvMZEbMbfhNQx1wdAwpRL-WS5sA7w@mail.gmail.com>

I following the instruction at openjdk.java.net/projects/build-infra/guide.html

with commands `configure` and `make (all)`

`configure` goes well, but `make` or `make all` fails with error like
paste.debian.net/138889/

And there is no differences with JAVA_HOME set or unset.

How to fix this problem?

Environment: debian 8.0, hg 3.1, the latest changeset is
941:1773f1fd0fac with date on Tue Mar 04 11:50:40 2014 -0800

Thanks


From volker.simonis at gmail.com  Fri Jan  2 09:34:15 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 2 Jan 2015 10:34:15 +0100
Subject: Building open jdk 8 from source fails
In-Reply-To: <CAG6=6-TO7FU4diVNjT5CUUvMZEbMbfhNQx1wdAwpRL-WS5sA7w@mail.gmail.com>
References: <CAG6=6-TO7FU4diVNjT5CUUvMZEbMbfhNQx1wdAwpRL-WS5sA7w@mail.gmail.com>
Message-ID: <CA+3eh11xjb2wR0sOYuUhXxM9NrfsXyfZQ6DhX=Whd1CYh8ucqg@mail.gmail.com>

What boot-jdk did you use?
- You could try with a different one.

What is the exact configure command line?

Which repository did you build from?
- The latest jdk8 development code line is at:
http://hg.openjdk.java.net/jdk8u/jdk8u-dev/


On Fri, Jan 2, 2015 at 10:24 AM, lee json <jsonlee.ft at gmail.com> wrote:
> I following the instruction at openjdk.java.net/projects/build-infra/guide.html
>
> with commands `configure` and `make (all)`
>
> `configure` goes well, but `make` or `make all` fails with error like
> paste.debian.net/138889/
>
> And there is no differences with JAVA_HOME set or unset.
>
> How to fix this problem?
>
> Environment: debian 8.0, hg 3.1, the latest changeset is
> 941:1773f1fd0fac with date on Tue Mar 04 11:50:40 2014 -0800
>
> Thanks


From sbaiduzh at redhat.com  Sat Jan  3 19:45:55 2015
From: sbaiduzh at redhat.com (Stanislav Baiduzhyi)
Date: Sat, 03 Jan 2015 20:45:55 +0100
Subject: Building open jdk 8 from source fails
In-Reply-To: <CAG6=6-TO7FU4diVNjT5CUUvMZEbMbfhNQx1wdAwpRL-WS5sA7w@mail.gmail.com>
References: <CAG6=6-TO7FU4diVNjT5CUUvMZEbMbfhNQx1wdAwpRL-WS5sA7w@mail.gmail.com>
Message-ID: <26817504.PlOLrt4lC8@thinkpad.hell>

On Friday 02 January 2015 17:24:25 lee json wrote:
> I following the instruction at
> openjdk.java.net/projects/build-infra/guide.html
> 
> with commands `configure` and `make (all)`
> 
> `configure` goes well, but `make` or `make all` fails with error like
> paste.debian.net/138889/
> 
> And there is no differences with JAVA_HOME set or unset.
> 
> How to fix this problem?
> 
> Environment: debian 8.0, hg 3.1, the latest changeset is
> 941:1773f1fd0fac with date on Tue Mar 04 11:50:40 2014 -0800

Looks like it does not like diamond operators. Are you sure you're using jdk 7 
to build openjdk 8?

-- 
Regards,
    Stas



From peina2015 at 163.com  Mon Jan  5 07:57:26 2015
From: peina2015 at 163.com (Na Pei)
Date: Mon, 5 Jan 2015 07:57:26 +0000 (UTC)
Subject: Building openjdk 8 on Mac OS X
References: <322D21DC-A8EC-4054-9B29-5EB6B8DB8754@gmail.com>
	<78ABBB16-75D7-4F95-9364-0996FAAA7E22@oracle.com>
	<A8ECBB8A-556D-4E4C-A677-31E2415B4216@gmail.com>
Message-ID: <loom.20150105T084754-902@post.gmane.org>

You need to patch /hotspot/make/bsd/makefiles/saproc.make to make it use
10.8sdk instead of system library in Yosemite.

 - SALIBS = -g -framework Foundation
-F/System/Library/Frameworks/JavaVM.framework/Frameworks 
-framework JavaNativeFoundation -framework Security -framework CoreFoundation

 + SALIBS = -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform
/Developer/SDKs/MacOSX10.8.sdk
-g -framework Foundation
-F/System/Library/Frameworks/JavaVM.framework/Frameworks -framework
JavaNativeFoundation -framework Security -framework CoreFoundation



Manas Thakur <manasthakur17 at ...> writes:







From hadilashkari at gmail.com  Mon Jan  5 14:55:37 2015
From: hadilashkari at gmail.com (Hadi)
Date: Mon, 5 Jan 2015 14:55:37 +0000 (UTC)
Subject: Problem building JDK 8
References: <5493EB1D.2010405@gmail.com>
	<CA+kOe08ZQF2n-Vw7oe_TwiAaDNU87gBdbeoUAsk3rNDog78oBQ@mail.gmail.com>
Message-ID: <loom.20150105T153311-634@post.gmane.org>

Martin Buchholz <martinrb at ...> writes:

> 
> Others don't seem to have this problem - you can try looking at
> config.log and elsewhere trying to figure out what went wrong.
> 
> On Fri, Dec 19, 2014 at 1:08 AM, C?dric Champeau
> <cedric.champeau at ...> wrote:
> > Hi everyone,
> >
> > Some of you may know that we try to test Groovy builds against the latest
> > versions of the JDK. For that, we have setup a CI build of OpenJDK 7, 8 and
> > 9. However, the JDK 8 builds have been failing for several months now (sorry
> > I didn't have much time to investigate this specific subject, so I rely on
> > EA builds instead, which gives us late but valuable feedback).
> >
> > Basically, in the JDK 8 build log (JDK 9 doesn't have the issue), I can read
> > this in the logs:
> >
> > [02:00:17]:     [Step 1/2] configure: error: Could not find freetype! You
> > might be able to fix this by running 'sudo apt-get install
> > libfreetype6-dev'.
> >
> > However if I try to do so, I see that freetype *is* installed:
> >
> > # apt-get install libfreetype6-dev
> > Reading package lists... Done
> > Building dependency tree
> > Reading state information... Done
> > libfreetype6-dev is already the newest version.
> >
> > The server is running Ubuntu 14.04.1 LTS, which gcc 4.8.2, which is supposed
> > to "work flawlessly" from what I read here:
> > https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms
> >
> > We build from http://hg.openjdk.java.net/jdk8u/jdk8u
> >
> > Thanks for your help!
> >
> > --
> > C?dric Champeau
> > SpringSource - Pivotal
> > http://twitter.com/CedricChampeau
> > http://melix.github.io/blog
> > http://spring.io/ http://www.gopivotal.com/
> >
> 
> 


Hey,

I have the same issue!! I recently upgraded from UBUNTU 12.04 to UBUNTU
14.04. Then I cloned jdk8u tree and installed these packages:
build-essential zip unzip openjdk-7-jdk libX11-dev libxext-dev
libxrender-dev libxtst-dev libxt-dev libcups2-dev libfreetype6-dev
libcups2-dev libasound2-dev ccache g++-4.7-multilib libffi-dev

But after running `bash configure` I get the same error:
configure: error: Could not find freetype! You might be able to fix this by
running 'sudo apt-get install libfreetype6-dev'. 
configure exiting with result code 1
 
You see that I installed libfreetype6-dev. This is a part of config.log as
you requested:

## --------- ##
## Platform. ##
## --------- ##

hostname = srv25887.screweb.com
uname -m = x86_64
uname -r = 3.13.0-43-generic
uname -s = Linux
uname -v = #72-Ubuntu SMP Mon Dec 8 19:35:06 UTC 2014

/usr/bin/uname -p = unknown
/bin/uname -X     = unknown

/bin/arch              = unknown
/usr/bin/arch -k       = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo      = unknown
/bin/machine           = unknown
/usr/bin/oslevel       = unknown
/bin/universe          = unknown

PATH: /usr/local/sbin
PATH: /usr/local/bin
PATH: /usr/sbin
PATH: /usr/bin
PATH: /sbin
PATH: /bin
PATH: /usr/games
PATH: /usr/local/games


## ----------- ##
## Core tests. ##
## ----------- ##

.
.
.
configure:29378: result: no
configure:30037: checking if compiler supports "-m64"
configure:30053: /usr/bin/gcc-4.8 -c  -m64  conftest.c >&5
configure:30053: $? = 0
configure:30079: /usr/bin/g++-4.8 -c  -m64  conftest.cpp >&5
configure:30079: $? = 0
configure:30093: result: yes
configure:30106: checking if compiler supports "-m64"
configure:30122: /usr/bin/gcc-4.8 -c  -m64  conftest.c >&5
configure:30122: $? = 0
configure:30148: /usr/bin/g++-4.8 -c  -m64  conftest.cpp >&5
configure:30148: $? = 0
configure:30162: result: yes
configure:30176: checking for broken SuSE 'ld' which only understands
anonymous version tags in executables
configure:30181: result: no
configure:30206: checking if we should generate debug symbols
configure:30231: result: true
configure:30237: checking if we should zip debug-info files
configure:30246: result: yes
configure:30334: checking what is not needed on Linux?
configure:30337: result: pulse
configure:30416: checking for Mac OS X Java Framework
configure:30422: result: no
configure:30456: checking for X
configure:30564: /usr/bin/g++-4.8 -E  conftest.cpp
configure:30564: $? = 0
configure:30595: /usr/bin/g++-4.8 -o conftest    conftest.cpp -lX11  >&5
configure:30595: $? = 0
configure:30645: result: libraries , headers 
configure:30744: /usr/bin/g++-4.8 -o conftest    conftest.cpp   -lX11 >&5
configure:30744: $? = 0
configure:30842: checking for gethostbyname
configure:30842: /usr/bin/g++-4.8 -o conftest    conftest.cpp  >&5
configure:30842: $? = 0
configure:30842: result: yes
configure:30939: checking for connect
configure:30939: /usr/bin/g++-4.8 -o conftest    conftest.cpp  >&5
configure:30939: $? = 0
configure:30939: result: yes
configure:30988: checking for remove
configure:30988: /usr/bin/g++-4.8 -o conftest    conftest.cpp  >&5
configure:30988: $? = 0
configure:30988: result: yes
configure:31037: checking for shmat
configure:31037: /usr/bin/g++-4.8 -o conftest    conftest.cpp  >&5
configure:31037: $? = 0
configure:31037: result: yes
configure:31095: checking for IceConnectionNumber in -lICE
configure:31120: /usr/bin/g++-4.8 -o conftest    conftest.cpp -lICE   >&5
configure:31120: $? = 0
configure:31129: result: yes
configure:31210: checking for X11/extensions/shape.h
configure:31210: /usr/bin/gcc-4.8 -c    conftest.c >&5
configure:31210: $? = 0
configure:31210: result: yes
configure:31210: checking for X11/extensions/Xrender.h
configure:31210: /usr/bin/gcc-4.8 -c    conftest.c >&5
configure:31210: $? = 0
configure:31210: result: yes
configure:31210: checking for X11/extensions/XTest.h
configure:31210: /usr/bin/gcc-4.8 -c    conftest.c >&5
configure:31210: $? = 0
configure:31210: result: yes
configure:31210: checking for X11/Intrinsic.h
configure:31210: /usr/bin/gcc-4.8 -c    conftest.c >&5
configure:31210: $? = 0
configure:31210: result: yes
configure:31463: checking cups/cups.h usability
configure:31463: /usr/bin/g++-4.8 -c   conftest.cpp >&5
configure:31463: $? = 0
configure:31463: result: yes
configure:31463: checking cups/cups.h presence
configure:31463: /usr/bin/g++-4.8 -E  conftest.cpp
configure:31463: $? = 0
configure:31463: result: yes
configure:31463: checking for cups/cups.h
configure:31463: result: yes
configure:31463: checking cups/ppd.h usability
configure:31463: /usr/bin/g++-4.8 -c   conftest.cpp >&5
configure:31463: $? = 0
configure:31463: result: yes
configure:31463: checking cups/ppd.h presence
configure:31463: /usr/bin/g++-4.8 -E  conftest.cpp
configure:31463: $? = 0
configure:31463: result: yes
configure:31463: checking for cups/ppd.h
configure:31463: result: yes
configure:34287: error: Could not find freetype! You might be able to fix
this by running 'sudo apt-get install libfreetype6-dev'. 

## ---------------- ##
## Cache variables. ##
## ---------------- ##

ac_cv_build=x86_64-unknown-linux-gnu
ac_cv_c_bigendian=no
ac_cv_c_compiler_gnu=yes
ac_cv_cxx_compiler_gnu=yes
ac_cv_env_ALSA_CFLAGS_set=
ac_cv_env_ALSA_CFLAGS_value=
ac_cv_env_ALSA_LIBS_set=
ac_cv_env_ALSA_LIBS_value=
ac_cv_env_CCC_set=
ac_cv_env_CCC_value=
ac_cv_env_CC_set=
ac_cv_env_CC_value=
ac_cv_env_CFLAGS_set=
ac_cv_env_CFLAGS_value=
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CPP_set=
ac_cv_env_CPP_value=
ac_cv_env_CXXCPP_set=
ac_cv_env_CXXCPP_value=
ac_cv_env_CXXFLAGS_set=
ac_cv_env_CXXFLAGS_value=
ac_cv_env_CXX_set=
ac_cv_env_CXX_value=
ac_cv_env_FREETYPE_CFLAGS_set=
ac_cv_env_FREETYPE_CFLAGS_value=
ac_cv_env_FREETYPE_LIBS_set=
ac_cv_env_FREETYPE_LIBS_value=
ac_cv_env_LDFLAGS_set=
ac_cv_env_LDFLAGS_value=
ac_cv_env_LIBFFI_CFLAGS_set=
ac_cv_env_LIBFFI_CFLAGS_value=
ac_cv_env_LIBFFI_LIBS_set=
ac_cv_env_LIBFFI_LIBS_value=
ac_cv_env_LIBS_set=
ac_cv_env_LIBS_value=
ac_cv_env_OBJCFLAGS_set=
ac_cv_env_OBJCFLAGS_value=
ac_cv_env_OBJC_set=
ac_cv_env_OBJC_value=
ac_cv_env_PKG_CONFIG_set=
ac_cv_env_PKG_CONFIG_value=
ac_cv_env_XMKMF_set=
ac_cv_env_XMKMF_value=
ac_cv_env_build_alias_set=
ac_cv_env_build_alias_value=
ac_cv_env_host_alias_set=
ac_cv_env_host_alias_value=
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_func_connect=yes
ac_cv_func_gethostbyname=yes
ac_cv_func_remove=yes
ac_cv_func_shmat=yes
ac_cv_have_x='have_x=yes	ac_x_includes='\'''\''	ac_x_libraries='\'''\'''
ac_cv_header_X11_Intrinsic_h=yes
ac_cv_header_X11_extensions_XTest_h=yes
ac_cv_header_X11_extensions_Xrender_h=yes
ac_cv_header_X11_extensions_shape_h=yes
ac_cv_header_cups_cups_h=yes
ac_cv_header_cups_ppd_h=yes
ac_cv_header_inttypes_h=yes
ac_cv_header_memory_h=yes
ac_cv_header_stdc=yes
ac_cv_header_stdint_h=yes
ac_cv_header_stdio_h=yes
ac_cv_header_stdlib_h=yes
ac_cv_header_string_h=yes
ac_cv_header_strings_h=yes
ac_cv_header_sys_stat_h=yes
ac_cv_header_sys_types_h=yes
ac_cv_header_unistd_h=yes
ac_cv_host=x86_64-unknown-linux-gnu
ac_cv_lib_ICE_IceConnectionNumber=yes
ac_cv_objext=o
ac_cv_path_BASENAME=/usr/bin/basename
ac_cv_path_BASH=/bin/bash
ac_cv_path_CAT=/bin/cat
ac_cv_path_CHECK_MAKE=/usr/bin/make
ac_cv_path_CHMOD=/bin/chmod
ac_cv_path_CMP=/usr/bin/cmp
ac_cv_path_COMM=/usr/bin/comm
ac_cv_path_CP=/bin/cp
ac_cv_path_CPIO=/bin/cpio
ac_cv_path_CUT=/usr/bin/cut
ac_cv_path_DATE=/bin/date
ac_cv_path_DF=/bin/df
ac_cv_path_DIFF=/usr/bin/diff
ac_cv_path_DIRNAME=/usr/bin/dirname
ac_cv_path_ECHO=/bin/echo
ac_cv_path_EGREP='/bin/grep -E'
ac_cv_path_EXPR=/usr/bin/expr
ac_cv_path_FGREP='/bin/grep -F'
ac_cv_path_FILE=/usr/bin/file
ac_cv_path_FIND=/usr/bin/find
ac_cv_path_GREP=/bin/grep
ac_cv_path_HEAD=/usr/bin/head
ac_cv_path_HG=/usr/bin/hg
ac_cv_path_JAVAC_CHECK=/usr/bin/javac
ac_cv_path_JAVA_CHECK=/usr/bin/java
ac_cv_path_LDD=/usr/bin/ldd
ac_cv_path_LN=/bin/ln
ac_cv_path_LS=/bin/ls
ac_cv_path_MKDIR=/bin/mkdir
ac_cv_path_MKTEMP=/bin/mktemp
ac_cv_path_MV=/bin/mv
ac_cv_path_NAWK=/usr/bin/nawk
ac_cv_path_POTENTIAL_CC=/usr/bin/gcc
ac_cv_path_POTENTIAL_CXX=/usr/bin/g++
ac_cv_path_PRINTF=/usr/bin/printf
ac_cv_path_READELF=/usr/bin/readelf
ac_cv_path_READLINK=/bin/readlink
ac_cv_path_RM=/bin/rm
ac_cv_path_SED=/bin/sed
ac_cv_path_SH=/bin/sh
ac_cv_path_SORT=/usr/bin/sort
ac_cv_path_STAT=/usr/bin/stat
ac_cv_path_TAIL=/usr/bin/tail
ac_cv_path_TAR=/bin/tar
ac_cv_path_TEE=/usr/bin/tee
ac_cv_path_TIME=/usr/bin/time
ac_cv_path_TOUCH=/usr/bin/touch
ac_cv_path_TR=/usr/bin/tr
ac_cv_path_UNAME=/bin/uname
ac_cv_path_UNIQ=/usr/bin/uniq
ac_cv_path_UNZIP=/usr/bin/unzip
ac_cv_path_WC=/usr/bin/wc
ac_cv_path_WHICH=/usr/bin/which
ac_cv_path_XARGS=/usr/bin/xargs
ac_cv_path_ZIP=/usr/bin/zip
ac_cv_prog_AWK=gawk
ac_cv_prog_BDEPS_FTP=wget
ac_cv_prog_BDEPS_UNZIP=unzip
ac_cv_prog_CPP='/usr/bin/gcc-4.8 -E'
ac_cv_prog_CXXCPP='/usr/bin/g++-4.8 -E'
ac_cv_prog_PKGHANDLER=apt-get
ac_cv_prog_ac_ct_AR=ar
ac_cv_prog_ac_ct_NM=nm
ac_cv_prog_ac_ct_OBJCOPY=objcopy
ac_cv_prog_ac_ct_OBJDUMP=objdump
ac_cv_prog_ac_ct_STRIP=strip
ac_cv_prog_cc_c89=
ac_cv_prog_cc_g=yes
ac_cv_prog_cxx_g=yes
ac_cv_sizeof_int_p=8
ac_cv_target=x86_64-unknown-linux-gnu





From volker.simonis at gmail.com  Mon Jan  5 16:22:42 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 5 Jan 2015 17:22:42 +0100
Subject: Problem building JDK 8
In-Reply-To: <5493EB1D.2010405@gmail.com>
References: <5493EB1D.2010405@gmail.com>
Message-ID: <CA+3eh12P8mXGK__wpTkWVJiSYcDQmW+d8MKm5eoiVh7wceosXQ@mail.gmail.com>

Maybe this is a 32/64 bit mismatch - i.e. you are on a 64-bit machine
with 64-bit libfreetype but configuring for 32-bit ?



On Fri, Dec 19, 2014 at 10:08 AM, C?dric Champeau
<cedric.champeau at gmail.com> wrote:
> Hi everyone,
>
> Some of you may know that we try to test Groovy builds against the latest
> versions of the JDK. For that, we have setup a CI build of OpenJDK 7, 8 and
> 9. However, the JDK 8 builds have been failing for several months now (sorry
> I didn't have much time to investigate this specific subject, so I rely on
> EA builds instead, which gives us late but valuable feedback).
>
> Basically, in the JDK 8 build log (JDK 9 doesn't have the issue), I can read
> this in the logs:
>
> [02:00:17]:     [Step 1/2] configure: error: Could not find freetype! You
> might be able to fix this by running 'sudo apt-get install
> libfreetype6-dev'.
>
> However if I try to do so, I see that freetype *is* installed:
>
> # apt-get install libfreetype6-dev
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> libfreetype6-dev is already the newest version.
>
> The server is running Ubuntu 14.04.1 LTS, which gcc 4.8.2, which is supposed
> to "work flawlessly" from what I read here:
> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms
>
> We build from http://hg.openjdk.java.net/jdk8u/jdk8u
>
> Thanks for your help!
>
> --
> C?dric Champeau
> SpringSource - Pivotal
> http://twitter.com/CedricChampeau
> http://melix.github.io/blog
> http://spring.io/ http://www.gopivotal.com/
>


From toby at telegraphics.com.au  Mon Jan  5 16:39:21 2015
From: toby at telegraphics.com.au (Toby Thain)
Date: Mon, 05 Jan 2015 11:39:21 -0500
Subject: Building openjdk 8 on Mac OS X
In-Reply-To: <loom.20150105T084754-902@post.gmane.org>
References: <322D21DC-A8EC-4054-9B29-5EB6B8DB8754@gmail.com>	<78ABBB16-75D7-4F95-9364-0996FAAA7E22@oracle.com>	<A8ECBB8A-556D-4E4C-A677-31E2415B4216@gmail.com>
	<loom.20150105T084754-902@post.gmane.org>
Message-ID: <54AABE39.4000909@telegraphics.com.au>

On 05/01/15 2:57 AM, Na Pei wrote:
> You need to patch /hotspot/make/bsd/makefiles/saproc.make to make it use
> 10.8sdk instead of system library in Yosemite.
>
>   - SALIBS = -g -framework Foundation
> -F/System/Library/Frameworks/JavaVM.framework/Frameworks
> -framework JavaNativeFoundation -framework Security -framework CoreFoundation
>
>   + SALIBS = -isysroot
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform
> /Developer/SDKs/MacOSX10.8.sdk
> -g -framework Foundation
> -F/System/Library/Frameworks/JavaVM.framework/Frameworks -framework
> JavaNativeFoundation -framework Security -framework CoreFoundation
>
>
>
> Manas Thakur <manasthakur17 at ...> writes:
>
>
>
>
>
>

Yes, I just found this out the hard way yesterday (and many other 
patches are required too).

Is there any chance OS X fixes can make it upstream?

--Toby



From martinrb at google.com  Mon Jan  5 20:51:59 2015
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 5 Jan 2015 12:51:59 -0800
Subject: Problem building JDK 8
In-Reply-To: <loom.20150105T153311-634@post.gmane.org>
References: <5493EB1D.2010405@gmail.com>
	<CA+kOe08ZQF2n-Vw7oe_TwiAaDNU87gBdbeoUAsk3rNDog78oBQ@mail.gmail.com>
	<loom.20150105T153311-634@post.gmane.org>
Message-ID: <CA+kOe0_6fDS8eWCOZdh5V17Y5r3Ox_ShSixCUifXVbjbed7C-g@mail.gmail.com>

It's a mystery.  My own successful config.log snippet with latest jdk8u is
below.  Why didn't your config.log contain "checking for FREETYPE"?  Maybe
a pkg-config problem? Are you doing something crazy like defining
LD_LIBRARY_PATH? Someone will need to debug configure, perhaps using bash
-x configure...

configure:31477: checking for cups/ppd.h
configure:31477: result: yes
configure:32103: checking for FREETYPE
configure:32110: $PKG_CONFIG --exists --print-errors "freetype2"
configure:32113: $? = 0
configure:32126: $PKG_CONFIG --exists --print-errors "freetype2"
configure:32129: $? = 0
configure:32164: result: yes
configure:32181: checking for freetype
configure:32183: result: yes (using pkg-config)
configure:34567: checking if we can compile and link with freetype
configure:34592:  /usr/bin/g++-4.8 -o conftest  -I/usr/include/freetype2
  conftest.cpp  -lfreetype >&5
configure:34592: $? = 0
configure:34594: result: yes
configure:34653: checking if we should bundle freetype
configure:34658: result: no


From david.dehaven at oracle.com  Tue Jan  6 22:01:40 2015
From: david.dehaven at oracle.com (David DeHaven)
Date: Tue, 6 Jan 2015 14:01:40 -0800
Subject: Building openjdk 8 on Mac OS X
In-Reply-To: <54AABE39.4000909@telegraphics.com.au>
References: <322D21DC-A8EC-4054-9B29-5EB6B8DB8754@gmail.com>	<78ABBB16-75D7-4F95-9364-0996FAAA7E22@oracle.com>	<A8ECBB8A-556D-4E4C-A677-31E2415B4216@gmail.com>
	<loom.20150105T084754-902@post.gmane.org>
	<54AABE39.4000909@telegraphics.com.au>
Message-ID: <CC591DCC-287A-4481-9672-E1B7CBADFEAF@oracle.com>


>> You need to patch /hotspot/make/bsd/makefiles/saproc.make to make it use
>> 10.8sdk instead of system library in Yosemite.
>> 
>>  - SALIBS = -g -framework Foundation
>> -F/System/Library/Frameworks/JavaVM.framework/Frameworks
>> -framework JavaNativeFoundation -framework Security -framework CoreFoundation
>> 
>>  + SALIBS = -isysroot
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform
>> /Developer/SDKs/MacOSX10.8.sdk
>> -g -framework Foundation
>> -F/System/Library/Frameworks/JavaVM.framework/Frameworks -framework
>> JavaNativeFoundation -framework Security -framework CoreFoundation
>> 
>> 
>> 
>> Manas Thakur <manasthakur17 at ...> writes:
>> 
>> 
>> 
>> 
>> 
>> 
> 
> Yes, I just found this out the hard way yesterday (and many other patches are required too).
> 
> Is there any chance OS X fixes can make it upstream?

This basically requires backporting JDK-8043340 to jdk8u, which I've been poking at here and there but have not had the time to really tackle it.

-DrD-



From robinndi at aol.com  Wed Jan  7 01:24:52 2015
From: robinndi at aol.com (Robin & Di Hayman)
Date: Tue, 06 Jan 2015 20:24:52 -0500
Subject: Problems building JFX media -help
Message-ID: <54AC8AE4.7000001@aol.com>

I am trying to build JavaFX with native media enabled.  For background, 
read *The initial problem* below.

So I am stuck in build.gradle ( line 2392 for me)  in def buildGlib{ 
.... I have progressed somewhat since the initial problem.  To me it now 
seems that Gradle or Cywin or Make is messing up my Path so that the 
makefile is not able to execute lines like:
/MANIFEST   = $(shell cygpath -ma "$(BUILD_DIR)/$(BASE_NAME).manifest"/)
as it can't find cygpath.

I haven't fixed this yet, but I have some clues.
Firstly, I have added a line to the makefile (in 
E:\...\JavaFX\modules\media\src\main\native\gstreamer\projects\win\glib-lite/)  
a /lin/e SHELL=C:/cygwin/bin/sh.exe/to be sure I have a shell./
/Then I added a line to print the value of /PATH /in the makefile.
My DOS path (DOS SET PATH) has 26 items including C:\cygwin\bin; which 
is where cygpath.exe is held.
By the time /PATH /gets to the makefile it has 47 items and the item 
C:\cygwin\binhas been /replaced /by C:/cygwin64/bin;
As a result (I think) /$(shell cygpath/doesn't find cygpath and that 
breaks the build.

I have grepped for /cygwin64 /in the JFX tree but there are no hits.
So either Cygwin or Gradle or Cygwin-make is taking what may be a 
correct DOS path and making it into an incorrect path by the time it 
gets to /make/. /cygwin.bat/ does not do it. /mingw make 3.8/ has the 
same problem so perhaps it is in /Cygwin /or Gradle.

It seems /make /has a variable called PATH which is /derived /from DOS 
Path but is messed up.  DOS path itself is not changed.  I don't really 
understand who makes the make PATH or how /make /might use it in finding 
cygpath.exe.

But these are just clues.

Any ideas on where to look /what to do next?

Thanks

robinH

P.S.
It would be helpful if the page Building OpenJFX 
<https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX> was 
more specific about the versions of /Cygwin /& /make /which should be 
used as it is quite specific for most of the other tools. /Cygwin/make/ 
has been making changes in how they deal with DOS paths so perhaps they 
broke something.

------------------------------------------------- The initial probem 
-------------------------------------------------------------------------

I find JFX media HLS is not working well for me. It dies after about 30s 
whereas VLC can pick up the 'dead' m3u8 and continue playing fine, so I 
decided to build from source to try to see what is going on.  I have 
followed Michael Berry's efforts extending media codecs too. Also,  I 
found this 
<https://coaxion.net/blog/2014/05/http-adaptive-streaming-with-gstreamer/>(November 
26, 2014 at 15:04 
<https://coaxion.net/blog/2014/05/http-adaptive-streaming-with-gstreamer/comment-page-1/#comment-28467>) 
comment interesting in response to the question "Is there any support on 
gstreamer 0.10 for Adaptive Streaming ? Smooth Streaming, Dash etc. ?" . 
'Slomo' replied /"There is some initial support for HLS but don?t use 
0.10 for anything really. It?s no longer maintained since more than 2 
years and a lot has happened since then"/. The rest of his blog ('*HTTP 
Adaptive Streaming with GStreamer*') seemed to indicate he had some 
knowledge in this area.  So I decided to build from source to see more 
of what is going on.

I chose to build 8u-dev/rt from Hg, although that may not have been the 
best choice.
The initial build went fine (without native).  It was */easy/*. 
Congratulations!

Then I made a gradle.properties and set COMPILE_MEDIA = true and got 
errors.  These are in of build.gradle ( line 2392 for me)  in def 
buildGlib{ ....
This exec's the makefile in 
E:\robins_root\software\JavaFX\modules\media\src\main\native\gstreamer\projects\win\glib-lite.
The errors look like:
/bin/sh: cygpath: command not found
/    Makefile:71: recipe for target '/libglib-2.28.8.lib' failed/ /( I 
have messed up the line numbers ignore 71)/
And make returns 2 and error 127.  Now from the cywin window, I can do

/Robin at MY-PC /cygdrive/e/robins_root/software/JavaFX//
//$ cygpath --help//
//cygpath --help//
//Usage: cygpath (-d|-m|-u|-w|-t TYPE) [-f FILE] [OPTION]... NAME.../
etc
and also
/$ echo $SHELL//
//echo $SHELL//
//C:\cygwin\bin\bash.exe/
and echo path starts off
/usr/local/bin:
/usr/bin:
/cygdrive/c/ProgramData/Oracle/Java/javapath:
/cygdrive/c/Tcl/bin:
/cygdrive/c/Windows/system32:
/cygdrive/c/Windows:
...
If I manually run the makefile from its folder, fixing up any needed 
variables, it seemed to run OK.  ( Although my VS2010 was initially 
damaged. I had to set up the INCLUDE environment variable since I was 
getting windows.h not found.  I think this is caused somehow by having 
VS2010, VS2011 & VS2012 originally, then removing all three and doing a 
clean install of VS2010. I googled reports of others having this problem 
of corrupted include path.)

My installation is unusual (?) in that all my JFX builder folders are on 
e: whereas Cywgin is on c:  .  I need to use both paths /cygdrive/e/ 
and  /cygdrive/c/.

The detailed build instructions are detailed about versions for most 
programs, but not for cygwin & make. I wonder which version you use in 
your builds?

Does Gradle change the SHELL variable?  Does Gradle/cygwin/make assume 
all programs are on say a C: drive?  mintty has no problem finding 
cygpath.  Is Gradle looking for cygpath on e: instead of c:?

Now I have been playing with PATH & SHELL but nothing I do seems to help.

Any suggestions?

---------------------------------------------------------------------------
I am using:
Gradle 1.8   Build time: 2013-09-24 07:32:33 UTC  Revision: 
7970ec3503b4f5767ee1c1c69f8b4186c4763e3d  Groovy:1.8.6
Ant:          Apache Ant(TM) version 1.9.2 compiled on July 8 2013
Ivy:          2.2.0
JVM:          1.8.0_05 (Oracle Corporation 25.5-b02)
OS:           Windows 8.1 6.3 x86
$uname -a   CYGWIN_NT-6.3-WOW64 ROBIN-PC 1.7.33-2(0.280/5/3) 2014-11-13 
15:45 i686 Cygwin
make -v   GNU Make 4.0  Built for i686-pc-cygwin
cygwin install, version 2.859
I used CygWin setup-x86.exe so I presume this is 32-bit Cygwin
JAVA_HOME points to (X86) jdk1.8.0.05
JRE_HOME  (X86) jre8
My machine also has 64-bit jdk1.8.0_25 & jdk1.8.0_05in Program Files


From david.dehaven at oracle.com  Wed Jan  7 03:28:10 2015
From: david.dehaven at oracle.com (David DeHaven)
Date: Tue, 6 Jan 2015 19:28:10 -0800
Subject: Problems building JFX media -help
In-Reply-To: <54AC8AE4.7000001@aol.com>
References: <54AC8AE4.7000001@aol.com>
Message-ID: <86F199F8-D2D7-4401-A62F-010F85EA0EF2@oracle.com>


You should direct FX related issues to openjfx-dev instead.

-DrD-

> I am trying to build JavaFX with native media enabled.  For background, read *The initial problem* below.
> 
> So I am stuck in build.gradle ( line 2392 for me)  in def buildGlib{ .... I have progressed somewhat since the initial problem.  To me it now seems that Gradle or Cywin or Make is messing up my Path so that the makefile is not able to execute lines like:
> /MANIFEST   = $(shell cygpath -ma "$(BUILD_DIR)/$(BASE_NAME).manifest"/)
> as it can't find cygpath.
> 
> I haven't fixed this yet, but I have some clues.
> Firstly, I have added a line to the makefile (in E:\...\JavaFX\modules\media\src\main\native\gstreamer\projects\win\glib-lite/)  a /lin/e SHELL=C:/cygwin/bin/sh.exe/to be sure I have a shell./
> /Then I added a line to print the value of /PATH /in the makefile.
> My DOS path (DOS SET PATH) has 26 items including C:\cygwin\bin; which is where cygpath.exe is held.
> By the time /PATH /gets to the makefile it has 47 items and the item C:\cygwin\binhas been /replaced /by C:/cygwin64/bin;
> As a result (I think) /$(shell cygpath/doesn't find cygpath and that breaks the build.
> 
> I have grepped for /cygwin64 /in the JFX tree but there are no hits.
> So either Cygwin or Gradle or Cygwin-make is taking what may be a correct DOS path and making it into an incorrect path by the time it gets to /make/. /cygwin.bat/ does not do it. /mingw make 3.8/ has the same problem so perhaps it is in /Cygwin /or Gradle.
> 
> It seems /make /has a variable called PATH which is /derived /from DOS Path but is messed up.  DOS path itself is not changed.  I don't really understand who makes the make PATH or how /make /might use it in finding cygpath.exe.
> 
> But these are just clues.
> 
> Any ideas on where to look /what to do next?
> 
> Thanks
> 
> robinH
> 
> P.S.
> It would be helpful if the page Building OpenJFX <https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX> was more specific about the versions of /Cygwin /& /make /which should be used as it is quite specific for most of the other tools. /Cygwin/make/ has been making changes in how they deal with DOS paths so perhaps they broke something.
> 
> ------------------------------------------------- The initial probem -------------------------------------------------------------------------
> 
> I find JFX media HLS is not working well for me. It dies after about 30s whereas VLC can pick up the 'dead' m3u8 and continue playing fine, so I decided to build from source to try to see what is going on.  I have followed Michael Berry's efforts extending media codecs too. Also,  I found this <https://coaxion.net/blog/2014/05/http-adaptive-streaming-with-gstreamer/>(November 26, 2014 at 15:04 <https://coaxion.net/blog/2014/05/http-adaptive-streaming-with-gstreamer/comment-page-1/#comment-28467>) comment interesting in response to the question "Is there any support on gstreamer 0.10 for Adaptive Streaming ? Smooth Streaming, Dash etc. ?" . 'Slomo' replied /"There is some initial support for HLS but don?t use 0.10 for anything really. It?s no longer maintained since more than 2 years and a lot has happened since then"/. The rest of his blog ('*HTTP Adaptive Streaming with GStreamer*') seemed to indicate he had some knowledge in this area.  So I decided to build from source to see more of what is going on.
> 
> I chose to build 8u-dev/rt from Hg, although that may not have been the best choice.
> The initial build went fine (without native).  It was */easy/*. Congratulations!
> 
> Then I made a gradle.properties and set COMPILE_MEDIA = true and got errors.  These are in of build.gradle ( line 2392 for me)  in def buildGlib{ ....
> This exec's the makefile in E:\robins_root\software\JavaFX\modules\media\src\main\native\gstreamer\projects\win\glib-lite.
> The errors look like:
> /bin/sh: cygpath: command not found
> /    Makefile:71: recipe for target '/libglib-2.28.8.lib' failed/ /( I have messed up the line numbers ignore 71)/
> And make returns 2 and error 127.  Now from the cywin window, I can do
> 
> /Robin at MY-PC /cygdrive/e/robins_root/software/JavaFX//
> //$ cygpath --help//
> //cygpath --help//
> //Usage: cygpath (-d|-m|-u|-w|-t TYPE) [-f FILE] [OPTION]... NAME.../
> etc
> and also
> /$ echo $SHELL//
> //echo $SHELL//
> //C:\cygwin\bin\bash.exe/
> and echo path starts off
> /usr/local/bin:
> /usr/bin:
> /cygdrive/c/ProgramData/Oracle/Java/javapath:
> /cygdrive/c/Tcl/bin:
> /cygdrive/c/Windows/system32:
> /cygdrive/c/Windows:
> ...
> If I manually run the makefile from its folder, fixing up any needed variables, it seemed to run OK.  ( Although my VS2010 was initially damaged. I had to set up the INCLUDE environment variable since I was getting windows.h not found.  I think this is caused somehow by having VS2010, VS2011 & VS2012 originally, then removing all three and doing a clean install of VS2010. I googled reports of others having this problem of corrupted include path.)
> 
> My installation is unusual (?) in that all my JFX builder folders are on e: whereas Cywgin is on c:  .  I need to use both paths /cygdrive/e/ and  /cygdrive/c/.
> 
> The detailed build instructions are detailed about versions for most programs, but not for cygwin & make. I wonder which version you use in your builds?
> 
> Does Gradle change the SHELL variable?  Does Gradle/cygwin/make assume all programs are on say a C: drive?  mintty has no problem finding cygpath.  Is Gradle looking for cygpath on e: instead of c:?
> 
> Now I have been playing with PATH & SHELL but nothing I do seems to help.
> 
> Any suggestions?
> 
> ---------------------------------------------------------------------------
> I am using:
> Gradle 1.8   Build time: 2013-09-24 07:32:33 UTC  Revision: 7970ec3503b4f5767ee1c1c69f8b4186c4763e3d  Groovy:1.8.6
> Ant:          Apache Ant(TM) version 1.9.2 compiled on July 8 2013
> Ivy:          2.2.0
> JVM:          1.8.0_05 (Oracle Corporation 25.5-b02)
> OS:           Windows 8.1 6.3 x86
> $uname -a   CYGWIN_NT-6.3-WOW64 ROBIN-PC 1.7.33-2(0.280/5/3) 2014-11-13 15:45 i686 Cygwin
> make -v   GNU Make 4.0  Built for i686-pc-cygwin
> cygwin install, version 2.859
> I used CygWin setup-x86.exe so I presume this is 32-bit Cygwin
> JAVA_HOME points to (X86) jdk1.8.0.05
> JRE_HOME  (X86) jre8
> My machine also has 64-bit jdk1.8.0_25 & jdk1.8.0_05in Program Files



From manasthakur17 at gmail.com  Wed Jan  7 03:58:27 2015
From: manasthakur17 at gmail.com (Manas Thakur)
Date: Wed, 7 Jan 2015 09:28:27 +0530
Subject: Building openjdk 8 on Mac OS X
Message-ID: <A35F9A37-868B-4086-A747-12A6BFF1E876@gmail.com>

Hi Toby,

Can you please share all those patches that you needed to do in order to successfully build jdk8 (or jdk8u) on MAC OS X Yosemite?

Regards,
Manas










From weijun.wang at oracle.com  Wed Jan  7 07:57:47 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Wed, 7 Jan 2015 15:57:47 +0800
Subject: Building openjdk 8 on Mac OS X
In-Reply-To: <A35F9A37-868B-4086-A747-12A6BFF1E876@gmail.com>
References: <A35F9A37-868B-4086-A747-12A6BFF1E876@gmail.com>
Message-ID: <53D45A45-1229-45CC-B94C-49DB9BF04A26@oracle.com>

Advices from Denis and Na (were in this thread, quoted at the end), and

1. MACOSX_DEPLOYMENT_TARGET is also necessary for make

2. I need an extra configure argument

   --with-tools-dir=/Applications/Xcode4.app/Contents/Developer/usr/bin

3. When applying Na's patch, make sure to use Xcode4.app if that's what your path is.

With these, I am able to build the latest jdk8u-dev forest.

--Max

----------Advice from Denis--------------

Steps:

1.  Download and save in some secure place Xcode4.6
2.  Make a link form Xcode.4 lipo to /usr/bin/lipo
3.  Set MACOSX_DEPLOYMENT_TARGET enviroment variable to 10.8
4.  Execute  configure like this

sh configure --with-freetype=/Volumes/HD-PATU3/tools/freetype-2.4.0/  --with-extra-cflags="-isysroot /Applications/Xcode4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -F/Applications/Xcode4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/ApplicationServices.framework/Frameworks" --with-extra-cxxflags="-isysroot /Applications/Xcode4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -F/Applications/Xcode4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/ApplicationServices.framework/Frameworks" --with-boot-jdk=/Library/Java/JavaVirtualMachines/jdk1.8.0_20.jdk/Contents/Home/

Thank you,
  Denis.

---------------Advice from Na-----------------

You need to patch /hotspot/make/bsd/makefiles/saproc.make to make it use
10.8sdk instead of system library in Yosemite.

- SALIBS = -g -framework Foundation
-F/System/Library/Frameworks/JavaVM.framework/Frameworks 
-framework JavaNativeFoundation -framework Security -framework CoreFoundation

+ SALIBS = -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform
/Developer/SDKs/MacOSX10.8.sdk
-g -framework Foundation
-F/System/Library/Frameworks/JavaVM.framework/Frameworks -framework
JavaNativeFoundation -framework Security -framework CoreFoundation

----------------end-----------------

> On Jan 7, 2015, at 11:58, Manas Thakur <manasthakur17 at gmail.com> wrote:
> 
> Hi Toby,
> 
> Can you please share all those patches that you needed to do in order to successfully build jdk8 (or jdk8u) on MAC OS X Yosemite?
> 
> Regards,
> Manas
> 
> 
> 
> 
> 
> 
> 
> 



From rkennke at redhat.com  Wed Jan  7 14:45:03 2015
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 07 Jan 2015 15:45:03 +0100
Subject: [PATCH] Fix Shark build in JDK9
Message-ID: <1420641903.6838.9.camel@localhost>

Hello there,

I made some fixes to the build machinery to be able to build Shark:

http://cr.openjdk.java.net/~rkennke/shark-build-top/
http://cr.openjdk.java.net/~rkennke/shark-build-hotspot/
http://cr.openjdk.java.net/~rkennke/shark-build-jdk/

In particular, it does:
- Improve the sed command to figure out the LLVM version. LLVM changed
its version string from x.y to x.y.z. The command now correctly strips
x.y.z to xy, we're only interested in the first two numbers. I also
hand-changed the generated configure, please forgive me ;-)
- In hotspot's makefile, I fixed a typo, allowing to build with unzipped
debug info.
- In JDK's build, I added the ZEROSHARK variant to exclude the SA
generation.

Notice that this alone doesn't make Shark build and run fine, it still
requires some code changes. Those are not related to build-dev though, I
will post them to the appropriate lists asap.

Can you please review the changes? I would like to push this to
build-infra/jdk9.

Regards,
Roman



From volker.simonis at gmail.com  Wed Jan  7 14:49:41 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 7 Jan 2015 15:49:41 +0100
Subject: Problem building JDK 8
In-Reply-To: <CA+kOe0_6fDS8eWCOZdh5V17Y5r3Ox_ShSixCUifXVbjbed7C-g@mail.gmail.com>
References: <5493EB1D.2010405@gmail.com>
	<CA+kOe08ZQF2n-Vw7oe_TwiAaDNU87gBdbeoUAsk3rNDog78oBQ@mail.gmail.com>
	<loom.20150105T153311-634@post.gmane.org>
	<CA+kOe0_6fDS8eWCOZdh5V17Y5r3Ox_ShSixCUifXVbjbed7C-g@mail.gmail.com>
Message-ID: <CA+3eh11ucGqzV7Bpi7ZpapnLFwmwT4pqE7U_G6_oSSjZk0aa=w@mail.gmail.com>

Hi Martin, Hadi,

I did the same (checked my own config.log files) and observed the same
think like Martin. But it seems that the "checking for.." lines are
only there for successful checks (look at other failed checks in
config log). Nevertheless I agree that it is strange that there's no
output at all before the error line.


On Mon, Jan 5, 2015 at 9:51 PM, Martin Buchholz <martinrb at google.com> wrote:
> It's a mystery.  My own successful config.log snippet with latest jdk8u is
> below.  Why didn't your config.log contain "checking for FREETYPE"?  Maybe
> a pkg-config problem? Are you doing something crazy like defining
> LD_LIBRARY_PATH? Someone will need to debug configure, perhaps using bash
> -x configure...
>
> configure:31477: checking for cups/ppd.h
> configure:31477: result: yes
> configure:32103: checking for FREETYPE
> configure:32110: $PKG_CONFIG --exists --print-errors "freetype2"
> configure:32113: $? = 0
> configure:32126: $PKG_CONFIG --exists --print-errors "freetype2"
> configure:32129: $? = 0
> configure:32164: result: yes
> configure:32181: checking for freetype
> configure:32183: result: yes (using pkg-config)
> configure:34567: checking if we can compile and link with freetype
> configure:34592:  /usr/bin/g++-4.8 -o conftest  -I/usr/include/freetype2
>   conftest.cpp  -lfreetype >&5
> configure:34592: $? = 0
> configure:34594: result: yes
> configure:34653: checking if we should bundle freetype
> configure:34658: result: no


From rkennke at redhat.com  Wed Jan  7 15:03:59 2015
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 07 Jan 2015 16:03:59 +0100
Subject: [PATCH] Fix Shark build in JDK9
In-Reply-To: <1420641903.6838.9.camel@localhost>
References: <1420641903.6838.9.camel@localhost>
Message-ID: <1420643039.6838.11.camel@localhost>

I just realized that I posted some unneeded stuff, and that the check
for ZERO *or* ZEROSHARK can be made simpler:

http://cr.openjdk.java.net/~rkennke/shark-build-jdk/webrev.01/

Roman

Am Mittwoch, den 07.01.2015 um 15:45 +0100 schrieb Roman Kennke:
> Hello there,
> 
> I made some fixes to the build machinery to be able to build Shark:
> 
> http://cr.openjdk.java.net/~rkennke/shark-build-top/
> http://cr.openjdk.java.net/~rkennke/shark-build-hotspot/
> http://cr.openjdk.java.net/~rkennke/shark-build-jdk/
> 
> In particular, it does:
> - Improve the sed command to figure out the LLVM version. LLVM changed
> its version string from x.y to x.y.z. The command now correctly strips
> x.y.z to xy, we're only interested in the first two numbers. I also
> hand-changed the generated configure, please forgive me ;-)
> - In hotspot's makefile, I fixed a typo, allowing to build with unzipped
> debug info.
> - In JDK's build, I added the ZEROSHARK variant to exclude the SA
> generation.
> 
> Notice that this alone doesn't make Shark build and run fine, it still
> requires some code changes. Those are not related to build-dev though, I
> will post them to the appropriate lists asap.
> 
> Can you please review the changes? I would like to push this to
> build-infra/jdk9.
> 
> Regards,
> Roman
> 




From erik.joelsson at oracle.com  Wed Jan  7 15:10:35 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 07 Jan 2015 16:10:35 +0100
Subject: [PATCH] Fix Shark build in JDK9
In-Reply-To: <1420641903.6838.9.camel@localhost>
References: <1420641903.6838.9.camel@localhost>
Message-ID: <54AD4C6B.1070702@oracle.com>

Hello,

On 2015-01-07 15:45, Roman Kennke wrote:
> Hello there,
>
> I made some fixes to the build machinery to be able to build Shark:
>
> http://cr.openjdk.java.net/~rkennke/shark-build-top/
Looks fine, but the generated configure script needs to be generated by 
the script as it also updates a timestamp inside the file. We will still 
need to update the closed version of the generated script in sync with 
this. I will be happy to push both when review has passed if you like.
> http://cr.openjdk.java.net/~rkennke/shark-build-hotspot/
That looks like a simple typo. Looks good to me. This is in hotspot 
however so will need to go through a hotspot forest and requires 2 
reviewers.
> http://cr.openjdk.java.net/~rkennke/shark-build-jdk/
Is the contents of the conditionals for SERVER, ZERO and ZEROSHARK the 
exact same? Perhaps change into one conditional like this?

ifneq ($(findstring $(JVM_VARIANTS), server zero zeroshark),)

I'm also pondering if the build_sa conditional could be made simpler, 
but this is planned to go away before JDK 9 is done so I'm ok with 
leaving it like this.

> In particular, it does:
> - Improve the sed command to figure out the LLVM version. LLVM changed
> its version string from x.y to x.y.z. The command now correctly strips
> x.y.z to xy, we're only interested in the first two numbers. I also
> hand-changed the generated configure, please forgive me ;-)
> - In hotspot's makefile, I fixed a typo, allowing to build with unzipped
> debug info.
> - In JDK's build, I added the ZEROSHARK variant to exclude the SA
> generation.
>
> Notice that this alone doesn't make Shark build and run fine, it still
> requires some code changes. Those are not related to build-dev though, I
> will post them to the appropriate lists asap.
>
> Can you please review the changes? I would like to push this to
> build-infra/jdk9.
Build changes go directly to jdk9/dev. The build-infra forest is for 
prototyping things for the build-infra project and has no scheduled 
pushes to jdk9. Perhaps it would be better to combine the above changes 
with your source changes and submit reviews separately for hotspot and 
root/jdk repos instead?

/Erik
> Regards,
> Roman
>



From david.r.chase at oracle.com  Wed Jan  7 15:27:16 2015
From: david.r.chase at oracle.com (David Chase)
Date: Wed, 7 Jan 2015 10:27:16 -0500
Subject: Building openjdk 8 on Mac OS X
In-Reply-To: <53D45A45-1229-45CC-B94C-49DB9BF04A26@oracle.com>
References: <A35F9A37-868B-4086-A747-12A6BFF1E876@gmail.com>
	<53D45A45-1229-45CC-B94C-49DB9BF04A26@oracle.com>
Message-ID: <66C782C4-4897-46C3-80DC-159A7759A823@oracle.com>

For reference, with version numbers, here is what worked for me this morning,
for both release and fastdebug builds (including closed bits):

I'm on Mavericks (10.9.5),
using Xcode 4.6.3, (sudo xcode-select -s /Applications/Xcode4.6.3.app/Contents/Developer)
MacPorts lipo (it works, put it earlier on your path because hotspot build references "lipo" with no fancy variables)

PATH=/opt/local/bin:/Users/dr2chase/work/graal/mxtool:/Users/dr2chase/bin:/usr/bin:/opt/local/sbin:/usr/local/bin:/usr/local/CrossPack-AVR/bin:/usr/sbin:/bin:/sbin

Note that I pick up a lot of stuff from MacPorts, and that has been known to solve some problems in the past even though it is not officially recommended:

spec.gmk:PACKAGE_PATH=/opt/local
spec.gmk:AR:= /opt/local/bin/ar
spec.gmk:NM:=/opt/local/bin/nm
spec.gmk:GNM:=/opt/local/bin/nm
spec.gmk:STRIP:=/opt/local/bin/strip
spec.gmk:LIPO:=/opt/local/bin/lipo
spec.gmk:POST_STRIP_CMD:=/opt/local/bin/strip -S
spec.gmk:NAWK:=/opt/local/bin/gawk
spec.gmk:SED:=/opt/local/bin/gsed
spec.gmk:OTOOL:=/opt/local/bin/otool
spec.gmk:READELF:=/opt/local/bin/greadelf
spec.gmk:FILE:=/opt/local/bin/file
spec.gmk:HG:=/opt/local/bin/hg
spec.sh:SED="/opt/local/bin/gsed"
spec.sh:POST_STRIP_CMD="/opt/local/bin/strip -S"

and did this change to SALIBS:

SALIBS = -isysroot /Applications/Xcode4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -g -framework Foundation -F/System/Library/Frameworks/JavaVM.framework/Frameworks -framework JavaNativeFoundation -framework Security -framework CoreFoundation

 ( or perhaps better:
SALIBS = -isysroot `xcode-select -p`/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -g -framework Foundation -F/System/Library/Frameworks/JavaVM.framework/Frameworks -framework JavaNativeFoundation -framework Security -framework CoreFoundation
) 

bash configure --with-extra-cflags="-isysroot /Applications/Xcode4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -F/Applications/Xcode4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/ApplicationServices.framework/Frameworks" --with-extra-cxxflags="-isysroot /Applications/Xcode4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -F/Applications/Xcode4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/ApplicationServices.framework/Frameworks"

( or perhaps better:
bash configure --with-extra-cflags="-isysroot `xcode-select -p`/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -F`xcode-select -p`/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/ApplicationServices.framework/Frameworks" --with-extra-cxxflags="-isysroot `xcode-select -p`/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -F`xcode-select -p`/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/ApplicationServices.framework/Frameworks"
)

MACOSX_DEPLOYMENT_TARGET=10.8 make MACOSX_DEPLOYMENT_TARGET=10.8 images CONF=fastdebug

and it built and it worked, at least once.

I have not tested this on 10.8 or 10.10 (yet).

David

On 2015-01-07, at 2:57 AM, Wang Weijun <weijun.wang at oracle.com> wrote:

> Advices from Denis and Na (were in this thread, quoted at the end), and
> 
> 1. MACOSX_DEPLOYMENT_TARGET is also necessary for make
> 
> 2. I need an extra configure argument
> 
>   --with-tools-dir=/Applications/Xcode4.app/Contents/Developer/usr/bin
> 
> 3. When applying Na's patch, make sure to use Xcode4.app if that's what your path is.
> 
> With these, I am able to build the latest jdk8u-dev forest.
> 
> --Max
> 
> ----------Advice from Denis--------------
> 
> Steps:
> 
> 1.  Download and save in some secure place Xcode4.6
> 2.  Make a link form Xcode.4 lipo to /usr/bin/lipo
> 3.  Set MACOSX_DEPLOYMENT_TARGET enviroment variable to 10.8
> 4.  Execute  configure like this
> 
> sh configure --with-freetype=/Volumes/HD-PATU3/tools/freetype-2.4.0/  --with-extra-cflags="-isysroot /Applications/Xcode4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -F/Applications/Xcode4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/ApplicationServices.framework/Frameworks" --with-extra-cxxflags="-isysroot /Applications/Xcode4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -F/Applications/Xcode4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/ApplicationServices.framework/Frameworks" --with-boot-jdk=/Library/Java/JavaVirtualMachines/jdk1.8.0_20.jdk/Contents/Home/
> 
> Thank you,
>  Denis.
> 
> ---------------Advice from Na-----------------
> 
> You need to patch /hotspot/make/bsd/makefiles/saproc.make to make it use
> 10.8sdk instead of system library in Yosemite.
> 
> - SALIBS = -g -framework Foundation
> -F/System/Library/Frameworks/JavaVM.framework/Frameworks 
> -framework JavaNativeFoundation -framework Security -framework CoreFoundation
> 
> + SALIBS = -isysroot
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform
> /Developer/SDKs/MacOSX10.8.sdk
> -g -framework Foundation
> -F/System/Library/Frameworks/JavaVM.framework/Frameworks -framework
> JavaNativeFoundation -framework Security -framework CoreFoundation
> 
> ----------------end-----------------
> 
>> On Jan 7, 2015, at 11:58, Manas Thakur <manasthakur17 at gmail.com> wrote:
>> 
>> Hi Toby,
>> 
>> Can you please share all those patches that you needed to do in order to successfully build jdk8 (or jdk8u) on MAC OS X Yosemite?
>> 
>> Regards,
>> Manas



From rkennke at redhat.com  Wed Jan  7 15:41:41 2015
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 07 Jan 2015 16:41:41 +0100
Subject: [PATCH] Fix Shark build in JDK9
In-Reply-To: <54AD4C6B.1070702@oracle.com>
References: <1420641903.6838.9.camel@localhost> <54AD4C6B.1070702@oracle.com>
Message-ID: <1420645301.6838.14.camel@localhost>

Hi Erik,

> > I made some fixes to the build machinery to be able to build Shark:
> >
> > http://cr.openjdk.java.net/~rkennke/shark-build-top/
> Looks fine, but the generated configure script needs to be generated by 
> the script as it also updates a timestamp inside the file. We will still 
> need to update the closed version of the generated script in sync with 
> this. I will be happy to push both when review has passed if you like.

That would be great.

> > http://cr.openjdk.java.net/~rkennke/shark-build-hotspot/
> That looks like a simple typo. Looks good to me. This is in hotspot 
> however so will need to go through a hotspot forest and requires 2 
> reviewers.

ok, I will finish my code-changes to hotspot and propose the whole bunch
to hotspot-dev separately as you suggested.

> > http://cr.openjdk.java.net/~rkennke/shark-build-jdk/
> Is the contents of the conditionals for SERVER, ZERO and ZEROSHARK the 
> exact same? Perhaps change into one conditional like this?

Please have a look at the updated simpler patch I posted right after the
first one:

http://cr.openjdk.java.net/~rkennke/shark-build-jdk/webrev.01/

Regards,
Roman




From cedric.champeau at gmail.com  Wed Jan  7 15:49:07 2015
From: cedric.champeau at gmail.com (=?UTF-8?B?Q8OpZHJpYyBDaGFtcGVhdQ==?=)
Date: Wed, 07 Jan 2015 16:49:07 +0100
Subject: Problem building JDK 8
In-Reply-To: <CA+3eh12P8mXGK__wpTkWVJiSYcDQmW+d8MKm5eoiVh7wceosXQ@mail.gmail.com>
References: <5493EB1D.2010405@gmail.com>
	<CA+3eh12P8mXGK__wpTkWVJiSYcDQmW+d8MKm5eoiVh7wceosXQ@mail.gmail.com>
Message-ID: <54AD5573.1000707@gmail.com>

I managed to get past this error using the following configuration line:

./configure --with-target-bits=64 
--with-freetype-include=/usr/include/freetype2/ 
--with-freetype-lib=/usr/lib/x86_64-linux-gnu

It's good enough for us to be able to build, so I'll stick with it, but 
it seems the detection mechanism is somehow broken.

On 05/01/2015 17:22, Volker Simonis wrote:
> Maybe this is a 32/64 bit mismatch - i.e. you are on a 64-bit machine
> with 64-bit libfreetype but configuring for 32-bit ?
>
>
>
> On Fri, Dec 19, 2014 at 10:08 AM, C?dric Champeau
> <cedric.champeau at gmail.com> wrote:
>> Hi everyone,
>>
>> Some of you may know that we try to test Groovy builds against the latest
>> versions of the JDK. For that, we have setup a CI build of OpenJDK 7, 8 and
>> 9. However, the JDK 8 builds have been failing for several months now (sorry
>> I didn't have much time to investigate this specific subject, so I rely on
>> EA builds instead, which gives us late but valuable feedback).
>>
>> Basically, in the JDK 8 build log (JDK 9 doesn't have the issue), I can read
>> this in the logs:
>>
>> [02:00:17]:     [Step 1/2] configure: error: Could not find freetype! You
>> might be able to fix this by running 'sudo apt-get install
>> libfreetype6-dev'.
>>
>> However if I try to do so, I see that freetype *is* installed:
>>
>> # apt-get install libfreetype6-dev
>> Reading package lists... Done
>> Building dependency tree
>> Reading state information... Done
>> libfreetype6-dev is already the newest version.
>>
>> The server is running Ubuntu 14.04.1 LTS, which gcc 4.8.2, which is supposed
>> to "work flawlessly" from what I read here:
>> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms
>>
>> We build from http://hg.openjdk.java.net/jdk8u/jdk8u
>>
>> Thanks for your help!
>>
>> --
>> C?dric Champeau
>> SpringSource - Pivotal
>> http://twitter.com/CedricChampeau
>> http://melix.github.io/blog
>> http://spring.io/ http://www.gopivotal.com/
>>


-- 
C?dric Champeau
Groovy language developer
http://twitter.com/CedricChampeau
http://melix.github.io/blog



From erik.joelsson at oracle.com  Wed Jan  7 15:53:25 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 07 Jan 2015 16:53:25 +0100
Subject: [PATCH] Fix Shark build in JDK9
In-Reply-To: <1420645301.6838.14.camel@localhost>
References: <1420641903.6838.9.camel@localhost>	 <54AD4C6B.1070702@oracle.com>
	<1420645301.6838.14.camel@localhost>
Message-ID: <54AD5675.7010101@oracle.com>


On 2015-01-07 16:41, Roman Kennke wrote:
> Hi Erik,
>
>>> I made some fixes to the build machinery to be able to build Shark:
>>>
>>> http://cr.openjdk.java.net/~rkennke/shark-build-top/
>> Looks fine, but the generated configure script needs to be generated by
>> the script as it also updates a timestamp inside the file. We will still
>> need to update the closed version of the generated script in sync with
>> this. I will be happy to push both when review has passed if you like.
> That would be great.
>
>>> http://cr.openjdk.java.net/~rkennke/shark-build-hotspot/
>> That looks like a simple typo. Looks good to me. This is in hotspot
>> however so will need to go through a hotspot forest and requires 2
>> reviewers.
> ok, I will finish my code-changes to hotspot and propose the whole bunch
> to hotspot-dev separately as you suggested.
Sounds like a good idea, thanks!
>>> http://cr.openjdk.java.net/~rkennke/shark-build-jdk/
>> Is the contents of the conditionals for SERVER, ZERO and ZEROSHARK the
>> exact same? Perhaps change into one conditional like this?
> Please have a look at the updated simpler patch I posted right after the
> first one:
>
> http://cr.openjdk.java.net/~rkennke/shark-build-jdk/webrev.01/
That indeed looks better.

Do you have a bug for this?

/Erik
> Regards,
> Roman
>
>



From volker.simonis at gmail.com  Wed Jan  7 15:58:33 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 7 Jan 2015 16:58:33 +0100
Subject: Problem building JDK 8
In-Reply-To: <54AD5573.1000707@gmail.com>
References: <5493EB1D.2010405@gmail.com>
	<CA+3eh12P8mXGK__wpTkWVJiSYcDQmW+d8MKm5eoiVh7wceosXQ@mail.gmail.com>
	<54AD5573.1000707@gmail.com>
Message-ID: <CA+3eh13sjoNMAe=hmtFCz3ZtvPugt4Td2a+Qd5eHRQmyaA+Jzg@mail.gmail.com>

Glad to hear that you were able to build.

I think it's the multi-arch configuration on Linux which is still
broken, but that's just my opinion:)
Nevertheless you are probably right that the build system could
somehow work around this or at least spit out a clearer error message.

Regards,
Volker


On Wed, Jan 7, 2015 at 4:49 PM, C?dric Champeau
<cedric.champeau at gmail.com> wrote:
> I managed to get past this error using the following configuration line:
>
> ./configure --with-target-bits=64
> --with-freetype-include=/usr/include/freetype2/
> --with-freetype-lib=/usr/lib/x86_64-linux-gnu
>
> It's good enough for us to be able to build, so I'll stick with it, but it
> seems the detection mechanism is somehow broken.
>
>
> On 05/01/2015 17:22, Volker Simonis wrote:
>>
>> Maybe this is a 32/64 bit mismatch - i.e. you are on a 64-bit machine
>> with 64-bit libfreetype but configuring for 32-bit ?
>>
>>
>>
>> On Fri, Dec 19, 2014 at 10:08 AM, C?dric Champeau
>> <cedric.champeau at gmail.com> wrote:
>>>
>>> Hi everyone,
>>>
>>> Some of you may know that we try to test Groovy builds against the latest
>>> versions of the JDK. For that, we have setup a CI build of OpenJDK 7, 8
>>> and
>>> 9. However, the JDK 8 builds have been failing for several months now
>>> (sorry
>>> I didn't have much time to investigate this specific subject, so I rely
>>> on
>>> EA builds instead, which gives us late but valuable feedback).
>>>
>>> Basically, in the JDK 8 build log (JDK 9 doesn't have the issue), I can
>>> read
>>> this in the logs:
>>>
>>> [02:00:17]:     [Step 1/2] configure: error: Could not find freetype! You
>>> might be able to fix this by running 'sudo apt-get install
>>> libfreetype6-dev'.
>>>
>>> However if I try to do so, I see that freetype *is* installed:
>>>
>>> # apt-get install libfreetype6-dev
>>> Reading package lists... Done
>>> Building dependency tree
>>> Reading state information... Done
>>> libfreetype6-dev is already the newest version.
>>>
>>> The server is running Ubuntu 14.04.1 LTS, which gcc 4.8.2, which is
>>> supposed
>>> to "work flawlessly" from what I read here:
>>> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms
>>>
>>> We build from http://hg.openjdk.java.net/jdk8u/jdk8u
>>>
>>> Thanks for your help!
>>>
>>> --
>>> C?dric Champeau
>>> SpringSource - Pivotal
>>> http://twitter.com/CedricChampeau
>>> http://melix.github.io/blog
>>> http://spring.io/ http://www.gopivotal.com/
>>>
>
>
> --
> C?dric Champeau
> Groovy language developer
> http://twitter.com/CedricChampeau
> http://melix.github.io/blog
>


From rkennke at redhat.com  Wed Jan  7 16:11:47 2015
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 07 Jan 2015 17:11:47 +0100
Subject: [PATCH] Fix Shark build in JDK9
In-Reply-To: <54AD5675.7010101@oracle.com>
References: <1420641903.6838.9.camel@localhost>
	<54AD4C6B.1070702@oracle.com> <1420645301.6838.14.camel@localhost>
	<54AD5675.7010101@oracle.com>
Message-ID: <1420647107.6838.15.camel@localhost>

Hi Erik,

> >>> I made some fixes to the build machinery to be able to build Shark:
> >>>
> >>> http://cr.openjdk.java.net/~rkennke/shark-build-top/
> >> Looks fine, but the generated configure script needs to be generated by
> >> the script as it also updates a timestamp inside the file. We will still
> >> need to update the closed version of the generated script in sync with
> >> this. I will be happy to push both when review has passed if you like.
> > That would be great.
> >
> >>> http://cr.openjdk.java.net/~rkennke/shark-build-hotspot/
> >> That looks like a simple typo. Looks good to me. This is in hotspot
> >> however so will need to go through a hotspot forest and requires 2
> >> reviewers.
> > ok, I will finish my code-changes to hotspot and propose the whole bunch
> > to hotspot-dev separately as you suggested.
> Sounds like a good idea, thanks!
> >>> http://cr.openjdk.java.net/~rkennke/shark-build-jdk/
> >> Is the contents of the conditionals for SERVER, ZERO and ZEROSHARK the
> >> exact same? Perhaps change into one conditional like this?
> > Please have a look at the updated simpler patch I posted right after the
> > first one:
> >
> > http://cr.openjdk.java.net/~rkennke/shark-build-jdk/webrev.01/
> That indeed looks better.
> 
> Do you have a bug for this?

No.

I haven't pushed any changes to JDK in a while. Is it possible in the
meantime for me to create my own bugs? Otherwise, please file one for
me :-)

Regards,
Roman




From erik.joelsson at oracle.com  Wed Jan  7 16:16:31 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 07 Jan 2015 17:16:31 +0100
Subject: [PATCH] Fix Shark build in JDK9
In-Reply-To: <1420647107.6838.15.camel@localhost>
References: <1420641903.6838.9.camel@localhost>		 <54AD4C6B.1070702@oracle.com>
	<1420645301.6838.14.camel@localhost>	 <54AD5675.7010101@oracle.com>
	<1420647107.6838.15.camel@localhost>
Message-ID: <54AD5BDF.1060401@oracle.com>


On 2015-01-07 17:11, Roman Kennke wrote:
> Hi Erik,
>
> Do you have a bug for this?
> No.
>
> I haven't pushed any changes to JDK in a while. Is it possible in the
> meantime for me to create my own bugs? Otherwise, please file one for
> me :-)
You should be able to log in to https://bugs.openjdk.java.net and create 
bugs since you have an OpenJDK identity.

/Erik
> Regards,
> Roman
>
>



From rkennke at redhat.com  Wed Jan  7 16:29:21 2015
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 07 Jan 2015 17:29:21 +0100
Subject: [PATCH] Fix Shark build in JDK9
In-Reply-To: <54AD5BDF.1060401@oracle.com>
References: <1420641903.6838.9.camel@localhost>
	<54AD4C6B.1070702@oracle.com> <1420645301.6838.14.camel@localhost>
	<54AD5675.7010101@oracle.com> <1420647107.6838.15.camel@localhost>
	<54AD5BDF.1060401@oracle.com>
Message-ID: <1420648161.6838.17.camel@localhost>

Am Mittwoch, den 07.01.2015 um 17:16 +0100 schrieb Erik Joelsson:
> On 2015-01-07 17:11, Roman Kennke wrote:
> > Hi Erik,
> >
> > Do you have a bug for this?
> > No.
> >
> > I haven't pushed any changes to JDK in a while. Is it possible in the
> > meantime for me to create my own bugs? Otherwise, please file one for
> > me :-)
> You should be able to log in to https://bugs.openjdk.java.net and create 
> bugs since you have an OpenJDK identity.

Done:

https://bugs.openjdk.java.net/browse/JDK-8068598

While I'm at it, is it possible for me to push my own changes (except
hotspot of course)? If yes, what needs to be done for regenerating the
configure files? Simply run autogen.sh in common/autoconf with whatever
version of autotools I have? Or doesn't it make sense at all b/c you
need to regenerate your closed scripts?

Roman



From erik.joelsson at oracle.com  Wed Jan  7 16:49:30 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 07 Jan 2015 17:49:30 +0100
Subject: [PATCH] Fix Shark build in JDK9
In-Reply-To: <1420648161.6838.17.camel@localhost>
References: <1420641903.6838.9.camel@localhost>			
	<54AD4C6B.1070702@oracle.com>
	<1420645301.6838.14.camel@localhost>		
	<54AD5675.7010101@oracle.com> <1420647107.6838.15.camel@localhost>	
	<54AD5BDF.1060401@oracle.com> <1420648161.6838.17.camel@localhost>
Message-ID: <54AD639A.2060200@oracle.com>


On 2015-01-07 17:29, Roman Kennke wrote:
> Am Mittwoch, den 07.01.2015 um 17:16 +0100 schrieb Erik Joelsson:
>> On 2015-01-07 17:11, Roman Kennke wrote:
>>> Hi Erik,
>>>
>>> Do you have a bug for this?
>>> No.
>>>
>>> I haven't pushed any changes to JDK in a while. Is it possible in the
>>> meantime for me to create my own bugs? Otherwise, please file one for
>>> me :-)
>> You should be able to log in to https://bugs.openjdk.java.net and create
>> bugs since you have an OpenJDK identity.
> Done:
>
> https://bugs.openjdk.java.net/browse/JDK-8068598
>
> While I'm at it, is it possible for me to push my own changes (except
> hotspot of course)? If yes, what needs to be done for regenerating the
> configure files? Simply run autogen.sh in common/autoconf with whatever
> version of autotools I have? Or doesn't it make sense at all b/c you
> need to regenerate your closed scripts?
It requires you to run common/autogen.sh yes, and that will require you 
to have autoconf 2.69 installed. But since we also need to regenerate 
the closed version, I can take care of the push for you. Will do it 
tomorrow if that's ok?

/Erik
> Roman
>



From volker.simonis at gmail.com  Wed Jan  7 17:00:39 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 7 Jan 2015 18:00:39 +0100
Subject: [PATCH] Fix Shark build in JDK9
In-Reply-To: <1420648161.6838.17.camel@localhost>
References: <1420641903.6838.9.camel@localhost> <54AD4C6B.1070702@oracle.com>
	<1420645301.6838.14.camel@localhost> <54AD5675.7010101@oracle.com>
	<1420647107.6838.15.camel@localhost> <54AD5BDF.1060401@oracle.com>
	<1420648161.6838.17.camel@localhost>
Message-ID: <CA+3eh109pY1Z8UXJUo4FcTwk2xNEL4b0Bs7g3-9odVbtoiNDZQ@mail.gmail.com>

On Wed, Jan 7, 2015 at 5:29 PM, Roman Kennke <rkennke at redhat.com> wrote:
> Am Mittwoch, den 07.01.2015 um 17:16 +0100 schrieb Erik Joelsson:
>> On 2015-01-07 17:11, Roman Kennke wrote:
>> > Hi Erik,
>> >
>> > Do you have a bug for this?
>> > No.
>> >
>> > I haven't pushed any changes to JDK in a while. Is it possible in the
>> > meantime for me to create my own bugs? Otherwise, please file one for
>> > me :-)
>> You should be able to log in to https://bugs.openjdk.java.net and create
>> bugs since you have an OpenJDK identity.
>
> Done:
>
> https://bugs.openjdk.java.net/browse/JDK-8068598
>
> While I'm at it, is it possible for me to push my own changes (except
> hotspot of course)?

Hi Roman,

in order to push changes you first have to be a committer (which you are).

As you noticed, external (i.e. external to Oracle) committers can not
push changes to the hotspot repository with the exception of changes
which only touch community-supported platform files (i.e. all files
under src/cpu/{ppc, zero}, src/os/aix, ...)

Besides that you should be technically able to push changes to all
other repositories but you shouldn't do that for changes which require
changes in the closed source files Oracle maintains in parallel to the
OpenJDK sources. These are for example all the files which require the
regeneration of the generated configure script.

Depending on your time constraints it may be reasonable to ask Erik to
push your top-level/jdk changes right into the corresponding hotspot
forest in which you want to do your hotspot changes. Otherwise, if
your top-level/jdk changes are pushed to jdk9/dev it may take up to
two weeks until they arrive for example in jdk9/hs-rt.

Regards,
Volker

PS: by the way, the changes themselves look fine to me:)

> If yes, what needs to be done for regenerating the
> configure files? Simply run autogen.sh in common/autoconf with whatever
> version of autotools I have? Or doesn't it make sense at all b/c you
> need to regenerate your closed scripts?
>
> Roman
>


From rkennke at redhat.com  Wed Jan  7 17:10:50 2015
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 07 Jan 2015 18:10:50 +0100
Subject: [PATCH] Fix Shark build in JDK9
In-Reply-To: <54AD639A.2060200@oracle.com>
References: <1420641903.6838.9.camel@localhost>
	<54AD4C6B.1070702@oracle.com> <1420645301.6838.14.camel@localhost>
	<54AD5675.7010101@oracle.com> <1420647107.6838.15.camel@localhost>
	<54AD5BDF.1060401@oracle.com> <1420648161.6838.17.camel@localhost>
	<54AD639A.2060200@oracle.com>
Message-ID: <1420650650.6838.18.camel@localhost>

Am Mittwoch, den 07.01.2015 um 17:49 +0100 schrieb Erik Joelsson:
> On 2015-01-07 17:29, Roman Kennke wrote:
> > Am Mittwoch, den 07.01.2015 um 17:16 +0100 schrieb Erik Joelsson:
> >> On 2015-01-07 17:11, Roman Kennke wrote:
> >>> Hi Erik,
> >>>
> >>> Do you have a bug for this?
> >>> No.
> >>>
> >>> I haven't pushed any changes to JDK in a while. Is it possible in the
> >>> meantime for me to create my own bugs? Otherwise, please file one for
> >>> me :-)
> >> You should be able to log in to https://bugs.openjdk.java.net and create
> >> bugs since you have an OpenJDK identity.
> > Done:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8068598
> >
> > While I'm at it, is it possible for me to push my own changes (except
> > hotspot of course)? If yes, what needs to be done for regenerating the
> > configure files? Simply run autogen.sh in common/autoconf with whatever
> > version of autotools I have? Or doesn't it make sense at all b/c you
> > need to regenerate your closed scripts?
> It requires you to run common/autogen.sh yes, and that will require you 
> to have autoconf 2.69 installed. But since we also need to regenerate 
> the closed version, I can take care of the push for you. Will do it 
> tomorrow if that's ok?

Sure, please go ahead and push the top-level and JDK changes.

Thanks a lot!

Roman




From rkennke at redhat.com  Wed Jan  7 20:21:42 2015
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 07 Jan 2015 21:21:42 +0100
Subject: [PATCH] Fix Shark build in JDK9
In-Reply-To: <54AD639A.2060200@oracle.com>
References: <1420641903.6838.9.camel@localhost>
	<54AD4C6B.1070702@oracle.com> <1420645301.6838.14.camel@localhost>
	<54AD5675.7010101@oracle.com> <1420647107.6838.15.camel@localhost>
	<54AD5BDF.1060401@oracle.com> <1420648161.6838.17.camel@localhost>
	<54AD639A.2060200@oracle.com>
Message-ID: <1420662102.6838.23.camel@localhost>

Hi Erik,

When I built Zero and Shark on my Raspberry Pi, I noticed another
problem when copying jvm.cfg into the right places. I fixed it in a
similar way as I did for the SA stuff:

http://cr.openjdk.java.net/~rkennke/shark-build-jdk/webrev.02/

I think that should be all for now.

Please push that into JDK9 if you think that's fine.

Best regards,
Roman

Am Mittwoch, den 07.01.2015 um 17:49 +0100 schrieb Erik Joelsson:
> On 2015-01-07 17:29, Roman Kennke wrote:
> > Am Mittwoch, den 07.01.2015 um 17:16 +0100 schrieb Erik Joelsson:
> >> On 2015-01-07 17:11, Roman Kennke wrote:
> >>> Hi Erik,
> >>>
> >>> Do you have a bug for this?
> >>> No.
> >>>
> >>> I haven't pushed any changes to JDK in a while. Is it possible in the
> >>> meantime for me to create my own bugs? Otherwise, please file one for
> >>> me :-)
> >> You should be able to log in to https://bugs.openjdk.java.net and create
> >> bugs since you have an OpenJDK identity.
> > Done:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8068598
> >
> > While I'm at it, is it possible for me to push my own changes (except
> > hotspot of course)? If yes, what needs to be done for regenerating the
> > configure files? Simply run autogen.sh in common/autoconf with whatever
> > version of autotools I have? Or doesn't it make sense at all b/c you
> > need to regenerate your closed scripts?
> It requires you to run common/autogen.sh yes, and that will require you 
> to have autoconf 2.69 installed. But since we also need to regenerate 
> the closed version, I can take care of the push for you. Will do it 
> tomorrow if that's ok?
> 
> /Erik
> > Roman
> >
> 




From david.dehaven at oracle.com  Wed Jan  7 23:33:45 2015
From: david.dehaven at oracle.com (David DeHaven)
Date: Wed, 7 Jan 2015 15:33:45 -0800
Subject: Building openjdk 8 on Mac OS X
In-Reply-To: <66C782C4-4897-46C3-80DC-159A7759A823@oracle.com>
References: <A35F9A37-868B-4086-A747-12A6BFF1E876@gmail.com>
	<53D45A45-1229-45CC-B94C-49DB9BF04A26@oracle.com>
	<66C782C4-4897-46C3-80DC-159A7759A823@oracle.com>
Message-ID: <0D759210-1C02-4C52-9661-D0E8529CBBC8@oracle.com>


> MacPorts lipo (it works, put it earlier on your path because hotspot build references "lipo" with no fancy variables)

The lipo problem is freaking annoying. The issue is Xcode 4 doesn't have it in the OSX toolchain, it installed the actual binary to /usr/bin/lipo. In Xcode 5 that was replaced by a stub binary that forks xcrun to find the actual tool which is now located in the Xcode Developer directory. There's a bug in the stub tool that prevents it from exiting cleanly when it can't find the actual tool, so it goes into an infinite loop of calling xcrun to find the tool and failing. Incidentally, you can apply one of the fixes below, then call "xcrun -k lipo" and if you have lipo looping infinitely in another terminal it will suddenly start working.

Unfortunately I think it's the one thing that may require manual intervention (once I get my backport of 8043340 done, which will be soon..), there's just no way around this until Apple fixes their bug.

There's three solutions to this that I don't think are too ugly:
1> Install cctools in MacPorts, though this leaves the broken /usr/bin/lipo version around to break things in the future
2> Xcode 4 has lipo in the iOS Platform Developer directory, make the following symlink (or copy the executable):
lrwxr-xr-x  1 daved  admin  56 Jan  7 12:43 /path/to/Xcode4.app/Contents/Developer/usr/bin/lipo -> ../../Platforms/iPhoneOS.platform/Developer/usr/bin/lipo
3> Copy Xcode 5's version of lipo to /usr/bin, or you could even copy it to Xcode4.app/Contents/Developer/usr/bin/lipo

Option 2 is probably the most future-proof as it allows the use of xcode-select to choose Xcode 4, even after copying to a different system (it's also scriptable!).

I'm playing around with detecting if lipo is broken, if I can detect it reliably I can change the path to use the iOS version instead (which is the same executable..). If that can be done then none of the above will be necessary. Unfortunately detecting if something hangs indefinitely (in a *clean* and reliable way) from a shell script is not trivial. I may have to resort to a perl one-liner.


IMHO, the best solution would be to remove the use of lipo entirely, since we don't and likely will never actually support universal binaries on Mac.

-DrD-



From david.holmes at oracle.com  Thu Jan  8 02:12:44 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 08 Jan 2015 12:12:44 +1000
Subject: [PATCH] Fix Shark build in JDK9
In-Reply-To: <54AD4C6B.1070702@oracle.com>
References: <1420641903.6838.9.camel@localhost> <54AD4C6B.1070702@oracle.com>
Message-ID: <54ADE79C.4070309@oracle.com>

On 8/01/2015 1:10 AM, Erik Joelsson wrote:
> Hello,
>
> On 2015-01-07 15:45, Roman Kennke wrote:
>> Hello there,
>>
>> I made some fixes to the build machinery to be able to build Shark:
>>
>> http://cr.openjdk.java.net/~rkennke/shark-build-top/
> Looks fine, but the generated configure script needs to be generated by
> the script as it also updates a timestamp inside the file. We will still
> need to update the closed version of the generated script in sync with
> this. I will be happy to push both when review has passed if you like.
>> http://cr.openjdk.java.net/~rkennke/shark-build-hotspot/
> That looks like a simple typo. Looks good to me. This is in hotspot
> however so will need to go through a hotspot forest and requires 2
> reviewers.

I think this is trivial enough that it doesn't matter which forest it 
goes through - better to keep everything in one forest though. I can add 
my Review to Eriks and that will suffice.

David
-----

>> http://cr.openjdk.java.net/~rkennke/shark-build-jdk/
> Is the contents of the conditionals for SERVER, ZERO and ZEROSHARK the
> exact same? Perhaps change into one conditional like this?
>
> ifneq ($(findstring $(JVM_VARIANTS), server zero zeroshark),)
>
> I'm also pondering if the build_sa conditional could be made simpler,
> but this is planned to go away before JDK 9 is done so I'm ok with
> leaving it like this.
>
>> In particular, it does:
>> - Improve the sed command to figure out the LLVM version. LLVM changed
>> its version string from x.y to x.y.z. The command now correctly strips
>> x.y.z to xy, we're only interested in the first two numbers. I also
>> hand-changed the generated configure, please forgive me ;-)
>> - In hotspot's makefile, I fixed a typo, allowing to build with unzipped
>> debug info.
>> - In JDK's build, I added the ZEROSHARK variant to exclude the SA
>> generation.
>>
>> Notice that this alone doesn't make Shark build and run fine, it still
>> requires some code changes. Those are not related to build-dev though, I
>> will post them to the appropriate lists asap.
>>
>> Can you please review the changes? I would like to push this to
>> build-infra/jdk9.
> Build changes go directly to jdk9/dev. The build-infra forest is for
> prototyping things for the build-infra project and has no scheduled
> pushes to jdk9. Perhaps it would be better to combine the above changes
> with your source changes and submit reviews separately for hotspot and
> root/jdk repos instead?
>
> /Erik
>> Regards,
>> Roman
>>
>


From sundararajan.athijegannathan at oracle.com  Thu Jan  8 06:52:16 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Thu, 08 Jan 2015 12:22:16 +0530
Subject: RFR 8068650: https://bugs.openjdk.java.net/browse/JDK-8068650
Message-ID: <54AE2920.7080107@oracle.com>

Hi,

Please review http://cr.openjdk.java.net/~sundar/8068650/ for 
https://bugs.openjdk.java.net/browse/JDK-8068650

This issue was caused by another makefile fix to generate docs for 
nashorn. I'm cc'ing nashorn-dev and jdk8u-dev as the fix has to be in 
jdk8u release(s). jdk9 has proper makefile changes (jdk8u only issue).

Thanks,
-Sundar


From erik.joelsson at oracle.com  Thu Jan  8 10:03:55 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 08 Jan 2015 11:03:55 +0100
Subject: [PATCH] Fix Shark build in JDK9
In-Reply-To: <1420662102.6838.23.camel@localhost>
References: <1420641903.6838.9.camel@localhost>				
	<54AD4C6B.1070702@oracle.com>
	<1420645301.6838.14.camel@localhost>			
	<54AD5675.7010101@oracle.com>
	<1420647107.6838.15.camel@localhost>		
	<54AD5BDF.1060401@oracle.com> <1420648161.6838.17.camel@localhost>	
	<54AD639A.2060200@oracle.com> <1420662102.6838.23.camel@localhost>
Message-ID: <54AE560B.3060200@oracle.com>

Hello Roman,

This addition looks good to me.

Thinking about what the others said, it might be inconvenient to have 
all this be pushed to different forests. I tried applying all the 
changes to jdk9/hs-rt, but I can't seem to build zeroshark.. Did you 
have more hotspot changes to be able to finish the build?

My failure is:

  ciTypeFlow.o 
/localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/ci/ciTypeFlow.cpp
In file included from 
/localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/regmask.hpp:29:0,
                  from 
/localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/compile.hpp:40,
                  from 
/localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/ci/ciTypeFlow.cpp:38:
/localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/optoreg.hpp:40:39: 
fatal error: adfiles/adGlobals_zero.hpp: No such file or directory

 From what I can see, adfiles are not generated for zero or zeroshark 
builds, so the include should probably be removed.

Would you still like me to push what you currently have to hs-rt?

/Erik

On 2015-01-07 21:21, Roman Kennke wrote:
> Hi Erik,
>
> When I built Zero and Shark on my Raspberry Pi, I noticed another
> problem when copying jvm.cfg into the right places. I fixed it in a
> similar way as I did for the SA stuff:
>
> http://cr.openjdk.java.net/~rkennke/shark-build-jdk/webrev.02/
>
> I think that should be all for now.
>
> Please push that into JDK9 if you think that's fine.
>
> Best regards,
> Roman
>
> Am Mittwoch, den 07.01.2015 um 17:49 +0100 schrieb Erik Joelsson:
>> On 2015-01-07 17:29, Roman Kennke wrote:
>>> Am Mittwoch, den 07.01.2015 um 17:16 +0100 schrieb Erik Joelsson:
>>>> On 2015-01-07 17:11, Roman Kennke wrote:
>>>>> Hi Erik,
>>>>>
>>>>> Do you have a bug for this?
>>>>> No.
>>>>>
>>>>> I haven't pushed any changes to JDK in a while. Is it possible in the
>>>>> meantime for me to create my own bugs? Otherwise, please file one for
>>>>> me :-)
>>>> You should be able to log in to https://bugs.openjdk.java.net and create
>>>> bugs since you have an OpenJDK identity.
>>> Done:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8068598
>>>
>>> While I'm at it, is it possible for me to push my own changes (except
>>> hotspot of course)? If yes, what needs to be done for regenerating the
>>> configure files? Simply run autogen.sh in common/autoconf with whatever
>>> version of autotools I have? Or doesn't it make sense at all b/c you
>>> need to regenerate your closed scripts?
>> It requires you to run common/autogen.sh yes, and that will require you
>> to have autoconf 2.69 installed. But since we also need to regenerate
>> the closed version, I can take care of the push for you. Will do it
>> tomorrow if that's ok?
>>
>> /Erik
>>> Roman
>>>
>



From rkennke at redhat.com  Thu Jan  8 11:01:21 2015
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 08 Jan 2015 12:01:21 +0100
Subject: [PATCH] Fix Shark build in JDK9
In-Reply-To: <54AE560B.3060200@oracle.com>
References: <1420641903.6838.9.camel@localhost>
	<54AD4C6B.1070702@oracle.com> <1420645301.6838.14.camel@localhost>
	<54AD5675.7010101@oracle.com> <1420647107.6838.15.camel@localhost>
	<54AD5BDF.1060401@oracle.com> <1420648161.6838.17.camel@localhost>
	<54AD639A.2060200@oracle.com> <1420662102.6838.23.camel@localhost>
	<54AE560B.3060200@oracle.com>
Message-ID: <1420714881.6838.25.camel@localhost>

Hi Erik,

I'm CC-ing hotspot-dev for review of Hotspot code related changes.

Yes, some additional changes to Hotspot are required. This is the full
set of changes needed to build and run Shark:

http://cr.openjdk.java.net/~rkennke/shark-build-hotspot/webrev.01/

In detail:

- In the Makefile fix a typo to be able to build unzipped debuginfo.
- In ciTypeFlow.cpp only include some files and code only when building
C2. I don't think that code makes sense outside of C2. (That's the issue
that you've seen).
- In systemDictionary.cpp, exclude some code for Shark that creates and
checks native wrappers for method handle intrinsics. Invokedynamic stuff
is not yet implemented in Shark, so we can't do this.
- In allocation.hpp, exclude the operator overrides for new etc, LLVM
does allocations itself, and this would blow up.
- In handles.hpp and handles.inline.hpp, I added an argument
check_in_stack so that I can disable the in-stack check for the
SharkNativeWrapper. The SharkNativeWrapper is allocated on-heap and the
methodHandle inside the SharkNativeWrapper. I could have excluded that
check altogther using an #ifndef SHARK, but the way I implemented it
seemed more finegrained.
- In SharkCompiler, I pulled out the code to initialize LLVM into its
own method, and the call to set_state(initialized) out of the
execution-engine-lock. This would otherwise complain about wrong
lock-ordering.
- In SharkRuntime, I changed the cast from intptr_t to oop to work with
the new picky compilers ;-)

Please review.

Thanks and best regards,
Roman

Am Donnerstag, den 08.01.2015 um 11:03 +0100 schrieb Erik Joelsson:
> Hello Roman,
> 
> This addition looks good to me.
> 
> Thinking about what the others said, it might be inconvenient to have 
> all this be pushed to different forests. I tried applying all the 
> changes to jdk9/hs-rt, but I can't seem to build zeroshark.. Did you 
> have more hotspot changes to be able to finish the build?
> 
> My failure is:
> 
>   ciTypeFlow.o 
> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/ci/ciTypeFlow.cpp
> In file included from 
> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/regmask.hpp:29:0,
>                   from 
> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/compile.hpp:40,
>                   from 
> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/ci/ciTypeFlow.cpp:38:
> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/optoreg.hpp:40:39: 
> fatal error: adfiles/adGlobals_zero.hpp: No such file or directory
> 
>  From what I can see, adfiles are not generated for zero or zeroshark 
> builds, so the include should probably be removed.
> 
> Would you still like me to push what you currently have to hs-rt?
> 
> /Erik
> 
> On 2015-01-07 21:21, Roman Kennke wrote:
> > Hi Erik,
> >
> > When I built Zero and Shark on my Raspberry Pi, I noticed another
> > problem when copying jvm.cfg into the right places. I fixed it in a
> > similar way as I did for the SA stuff:
> >
> > http://cr.openjdk.java.net/~rkennke/shark-build-jdk/webrev.02/
> >
> > I think that should be all for now.
> >
> > Please push that into JDK9 if you think that's fine.
> >
> > Best regards,
> > Roman
> >
> > Am Mittwoch, den 07.01.2015 um 17:49 +0100 schrieb Erik Joelsson:
> >> On 2015-01-07 17:29, Roman Kennke wrote:
> >>> Am Mittwoch, den 07.01.2015 um 17:16 +0100 schrieb Erik Joelsson:
> >>>> On 2015-01-07 17:11, Roman Kennke wrote:
> >>>>> Hi Erik,
> >>>>>
> >>>>> Do you have a bug for this?
> >>>>> No.
> >>>>>
> >>>>> I haven't pushed any changes to JDK in a while. Is it possible in the
> >>>>> meantime for me to create my own bugs? Otherwise, please file one for
> >>>>> me :-)
> >>>> You should be able to log in to https://bugs.openjdk.java.net and create
> >>>> bugs since you have an OpenJDK identity.
> >>> Done:
> >>>
> >>> https://bugs.openjdk.java.net/browse/JDK-8068598
> >>>
> >>> While I'm at it, is it possible for me to push my own changes (except
> >>> hotspot of course)? If yes, what needs to be done for regenerating the
> >>> configure files? Simply run autogen.sh in common/autoconf with whatever
> >>> version of autotools I have? Or doesn't it make sense at all b/c you
> >>> need to regenerate your closed scripts?
> >> It requires you to run common/autogen.sh yes, and that will require you
> >> to have autoconf 2.69 installed. But since we also need to regenerate
> >> the closed version, I can take care of the push for you. Will do it
> >> tomorrow if that's ok?
> >>
> >> /Erik
> >>> Roman
> >>>
> >
> 




From rkennke at redhat.com  Thu Jan  8 11:05:46 2015
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 08 Jan 2015 12:05:46 +0100
Subject: [PATCH] Fix Shark build in JDK9
In-Reply-To: <54AE560B.3060200@oracle.com>
References: <1420641903.6838.9.camel@localhost>
	<54AD4C6B.1070702@oracle.com> <1420645301.6838.14.camel@localhost>
	<54AD5675.7010101@oracle.com> <1420647107.6838.15.camel@localhost>
	<54AD5BDF.1060401@oracle.com> <1420648161.6838.17.camel@localhost>
	<54AD639A.2060200@oracle.com> <1420662102.6838.23.camel@localhost>
	<54AE560B.3060200@oracle.com>
Message-ID: <1420715146.6838.27.camel@localhost>

Oh and notice that if you try to build it yourself, use a version of
LLVM < 3.5. In 3.5, C++11 is used/required, and OpenJDK doesn't support
C++11 yet. (are there any plans about this?) I'd recommend LLVM 3.4.2.

Roman

Am Donnerstag, den 08.01.2015 um 11:03 +0100 schrieb Erik Joelsson:
> Hello Roman,
> 
> This addition looks good to me.
> 
> Thinking about what the others said, it might be inconvenient to have 
> all this be pushed to different forests. I tried applying all the 
> changes to jdk9/hs-rt, but I can't seem to build zeroshark.. Did you 
> have more hotspot changes to be able to finish the build?
> 
> My failure is:
> 
>   ciTypeFlow.o 
> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/ci/ciTypeFlow.cpp
> In file included from 
> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/regmask.hpp:29:0,
>                   from 
> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/compile.hpp:40,
>                   from 
> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/ci/ciTypeFlow.cpp:38:
> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/optoreg.hpp:40:39: 
> fatal error: adfiles/adGlobals_zero.hpp: No such file or directory
> 
>  From what I can see, adfiles are not generated for zero or zeroshark 
> builds, so the include should probably be removed.
> 
> Would you still like me to push what you currently have to hs-rt?
> 
> /Erik
> 
> On 2015-01-07 21:21, Roman Kennke wrote:
> > Hi Erik,
> >
> > When I built Zero and Shark on my Raspberry Pi, I noticed another
> > problem when copying jvm.cfg into the right places. I fixed it in a
> > similar way as I did for the SA stuff:
> >
> > http://cr.openjdk.java.net/~rkennke/shark-build-jdk/webrev.02/
> >
> > I think that should be all for now.
> >
> > Please push that into JDK9 if you think that's fine.
> >
> > Best regards,
> > Roman
> >
> > Am Mittwoch, den 07.01.2015 um 17:49 +0100 schrieb Erik Joelsson:
> >> On 2015-01-07 17:29, Roman Kennke wrote:
> >>> Am Mittwoch, den 07.01.2015 um 17:16 +0100 schrieb Erik Joelsson:
> >>>> On 2015-01-07 17:11, Roman Kennke wrote:
> >>>>> Hi Erik,
> >>>>>
> >>>>> Do you have a bug for this?
> >>>>> No.
> >>>>>
> >>>>> I haven't pushed any changes to JDK in a while. Is it possible in the
> >>>>> meantime for me to create my own bugs? Otherwise, please file one for
> >>>>> me :-)
> >>>> You should be able to log in to https://bugs.openjdk.java.net and create
> >>>> bugs since you have an OpenJDK identity.
> >>> Done:
> >>>
> >>> https://bugs.openjdk.java.net/browse/JDK-8068598
> >>>
> >>> While I'm at it, is it possible for me to push my own changes (except
> >>> hotspot of course)? If yes, what needs to be done for regenerating the
> >>> configure files? Simply run autogen.sh in common/autoconf with whatever
> >>> version of autotools I have? Or doesn't it make sense at all b/c you
> >>> need to regenerate your closed scripts?
> >> It requires you to run common/autogen.sh yes, and that will require you
> >> to have autoconf 2.69 installed. But since we also need to regenerate
> >> the closed version, I can take care of the push for you. Will do it
> >> tomorrow if that's ok?
> >>
> >> /Erik
> >>> Roman
> >>>
> >
> 




From david.holmes at oracle.com  Thu Jan  8 11:20:55 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 08 Jan 2015 21:20:55 +1000
Subject: [PATCH] Fix Shark build in JDK9
In-Reply-To: <1420715146.6838.27.camel@localhost>
References: <1420641903.6838.9.camel@localhost>	<54AD4C6B.1070702@oracle.com>
	<1420645301.6838.14.camel@localhost>	<54AD5675.7010101@oracle.com>
	<1420647107.6838.15.camel@localhost>	<54AD5BDF.1060401@oracle.com>
	<1420648161.6838.17.camel@localhost>	<54AD639A.2060200@oracle.com>
	<1420662102.6838.23.camel@localhost>	<54AE560B.3060200@oracle.com>
	<1420715146.6838.27.camel@localhost>
Message-ID: <54AE6817.1080206@oracle.com>

On 8/01/2015 9:05 PM, Roman Kennke wrote:
> Oh and notice that if you try to build it yourself, use a version of
> LLVM < 3.5. In 3.5, C++11 is used/required, and OpenJDK doesn't support
> C++11 yet. (are there any plans about this?) I'd recommend LLVM 3.4.2.

C++11? We still have workarounds for compilers that don't support C99 :(

David

> Roman
>
> Am Donnerstag, den 08.01.2015 um 11:03 +0100 schrieb Erik Joelsson:
>> Hello Roman,
>>
>> This addition looks good to me.
>>
>> Thinking about what the others said, it might be inconvenient to have
>> all this be pushed to different forests. I tried applying all the
>> changes to jdk9/hs-rt, but I can't seem to build zeroshark.. Did you
>> have more hotspot changes to be able to finish the build?
>>
>> My failure is:
>>
>>    ciTypeFlow.o
>> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/ci/ciTypeFlow.cpp
>> In file included from
>> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/regmask.hpp:29:0,
>>                    from
>> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/compile.hpp:40,
>>                    from
>> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/ci/ciTypeFlow.cpp:38:
>> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/optoreg.hpp:40:39:
>> fatal error: adfiles/adGlobals_zero.hpp: No such file or directory
>>
>>   From what I can see, adfiles are not generated for zero or zeroshark
>> builds, so the include should probably be removed.
>>
>> Would you still like me to push what you currently have to hs-rt?
>>
>> /Erik
>>
>> On 2015-01-07 21:21, Roman Kennke wrote:
>>> Hi Erik,
>>>
>>> When I built Zero and Shark on my Raspberry Pi, I noticed another
>>> problem when copying jvm.cfg into the right places. I fixed it in a
>>> similar way as I did for the SA stuff:
>>>
>>> http://cr.openjdk.java.net/~rkennke/shark-build-jdk/webrev.02/
>>>
>>> I think that should be all for now.
>>>
>>> Please push that into JDK9 if you think that's fine.
>>>
>>> Best regards,
>>> Roman
>>>
>>> Am Mittwoch, den 07.01.2015 um 17:49 +0100 schrieb Erik Joelsson:
>>>> On 2015-01-07 17:29, Roman Kennke wrote:
>>>>> Am Mittwoch, den 07.01.2015 um 17:16 +0100 schrieb Erik Joelsson:
>>>>>> On 2015-01-07 17:11, Roman Kennke wrote:
>>>>>>> Hi Erik,
>>>>>>>
>>>>>>> Do you have a bug for this?
>>>>>>> No.
>>>>>>>
>>>>>>> I haven't pushed any changes to JDK in a while. Is it possible in the
>>>>>>> meantime for me to create my own bugs? Otherwise, please file one for
>>>>>>> me :-)
>>>>>> You should be able to log in to https://bugs.openjdk.java.net and create
>>>>>> bugs since you have an OpenJDK identity.
>>>>> Done:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8068598
>>>>>
>>>>> While I'm at it, is it possible for me to push my own changes (except
>>>>> hotspot of course)? If yes, what needs to be done for regenerating the
>>>>> configure files? Simply run autogen.sh in common/autoconf with whatever
>>>>> version of autotools I have? Or doesn't it make sense at all b/c you
>>>>> need to regenerate your closed scripts?
>>>> It requires you to run common/autogen.sh yes, and that will require you
>>>> to have autoconf 2.69 installed. But since we also need to regenerate
>>>> the closed version, I can take care of the push for you. Will do it
>>>> tomorrow if that's ok?
>>>>
>>>> /Erik
>>>>> Roman
>>>>>
>>>
>>
>
>


From rkennke at redhat.com  Thu Jan  8 11:31:59 2015
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 08 Jan 2015 12:31:59 +0100
Subject: [PATCH] Fix Shark build in JDK9
In-Reply-To: <54AE6817.1080206@oracle.com>
References: <1420641903.6838.9.camel@localhost>
	<54AD4C6B.1070702@oracle.com> <1420645301.6838.14.camel@localhost>
	<54AD5675.7010101@oracle.com> <1420647107.6838.15.camel@localhost>
	<54AD5BDF.1060401@oracle.com> <1420648161.6838.17.camel@localhost>
	<54AD639A.2060200@oracle.com> <1420662102.6838.23.camel@localhost>
	<54AE560B.3060200@oracle.com> <1420715146.6838.27.camel@localhost>
	<54AE6817.1080206@oracle.com>
Message-ID: <1420716719.6838.30.camel@localhost>

Am Donnerstag, den 08.01.2015 um 21:20 +1000 schrieb David Holmes:
> On 8/01/2015 9:05 PM, Roman Kennke wrote:
> > Oh and notice that if you try to build it yourself, use a version of
> > LLVM < 3.5. In 3.5, C++11 is used/required, and OpenJDK doesn't support
> > C++11 yet. (are there any plans about this?) I'd recommend LLVM 3.4.2.
> 
> C++11? We still have workarounds for compilers that don't support C99 :(

Well ok, fair enough ;-)

I guess for my purposes it's good enough to pass some GCC flag to turn
on C++11 support, so that the new LLVM headers can be used. That's all
that I need.

Roman

> 
> David
> 
> > Roman
> >
> > Am Donnerstag, den 08.01.2015 um 11:03 +0100 schrieb Erik Joelsson:
> >> Hello Roman,
> >>
> >> This addition looks good to me.
> >>
> >> Thinking about what the others said, it might be inconvenient to have
> >> all this be pushed to different forests. I tried applying all the
> >> changes to jdk9/hs-rt, but I can't seem to build zeroshark.. Did you
> >> have more hotspot changes to be able to finish the build?
> >>
> >> My failure is:
> >>
> >>    ciTypeFlow.o
> >> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/ci/ciTypeFlow.cpp
> >> In file included from
> >> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/regmask.hpp:29:0,
> >>                    from
> >> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/compile.hpp:40,
> >>                    from
> >> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/ci/ciTypeFlow.cpp:38:
> >> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/optoreg.hpp:40:39:
> >> fatal error: adfiles/adGlobals_zero.hpp: No such file or directory
> >>
> >>   From what I can see, adfiles are not generated for zero or zeroshark
> >> builds, so the include should probably be removed.
> >>
> >> Would you still like me to push what you currently have to hs-rt?
> >>
> >> /Erik
> >>
> >> On 2015-01-07 21:21, Roman Kennke wrote:
> >>> Hi Erik,
> >>>
> >>> When I built Zero and Shark on my Raspberry Pi, I noticed another
> >>> problem when copying jvm.cfg into the right places. I fixed it in a
> >>> similar way as I did for the SA stuff:
> >>>
> >>> http://cr.openjdk.java.net/~rkennke/shark-build-jdk/webrev.02/
> >>>
> >>> I think that should be all for now.
> >>>
> >>> Please push that into JDK9 if you think that's fine.
> >>>
> >>> Best regards,
> >>> Roman
> >>>
> >>> Am Mittwoch, den 07.01.2015 um 17:49 +0100 schrieb Erik Joelsson:
> >>>> On 2015-01-07 17:29, Roman Kennke wrote:
> >>>>> Am Mittwoch, den 07.01.2015 um 17:16 +0100 schrieb Erik Joelsson:
> >>>>>> On 2015-01-07 17:11, Roman Kennke wrote:
> >>>>>>> Hi Erik,
> >>>>>>>
> >>>>>>> Do you have a bug for this?
> >>>>>>> No.
> >>>>>>>
> >>>>>>> I haven't pushed any changes to JDK in a while. Is it possible in the
> >>>>>>> meantime for me to create my own bugs? Otherwise, please file one for
> >>>>>>> me :-)
> >>>>>> You should be able to log in to https://bugs.openjdk.java.net and create
> >>>>>> bugs since you have an OpenJDK identity.
> >>>>> Done:
> >>>>>
> >>>>> https://bugs.openjdk.java.net/browse/JDK-8068598
> >>>>>
> >>>>> While I'm at it, is it possible for me to push my own changes (except
> >>>>> hotspot of course)? If yes, what needs to be done for regenerating the
> >>>>> configure files? Simply run autogen.sh in common/autoconf with whatever
> >>>>> version of autotools I have? Or doesn't it make sense at all b/c you
> >>>>> need to regenerate your closed scripts?
> >>>> It requires you to run common/autogen.sh yes, and that will require you
> >>>> to have autoconf 2.69 installed. But since we also need to regenerate
> >>>> the closed version, I can take care of the push for you. Will do it
> >>>> tomorrow if that's ok?
> >>>>
> >>>> /Erik
> >>>>> Roman
> >>>>>
> >>>
> >>
> >
> >




From aph at redhat.com  Thu Jan  8 11:33:19 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 08 Jan 2015 11:33:19 +0000
Subject: [PATCH] Fix Shark build in JDK9
In-Reply-To: <1420716719.6838.30.camel@localhost>
References: <1420641903.6838.9.camel@localhost>	<54AD4C6B.1070702@oracle.com>
	<1420645301.6838.14.camel@localhost>	<54AD5675.7010101@oracle.com>
	<1420647107.6838.15.camel@localhost>	<54AD5BDF.1060401@oracle.com>
	<1420648161.6838.17.camel@localhost>	<54AD639A.2060200@oracle.com>
	<1420662102.6838.23.camel@localhost>	<54AE560B.3060200@oracle.com>
	<1420715146.6838.27.camel@localhost>	<54AE6817.1080206@oracle.com>
	<1420716719.6838.30.camel@localhost>
Message-ID: <54AE6AFF.4020209@redhat.com>

On 01/08/2015 11:31 AM, Roman Kennke wrote:
> I guess for my purposes it's good enough to pass some GCC flag to turn
> on C++11 support, so that the new LLVM headers can be used. That's all
> that I need.

But does that work without further changes?

Andrew.



From erik.joelsson at oracle.com  Thu Jan  8 11:38:54 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 08 Jan 2015 12:38:54 +0100
Subject: [PATCH] Fix Shark build in JDK9
In-Reply-To: <1420714881.6838.25.camel@localhost>
References: <1420641903.6838.9.camel@localhost>					
	<54AD4C6B.1070702@oracle.com>
	<1420645301.6838.14.camel@localhost>				
	<54AD5675.7010101@oracle.com>
	<1420647107.6838.15.camel@localhost>			
	<54AD5BDF.1060401@oracle.com>
	<1420648161.6838.17.camel@localhost>		
	<54AD639A.2060200@oracle.com> <1420662102.6838.23.camel@localhost>	
	<54AE560B.3060200@oracle.com> <1420714881.6838.25.camel@localhost>
Message-ID: <54AE6C4E.9070605@oracle.com>

Hello Roman,

Thanks for the full patch!

I discovered a problem with the top repo patch. When autoconf (using m4) 
evaluates your change, the brackets disappear. To fix this, more 
brackets need to be added. Here is a version that works for me that will 
make the correct sed expression appear in the generated file:

diff -r 7063bdada583 common/autoconf/libraries.m4
--- a/common/autoconf/libraries.m4
+++ b/common/autoconf/libraries.m4
@@ -1080,7 +1080,7 @@
          fi
        fi
      done
-    llvm_version=$("${LLVM_CONFIG}" --version | sed 's/\.//; s/svn.*//')
+    llvm_version=$("${LLVM_CONFIG}" --version | sed [ 
's/\(^[0-9]\)*.\([0-9]*\).*/\1\2/; s/svn.*//' ])
      LLVM_CFLAGS="${LLVM_CFLAGS} -DSHARK_LLVM_VERSION=${llvm_version}"

      unset LLVM_LDFLAGS

I tried building locally (Ubuntu 14.04 with llvm 3.4) but it failed with 
undefined references at link time:

/usr/lib/llvm-3.4/lib/libLLVMSupport.a(Process.o): In function 
`llvm::sys::Process::FileDescriptorHasColors(int)':
(.text+0x5b7): undefined reference to `setupterm'
/usr/lib/llvm-3.4/lib/libLLVMSupport.a(Process.o): In function 
`llvm::sys::Process::FileDescriptorHasColors(int)':
(.text+0x5e0): undefined reference to `tigetnum'
/usr/lib/llvm-3.4/lib/libLLVMSupport.a(Process.o): In function 
`llvm::sys::Process::FileDescriptorHasColors(int)':
(.text+0x5e9): undefined reference to `set_curterm'
/usr/lib/llvm-3.4/lib/libLLVMSupport.a(Process.o): In function 
`llvm::sys::Process::FileDescriptorHasColors(int)':
(.text+0x5f1): undefined reference to `del_curterm'
collect2: error: ld returned 1 exit status

I'm not familiar enough with the hotspot source changes to provide a 
meaningful review, but when it's approved I could still push the whole 
thing.

/Erik

On 2015-01-08 12:01, Roman Kennke wrote:
> Hi Erik,
>
> I'm CC-ing hotspot-dev for review of Hotspot code related changes.
>
> Yes, some additional changes to Hotspot are required. This is the full
> set of changes needed to build and run Shark:
>
> http://cr.openjdk.java.net/~rkennke/shark-build-hotspot/webrev.01/
>
> In detail:
>
> - In the Makefile fix a typo to be able to build unzipped debuginfo.
> - In ciTypeFlow.cpp only include some files and code only when building
> C2. I don't think that code makes sense outside of C2. (That's the issue
> that you've seen).
> - In systemDictionary.cpp, exclude some code for Shark that creates and
> checks native wrappers for method handle intrinsics. Invokedynamic stuff
> is not yet implemented in Shark, so we can't do this.
> - In allocation.hpp, exclude the operator overrides for new etc, LLVM
> does allocations itself, and this would blow up.
> - In handles.hpp and handles.inline.hpp, I added an argument
> check_in_stack so that I can disable the in-stack check for the
> SharkNativeWrapper. The SharkNativeWrapper is allocated on-heap and the
> methodHandle inside the SharkNativeWrapper. I could have excluded that
> check altogther using an #ifndef SHARK, but the way I implemented it
> seemed more finegrained.
> - In SharkCompiler, I pulled out the code to initialize LLVM into its
> own method, and the call to set_state(initialized) out of the
> execution-engine-lock. This would otherwise complain about wrong
> lock-ordering.
> - In SharkRuntime, I changed the cast from intptr_t to oop to work with
> the new picky compilers ;-)
>
> Please review.
>
> Thanks and best regards,
> Roman
>
> Am Donnerstag, den 08.01.2015 um 11:03 +0100 schrieb Erik Joelsson:
>> Hello Roman,
>>
>> This addition looks good to me.
>>
>> Thinking about what the others said, it might be inconvenient to have
>> all this be pushed to different forests. I tried applying all the
>> changes to jdk9/hs-rt, but I can't seem to build zeroshark.. Did you
>> have more hotspot changes to be able to finish the build?
>>
>> My failure is:
>>
>>    ciTypeFlow.o
>> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/ci/ciTypeFlow.cpp
>> In file included from
>> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/regmask.hpp:29:0,
>>                    from
>> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/compile.hpp:40,
>>                    from
>> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/ci/ciTypeFlow.cpp:38:
>> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/optoreg.hpp:40:39:
>> fatal error: adfiles/adGlobals_zero.hpp: No such file or directory
>>
>>   From what I can see, adfiles are not generated for zero or zeroshark
>> builds, so the include should probably be removed.
>>
>> Would you still like me to push what you currently have to hs-rt?
>>
>> /Erik
>>
>> On 2015-01-07 21:21, Roman Kennke wrote:
>>> Hi Erik,
>>>
>>> When I built Zero and Shark on my Raspberry Pi, I noticed another
>>> problem when copying jvm.cfg into the right places. I fixed it in a
>>> similar way as I did for the SA stuff:
>>>
>>> http://cr.openjdk.java.net/~rkennke/shark-build-jdk/webrev.02/
>>>
>>> I think that should be all for now.
>>>
>>> Please push that into JDK9 if you think that's fine.
>>>
>>> Best regards,
>>> Roman
>>>
>>> Am Mittwoch, den 07.01.2015 um 17:49 +0100 schrieb Erik Joelsson:
>>>> On 2015-01-07 17:29, Roman Kennke wrote:
>>>>> Am Mittwoch, den 07.01.2015 um 17:16 +0100 schrieb Erik Joelsson:
>>>>>> On 2015-01-07 17:11, Roman Kennke wrote:
>>>>>>> Hi Erik,
>>>>>>>
>>>>>>> Do you have a bug for this?
>>>>>>> No.
>>>>>>>
>>>>>>> I haven't pushed any changes to JDK in a while. Is it possible in the
>>>>>>> meantime for me to create my own bugs? Otherwise, please file one for
>>>>>>> me :-)
>>>>>> You should be able to log in to https://bugs.openjdk.java.net and create
>>>>>> bugs since you have an OpenJDK identity.
>>>>> Done:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8068598
>>>>>
>>>>> While I'm at it, is it possible for me to push my own changes (except
>>>>> hotspot of course)? If yes, what needs to be done for regenerating the
>>>>> configure files? Simply run autogen.sh in common/autoconf with whatever
>>>>> version of autotools I have? Or doesn't it make sense at all b/c you
>>>>> need to regenerate your closed scripts?
>>>> It requires you to run common/autogen.sh yes, and that will require you
>>>> to have autoconf 2.69 installed. But since we also need to regenerate
>>>> the closed version, I can take care of the push for you. Will do it
>>>> tomorrow if that's ok?
>>>>
>>>> /Erik
>>>>> Roman
>>>>>
>



From aph at redhat.com  Thu Jan  8 11:54:11 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 08 Jan 2015 11:54:11 +0000
Subject: [PATCH] Fix Shark build in JDK9
In-Reply-To: <54AE6C4E.9070605@oracle.com>
References: <1420641903.6838.9.camel@localhost>						<54AD4C6B.1070702@oracle.com>	<1420645301.6838.14.camel@localhost>					<54AD5675.7010101@oracle.com>	<1420647107.6838.15.camel@localhost>				<54AD5BDF.1060401@oracle.com>	<1420648161.6838.17.camel@localhost>			<54AD639A.2060200@oracle.com>
	<1420662102.6838.23.camel@localhost>		<54AE560B.3060200@oracle.com>
	<1420714881.6838.25.camel@localhost> <54AE6C4E.9070605@oracle.com>
Message-ID: <54AE6FE3.5090504@redhat.com>

On 01/08/2015 11:38 AM, Erik Joelsson wrote:
> Hello Roman,
> 
> Thanks for the full patch!
> 
> I discovered a problem with the top repo patch. When autoconf (using m4) 
> evaluates your change, the brackets disappear. To fix this, more 
> brackets need to be added. Here is a version that works for me that will 
> make the correct sed expression appear in the generated file:
> 
> diff -r 7063bdada583 common/autoconf/libraries.m4
> --- a/common/autoconf/libraries.m4
> +++ b/common/autoconf/libraries.m4
> @@ -1080,7 +1080,7 @@
>           fi
>         fi
>       done
> -    llvm_version=$("${LLVM_CONFIG}" --version | sed 's/\.//; s/svn.*//')
> +    llvm_version=$("${LLVM_CONFIG}" --version | sed [ 
> 's/\(^[0-9]\)*.\([0-9]*\).*/\1\2/; s/svn.*//' ])
>       LLVM_CFLAGS="${LLVM_CFLAGS} -DSHARK_LLVM_VERSION=${llvm_version}"
> 
>       unset LLVM_LDFLAGS
> 
> I tried building locally (Ubuntu 14.04 with llvm 3.4) but it failed with 
> undefined references at link time:
> 
> /usr/lib/llvm-3.4/lib/libLLVMSupport.a(Process.o): In function 
> `llvm::sys::Process::FileDescriptorHasColors(int)':
> (.text+0x5b7): undefined reference to `setupterm'
> /usr/lib/llvm-3.4/lib/libLLVMSupport.a(Process.o): In function 
> `llvm::sys::Process::FileDescriptorHasColors(int)':
> (.text+0x5e0): undefined reference to `tigetnum'
> /usr/lib/llvm-3.4/lib/libLLVMSupport.a(Process.o): In function 
> `llvm::sys::Process::FileDescriptorHasColors(int)':
> (.text+0x5e9): undefined reference to `set_curterm'
> /usr/lib/llvm-3.4/lib/libLLVMSupport.a(Process.o): In function 
> `llvm::sys::Process::FileDescriptorHasColors(int)':
> (.text+0x5f1): undefined reference to `del_curterm'
> collect2: error: ld returned 1 exit status

That should be in the ncurses-devel package (or whatever it's called on
Ubuntu) which I thought was an OpenJDK requirement anyway.  Maybe the
only problem is that we're not linking with -lncurses.

Andrew.




From james.laskey at oracle.com  Thu Jan  8 13:13:36 2015
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Thu, 8 Jan 2015 09:13:36 -0400
Subject: RFR 8068650: https://bugs.openjdk.java.net/browse/JDK-8068650
In-Reply-To: <54AE2920.7080107@oracle.com>
References: <54AE2920.7080107@oracle.com>
Message-ID: <3B353EDE-997A-4CC7-92E7-C85DE7EABB27@oracle.com>

+1

On Jan 8, 2015, at 2:52 AM, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:

> Hi,
> 
> Please review http://cr.openjdk.java.net/~sundar/8068650/ for https://bugs.openjdk.java.net/browse/JDK-8068650
> 
> This issue was caused by another makefile fix to generate docs for nashorn. I'm cc'ing nashorn-dev and jdk8u-dev as the fix has to be in jdk8u release(s). jdk9 has proper makefile changes (jdk8u only issue).
> 
> Thanks,
> -Sundar



From erik.joelsson at oracle.com  Thu Jan  8 13:35:32 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 08 Jan 2015 14:35:32 +0100
Subject: [PATCH] Fix Shark build in JDK9
In-Reply-To: <54AE6FE3.5090504@redhat.com>
References: <1420641903.6838.9.camel@localhost>						<54AD4C6B.1070702@oracle.com>	<1420645301.6838.14.camel@localhost>					<54AD5675.7010101@oracle.com>	<1420647107.6838.15.camel@localhost>				<54AD5BDF.1060401@oracle.com>	<1420648161.6838.17.camel@localhost>			<54AD639A.2060200@oracle.com>
	<1420662102.6838.23.camel@localhost>		<54AE560B.3060200@oracle.com>
	<1420714881.6838.25.camel@localhost>
	<54AE6C4E.9070605@oracle.com> <54AE6FE3.5090504@redhat.com>
Message-ID: <54AE87A4.1060703@oracle.com>

On 2015-01-08 12:54, Andrew Haley wrote:
> On 01/08/2015 11:38 AM, Erik Joelsson wrote:
>> I tried building locally (Ubuntu 14.04 with llvm 3.4) but it failed with
>> undefined references at link time:
>>
>> /usr/lib/llvm-3.4/lib/libLLVMSupport.a(Process.o): In function
>> `llvm::sys::Process::FileDescriptorHasColors(int)':
>> (.text+0x5b7): undefined reference to `setupterm'
>> /usr/lib/llvm-3.4/lib/libLLVMSupport.a(Process.o): In function
>> `llvm::sys::Process::FileDescriptorHasColors(int)':
>> (.text+0x5e0): undefined reference to `tigetnum'
>> /usr/lib/llvm-3.4/lib/libLLVMSupport.a(Process.o): In function
>> `llvm::sys::Process::FileDescriptorHasColors(int)':
>> (.text+0x5e9): undefined reference to `set_curterm'
>> /usr/lib/llvm-3.4/lib/libLLVMSupport.a(Process.o): In function
>> `llvm::sys::Process::FileDescriptorHasColors(int)':
>> (.text+0x5f1): undefined reference to `del_curterm'
>> collect2: error: ld returned 1 exit status
> That should be in the ncurses-devel package (or whatever it's called on
> Ubuntu) which I thought was an OpenJDK requirement anyway.  Maybe the
> only problem is that we're not linking with -lncurses.
On my machine, "llvm-config --ldflags" outputs:
-L/usr/lib/llvm-3.4/lib  -lpthread -lffi -ltinfo -ldl -lm

But configure filters only -L arguments into LLVM_LDFLAGS. The rest of 
the -l flags above are already present on the libjvm link line, but 
before $(LLVM_LIBS). If I explicitly add -ltinfo last on the link line 
(after LLVM_LIBS), my build succeeds.

/Erik


From erik.joelsson at oracle.com  Thu Jan  8 14:30:47 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 08 Jan 2015 15:30:47 +0100
Subject: RFR 8068650: https://bugs.openjdk.java.net/browse/JDK-8068650
In-Reply-To: <54AE2920.7080107@oracle.com>
References: <54AE2920.7080107@oracle.com>
Message-ID: <54AE9497.2090006@oracle.com>

Looks good to me.

/Erik

On 2015-01-08 07:52, A. Sundararajan wrote:
> Hi,
>
> Please review http://cr.openjdk.java.net/~sundar/8068650/ for 
> https://bugs.openjdk.java.net/browse/JDK-8068650
>
> This issue was caused by another makefile fix to generate docs for 
> nashorn. I'm cc'ing nashorn-dev and jdk8u-dev as the fix has to be in 
> jdk8u release(s). jdk9 has proper makefile changes (jdk8u only issue).
>
> Thanks,
> -Sundar



From erik.joelsson at oracle.com  Thu Jan  8 14:55:41 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 08 Jan 2015 15:55:41 +0100
Subject: RFR: JDK-8042707: Source changes needed to build JDK 9 with Visual
	Studio 2013 (VS2013)
Message-ID: <54AE9A6D.2030101@oracle.com>

Hello,

Please review this patch, which adds support for building with different 
versions of Visual Studio and in particular adds support for VS2013. In 
order to control which version to use, I've introduced a new configure 
parameter "--with-toolchain-version". On windows, this parameter will 
have the valid values 2010, 2012 and 2013. The default is still 2010. 
Note that 2012 was added for convenience, but has not been tested to 
actually work. The longer term goal is to switch the official compiler 
used for JDK 9 to VS2013. This is just the first step.

The main difference that needed to be addressed was that _STATIC_CPPLIB 
is no longer supported since VS2012, so we will now have to bundle 
another runtime dll (MSVCP). Also, since the build needs to be 
compatible with multiple versions of VS, we can no longer hard code the 
name msvcr100.dll. I changed the names of the dlls into macros that get 
added to the preprocessor command line. Note that the implementation for 
msvcp*.dll in java_md.c could perhaps be more elegant. I'm not familiar 
enough with the APIs, but if someone would like to improve on it, please do.

Bug: https://bugs.openjdk.java.net/browse/JDK-8042707
Webrevs:
http://cr.openjdk.java.net/~erikj/8042707/webrev.root.01/
http://cr.openjdk.java.net/~erikj/8042707/webrev.jdk.01/

Here is a patch for make/jprt.properties that adds new build and test 
platforms using the new compilers for windows and macosx. If you apply 
this and run JPRT, windows and mac platforms will be built and tested 
with both the old and the new compilers. I would like to commit this 
change too, but will do it separately later.

diff -r ef5c7075496d make/jprt.properties
--- a/make/jprt.properties
+++ b/make/jprt.properties
@@ -115,6 +115,12 @@
      ${my.i586.default.build.configure.args}                \
      ${jprt.productOpen.build.configure.args}

+jprt.windows_i586_6.2.build.configure.args= \
+ --with-toolchain-version=2013 \
+    ${jprt.i586.build.configure.args}
+jprt.windows_x64_6.2.build.configure.args= \
+    --with-toolchain-version=2013
+
  ########
  #
  # Build targets and options (default/jdk)
@@ -130,8 +136,11 @@
      linux_i586_2.6-{product|fastdebug},                    \
      linux_x64_2.6-{product|fastdebug},                    \
      macosx_x64_10.7-{product|fastdebug},                \
-    windows_i586_6.1-{product|fastdebug},                \
-    windows_x64_6.1-{product|fastdebug}
+    macosx_x64_10.9-{product|fastdebug},                \
+    windows_i586_6.1-{product|fastdebug},                         \
+ windows_x64_6.1-{product|fastdebug}, \
+ windows_i586_6.2-{product|fastdebug}, \
+    windows_x64_6.2-{product|fastdebug}

  # Test target list (no fastdebug & limited c2 testing)
  my.test.target.set=                            \
@@ -140,8 +149,11 @@
      linux_i586_2.6-product-{c1|c2}-TESTNAME,                \
      linux_x64_2.6-product-c2-TESTNAME,                    \
      macosx_x64_10.7-product-c2-TESTNAME,                \
+    macosx_x64_10.9-product-c2-TESTNAME,                \
      windows_i586_6.1-product-c1-TESTNAME,                \
-    windows_x64_6.1-product-c2-TESTNAME
+    windows_x64_6.1-product-c2-TESTNAME,                \
+    windows_i586_6.2-product-c1-TESTNAME,                \
+    windows_x64_6.2-product-c2-TESTNAME

  # Default vm test targets (testset=default)
  my.test.targets.default=                        \

/Erik


From david.dehaven at oracle.com  Wed Jan  7 03:36:26 2015
From: david.dehaven at oracle.com (David DeHaven)
Date: Tue, 6 Jan 2015 19:36:26 -0800
Subject: Building openjdk 8 on Mac OS X
In-Reply-To: <CC591DCC-287A-4481-9672-E1B7CBADFEAF@oracle.com>
References: <322D21DC-A8EC-4054-9B29-5EB6B8DB8754@gmail.com>	<78ABBB16-75D7-4F95-9364-0996FAAA7E22@oracle.com>	<A8ECBB8A-556D-4E4C-A677-31E2415B4216@gmail.com>
	<loom.20150105T084754-902@post.gmane.org>
	<54AABE39.4000909@telegraphics.com.au>
	<CC591DCC-287A-4481-9672-E1B7CBADFEAF@oracle.com>
Message-ID: <464DCFF1-0E3B-4716-BFB8-CEE59CE52E46@oracle.com>


>> Yes, I just found this out the hard way yesterday (and many other patches are required too).
>> 
>> Is there any chance OS X fixes can make it upstream?
> 
> This basically requires backporting JDK-8043340 to jdk8u, which I've been poking at here and there but have not had the time to really tackle it.

I started looking into this a bit, since I find myself needing to build 8u and cannot switch back to a 10.7 system to do so...

The hotspot and jdk patches are pretty close to 1:1, only a few minor differences. The base patch is completely different due to the lack of --with-sysroot and --with-toolchain* options that are now in JDK 9. Thankfully I did all this before the massive shuffle last summer. I think I'll simplify this to rely on --with-tools-dir, if specified it will set the necessary flags to build from an SDK based on that path (using the xcodebuild tool to find SDKs). This should be fairly foolproof and not add too much to the build process, though you will need Xcode 4.5+ installed since we can only build JDK 8 with gcc.

So far I have "make images" working, but have some other things to fix before I can submit a patch set.

-DrD-



From david.holmes at oracle.com  Fri Jan  9 05:27:21 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 09 Jan 2015 15:27:21 +1000
Subject: [PATCH] Fix Shark build in JDK9
In-Reply-To: <1420714881.6838.25.camel@localhost>
References: <1420641903.6838.9.camel@localhost>	<54AD4C6B.1070702@oracle.com>
	<1420645301.6838.14.camel@localhost>	<54AD5675.7010101@oracle.com>
	<1420647107.6838.15.camel@localhost>	<54AD5BDF.1060401@oracle.com>
	<1420648161.6838.17.camel@localhost>	<54AD639A.2060200@oracle.com>
	<1420662102.6838.23.camel@localhost>	<54AE560B.3060200@oracle.com>
	<1420714881.6838.25.camel@localhost>
Message-ID: <54AF66B9.8060900@oracle.com>

Hi Roman,

Commenting on the hotspot changes ...

On 8/01/2015 9:01 PM, Roman Kennke wrote:
> Hi Erik,
>
> I'm CC-ing hotspot-dev for review of Hotspot code related changes.
>
> Yes, some additional changes to Hotspot are required. This is the full
> set of changes needed to build and run Shark:
>
> http://cr.openjdk.java.net/~rkennke/shark-build-hotspot/webrev.01/
>
> In detail:
>
> - In the Makefile fix a typo to be able to build unzipped debuginfo.

Ok.

> - In ciTypeFlow.cpp only include some files and code only when building
> C2. I don't think that code makes sense outside of C2. (That's the issue
> that you've seen).

Looks okay but someone from compiler team needs to comment. There may be 
other code that need adjusting.

> - In systemDictionary.cpp, exclude some code for Shark that creates and
> checks native wrappers for method handle intrinsics. Invokedynamic stuff
> is not yet implemented in Shark, so we can't do this.

Ok.

> - In allocation.hpp, exclude the operator overrides for new etc, LLVM
> does allocations itself, and this would blow up.

I'm intrigued as the allocation strategy is not tied to the compiler but 
pervasive to the whole VM runtime.

> - In handles.hpp and handles.inline.hpp, I added an argument
> check_in_stack so that I can disable the in-stack check for the
> SharkNativeWrapper. The SharkNativeWrapper is allocated on-heap and the
> methodHandle inside the SharkNativeWrapper. I could have excluded that
> check altogther using an #ifndef SHARK, but the way I implemented it
> seemed more finegrained.

I'd prefer an ifndef SHARK rather than change the API.

Thanks,
David

> - In SharkCompiler, I pulled out the code to initialize LLVM into its
> own method, and the call to set_state(initialized) out of the
> execution-engine-lock. This would otherwise complain about wrong
> lock-ordering.
> - In SharkRuntime, I changed the cast from intptr_t to oop to work with
> the new picky compilers ;-)
>
> Please review.
>
> Thanks and best regards,
> Roman
>
> Am Donnerstag, den 08.01.2015 um 11:03 +0100 schrieb Erik Joelsson:
>> Hello Roman,
>>
>> This addition looks good to me.
>>
>> Thinking about what the others said, it might be inconvenient to have
>> all this be pushed to different forests. I tried applying all the
>> changes to jdk9/hs-rt, but I can't seem to build zeroshark.. Did you
>> have more hotspot changes to be able to finish the build?
>>
>> My failure is:
>>
>>    ciTypeFlow.o
>> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/ci/ciTypeFlow.cpp
>> In file included from
>> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/regmask.hpp:29:0,
>>                    from
>> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/compile.hpp:40,
>>                    from
>> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/ci/ciTypeFlow.cpp:38:
>> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/optoreg.hpp:40:39:
>> fatal error: adfiles/adGlobals_zero.hpp: No such file or directory
>>
>>   From what I can see, adfiles are not generated for zero or zeroshark
>> builds, so the include should probably be removed.
>>
>> Would you still like me to push what you currently have to hs-rt?
>>
>> /Erik
>>
>> On 2015-01-07 21:21, Roman Kennke wrote:
>>> Hi Erik,
>>>
>>> When I built Zero and Shark on my Raspberry Pi, I noticed another
>>> problem when copying jvm.cfg into the right places. I fixed it in a
>>> similar way as I did for the SA stuff:
>>>
>>> http://cr.openjdk.java.net/~rkennke/shark-build-jdk/webrev.02/
>>>
>>> I think that should be all for now.
>>>
>>> Please push that into JDK9 if you think that's fine.
>>>
>>> Best regards,
>>> Roman
>>>
>>> Am Mittwoch, den 07.01.2015 um 17:49 +0100 schrieb Erik Joelsson:
>>>> On 2015-01-07 17:29, Roman Kennke wrote:
>>>>> Am Mittwoch, den 07.01.2015 um 17:16 +0100 schrieb Erik Joelsson:
>>>>>> On 2015-01-07 17:11, Roman Kennke wrote:
>>>>>>> Hi Erik,
>>>>>>>
>>>>>>> Do you have a bug for this?
>>>>>>> No.
>>>>>>>
>>>>>>> I haven't pushed any changes to JDK in a while. Is it possible in the
>>>>>>> meantime for me to create my own bugs? Otherwise, please file one for
>>>>>>> me :-)
>>>>>> You should be able to log in to https://bugs.openjdk.java.net and create
>>>>>> bugs since you have an OpenJDK identity.
>>>>> Done:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8068598
>>>>>
>>>>> While I'm at it, is it possible for me to push my own changes (except
>>>>> hotspot of course)? If yes, what needs to be done for regenerating the
>>>>> configure files? Simply run autogen.sh in common/autoconf with whatever
>>>>> version of autotools I have? Or doesn't it make sense at all b/c you
>>>>> need to regenerate your closed scripts?
>>>> It requires you to run common/autogen.sh yes, and that will require you
>>>> to have autoconf 2.69 installed. But since we also need to regenerate
>>>> the closed version, I can take care of the push for you. Will do it
>>>> tomorrow if that's ok?
>>>>
>>>> /Erik
>>>>> Roman
>>>>>
>>>
>>
>
>


From ingemar.aberg at oracle.com  Fri Jan  9 12:24:52 2015
From: ingemar.aberg at oracle.com (Ingemar Aberg)
Date: Fri, 09 Jan 2015 13:24:52 +0100
Subject: RFR: JDK-8067759 Test bundles
Message-ID: <54AFC894.2050107@oracle.com>

The ability to build (when applicable) and bundle the tests that are in 
the JDK source code at the same time as the product is built is needed. 
(JDK-8067759)

This change provides basic infra structure for creating a test image and 
bundling it in the same manner as other images/bundles

No tests are added to the image/bundle by this change. Tests can be 
added by creating a rule that puts them in the $(TEST_IMAGE_DIR) and 
having the 'test-image' make  target depend on it.

Bug: https://bugs.openjdk.java.net/browse/JDK-8067759
WebRev: http://cr.openjdk.java.net/~ehelin/ingo/8067759/webrev.01/


From erik.joelsson at oracle.com  Fri Jan  9 13:06:14 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 09 Jan 2015 14:06:14 +0100
Subject: RFR: JDK-8067759 Test bundles
In-Reply-To: <54AFC894.2050107@oracle.com>
References: <54AFC894.2050107@oracle.com>
Message-ID: <54AFD246.1080800@oracle.com>

Looks good to me.

/Erik

On 2015-01-09 13:24, Ingemar Aberg wrote:
> The ability to build (when applicable) and bundle the tests that are 
> in the JDK source code at the same time as the product is built is 
> needed. (JDK-8067759)
>
> This change provides basic infra structure for creating a test image 
> and bundling it in the same manner as other images/bundles
>
> No tests are added to the image/bundle by this change. Tests can be 
> added by creating a rule that puts them in the $(TEST_IMAGE_DIR) and 
> having the 'test-image' make  target depend on it.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8067759
> WebRev: http://cr.openjdk.java.net/~ehelin/ingo/8067759/webrev.01/



From magnus.ihse.bursie at oracle.com  Fri Jan  9 13:21:37 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 09 Jan 2015 14:21:37 +0100
Subject: RFR: JDK-8067759 Test bundles
In-Reply-To: <54AFC894.2050107@oracle.com>
References: <54AFC894.2050107@oracle.com>
Message-ID: <54AFD5E1.5030208@oracle.com>

On 2015-01-09 13:24, Ingemar Aberg wrote:
> The ability to build (when applicable) and bundle the tests that are 
> in the JDK source code at the same time as the product is built is 
> needed. (JDK-8067759)
>
> This change provides basic infra structure for creating a test image 
> and bundling it in the same manner as other images/bundles
>
> No tests are added to the image/bundle by this change. Tests can be 
> added by creating a rule that puts them in the $(TEST_IMAGE_DIR) and 
> having the 'test-image' make  target depend on it.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8067759
> WebRev: http://cr.openjdk.java.net/~ehelin/ingo/8067759/webrev.01/

Looks good to me.

/Magnus


From erik.joelsson at oracle.com  Fri Jan  9 14:34:52 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 09 Jan 2015 15:34:52 +0100
Subject: RFR: JDK-8067479: verify-modules fails in bootcycle build
Message-ID: <54AFE70C.3070208@oracle.com>

Hello,

Please review this patch which fixes the verify-modules target when 
running bootcycle build, and also reenables verify-modules when running 
"make images".

There were two problems:

* The bootcycle build configuration was broken so that both the normal 
and the bootcycle build used the same HOTSPOT_DIST directory. The 
consequence of this was that verify-modules worked when run on its own, 
but not if bootcycle-images had been run before. This is fixed in 
bootcycle-spec.gmk.in.

* Since javac in JDK 9 no longer emits classes for implicitly compiled 
sources, certain classes in sa-jdi.jar were not compiled during the 
bootcycle build. I fixed this by adding the missing classes to sa.files. 
Not having the classes there might have been intentional (in at least 
some cases), but since they were compiled anyway, I felt it safer to 
just add them to the list to fix this issue. If these classes shouldn't 
be included, then they need to be properly removed in a followup fix.

Bug: https://bugs.openjdk.java.net/browse/JDK-8067479
Webrev: http://cr.openjdk.java.net/~erikj/8067479/webrev.01/

Since this is changing hotspot, I assume it will need to go in through a 
hotspot forest. Which one?

/Erik


From magnus.ihse.bursie at oracle.com  Fri Jan  9 14:45:33 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 09 Jan 2015 15:45:33 +0100
Subject: RFR: JDK-8042707: Source changes needed to build JDK 9 with Visual
	Studio 2013 (VS2013)
In-Reply-To: <54AE9A6D.2030101@oracle.com>
References: <54AE9A6D.2030101@oracle.com>
Message-ID: <54AFE98D.3070105@oracle.com>

On 2015-01-08 15:55, Erik Joelsson wrote:
> Hello,
>
> Please review this patch, which adds support for building with 
> different versions of Visual Studio and in particular adds support for 
> VS2013. In order to control which version to use, I've introduced a 
> new configure parameter "--with-toolchain-version". On windows, this 
> parameter will have the valid values 2010, 2012 and 2013. The default 
> is still 2010. Note that 2012 was added for convenience, but has not 
> been tested to actually work. The longer term goal is to switch the 
> official compiler used for JDK 9 to VS2013. This is just the first step.
>
> The main difference that needed to be addressed was that 
> _STATIC_CPPLIB is no longer supported since VS2012, so we will now 
> have to bundle another runtime dll (MSVCP). Also, since the build 
> needs to be compatible with multiple versions of VS, we can no longer 
> hard code the name msvcr100.dll. I changed the names of the dlls into 
> macros that get added to the preprocessor command line. Note that the 
> implementation for msvcp*.dll in java_md.c could perhaps be more 
> elegant. I'm not familiar enough with the APIs, but if someone would 
> like to improve on it, please do.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8042707
> Webrevs:
> http://cr.openjdk.java.net/~erikj/8042707/webrev.root.01/
> http://cr.openjdk.java.net/~erikj/8042707/webrev.jdk.01/

It looks basically good to me. Some remarks on toolchain_windows.m4, though.

In TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT:
# TODO: improve detection for other versions of VS

This seems to be done now, so perhaps this can be removed :)
---
Why is "vs_version" lowercase? It might be better to have local 
variables in lower case (or not, I'm not sure we are consistent on 
this?) but this breaks with the rest of the variables in the function 
and looks strange, like it was intentionally signalling something. (This 
goes for the vs_version in the other functions as well.)
---
# Work around the insanely named ProgramFiles(x86) env variable
PROGRAMFILES_X86="`env | $SED -n 's/^ProgramFiles(x86)=//p'`"

Yay! :-) I spent some time going crazy about that one before I gave up. 
Never thought of that solution.
---
# FIXME will just assume default Visual Studio version
if test "x$with_tools_dir" != x; then
TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT([$with_tools_dir/../..],

This seems broken. Have you tested it? You have to pass a version as the 
first argument to TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT, yes? I 
think we need to examine an explicitely given toolchain to have it's 
version determined. Otherwise, the msvcr/msvcp handling code will not 
function correctly. I suggest that we first check if 
--with-toolchain-version is set and if so, respect it. Otherwise, check 
the path given for the known names (VS_VS_INSTALLDIR_*), and if none 
matches, abort and complain that version must be specified.

Hm, actually, maybe the entire block of testing with_tools_dir should be 
lifted up into TOOLCHAIN_FIND_VISUAL_STUDIO and handled separately..? It 
doesn't really fit into TOOLCHAIN_FIND_VISUAL_STUDIO_BAT_FILE anyhow.

/Magnus



From erik.joelsson at oracle.com  Fri Jan  9 15:04:16 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 09 Jan 2015 16:04:16 +0100
Subject: RFR: JDK-8068726: Tab completion of targets fails when current dir
	is the output dir
Message-ID: <54AFEDF0.8080505@oracle.com>

Hello,

Please review this minor fix. Tab completion stopped working when 
running make from the output dir (which I often do). I found that this 
fixed the problem:

diff -r ef5c7075496d Makefile
--- a/Makefile
+++ b/Makefile
@@ -54,8 +54,11 @@
    # Duplication of global targets, needed before ParseConfAndSpec in 
case we have
    # no configurations.
    help:
-  # If CONF is not set, look for all available configurations
-  CONF?=
+  # If both CONF and SPEC are unset, look for all available 
configurations by
+  # setting CONF to the empty string.
+  ifeq ($(SPEC), )
+    CONF?=
+  endif
  endif

Bug: https://bugs.openjdk.java.net/browse/JDK-8068726

/Erik


From magnus.ihse.bursie at oracle.com  Fri Jan  9 15:24:46 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 09 Jan 2015 16:24:46 +0100
Subject: RFR: JDK-8067479: verify-modules fails in bootcycle build
In-Reply-To: <54AFE70C.3070208@oracle.com>
References: <54AFE70C.3070208@oracle.com>
Message-ID: <54AFF2BE.5050700@oracle.com>

On 2015-01-09 15:34, Erik Joelsson wrote:
> Hello,
>
> Please review this patch which fixes the verify-modules target when 
> running bootcycle build, and also reenables verify-modules when 
> running "make images".
>
> There were two problems:
>
> * The bootcycle build configuration was broken so that both the normal 
> and the bootcycle build used the same HOTSPOT_DIST directory. The 
> consequence of this was that verify-modules worked when run on its 
> own, but not if bootcycle-images had been run before. This is fixed in 
> bootcycle-spec.gmk.in.
>
> * Since javac in JDK 9 no longer emits classes for implicitly compiled 
> sources, certain classes in sa-jdi.jar were not compiled during the 
> bootcycle build. I fixed this by adding the missing classes to 
> sa.files. Not having the classes there might have been intentional (in 
> at least some cases), but since they were compiled anyway, I felt it 
> safer to just add them to the list to fix this issue. If these classes 
> shouldn't be included, then they need to be properly removed in a 
> followup fix.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8067479
> Webrev: http://cr.openjdk.java.net/~erikj/8067479/webrev.01/
>
> Since this is changing hotspot, I assume it will need to go in through 
> a hotspot forest. Which one?

Top level build changes look good to me. Can't say anything about the SA 
stuff.

/Magnus


From magnus.ihse.bursie at oracle.com  Fri Jan  9 15:27:00 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 09 Jan 2015 16:27:00 +0100
Subject: RFR: JDK-8068726: Tab completion of targets fails when current
	dir is the output dir
In-Reply-To: <54AFEDF0.8080505@oracle.com>
References: <54AFEDF0.8080505@oracle.com>
Message-ID: <54AFF344.8080109@oracle.com>

On 2015-01-09 16:04, Erik Joelsson wrote:
> Hello,
>
> Please review this minor fix. Tab completion stopped working when 
> running make from the output dir (which I often do). I found that this 
> fixed the problem:
>
> diff -r ef5c7075496d Makefile
> --- a/Makefile
> +++ b/Makefile
> @@ -54,8 +54,11 @@
>    # Duplication of global targets, needed before ParseConfAndSpec in 
> case we have
>    # no configurations.
>    help:
> -  # If CONF is not set, look for all available configurations
> -  CONF?=
> +  # If both CONF and SPEC are unset, look for all available 
> configurations by
> +  # setting CONF to the empty string.
> +  ifeq ($(SPEC), )
> +    CONF?=
> +  endif
>  endif
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8068726

Looks good to me. Thanks for fixing this on your own and not pestering 
me for breaking it. ;-)

/Magnus


From magnus.ihse.bursie at oracle.com  Fri Jan  9 15:41:05 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 09 Jan 2015 16:41:05 +0100
Subject: RFR: JDK-8068735 Configure fails on Windows if Visual Studio
	$LIB/$INCLUDE is lower case
Message-ID: <54AFF691.1020805@oracle.com>

When detecting the Visual Studio environment, we check for the variables 
$LIB and $INCLUDE. However, on Windows, environment variables are not 
case sensitive.

Most of the time, these are named $LIB and $INCLUDE, but sometimes they 
are named $lib and $include instead. Currently, we fail if this is the case.

I made a simple fix to cover this case. Ideally, we'd like to have 
proper, full support of case insensitivity. Unfortunately, that is hard 
to fix and the current lines are the result of much blood and tears. I'm 
not very much inclined to try to "improve" them.

Bug: https://bugs.openjdk.java.net/browse/JDK-8068735
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8068735-support-lowercase-vs-env/webrev.01

/Magnus


From erik.joelsson at oracle.com  Fri Jan  9 15:44:50 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 09 Jan 2015 16:44:50 +0100
Subject: RFR: JDK-8068735 Configure fails on Windows if Visual Studio
	$LIB/$INCLUDE is lower case
In-Reply-To: <54AFF691.1020805@oracle.com>
References: <54AFF691.1020805@oracle.com>
Message-ID: <54AFF772.5080000@oracle.com>

Looks ok to me.

/Erik

On 2015-01-09 16:41, Magnus Ihse Bursie wrote:
> When detecting the Visual Studio environment, we check for the 
> variables $LIB and $INCLUDE. However, on Windows, environment 
> variables are not case sensitive.
>
> Most of the time, these are named $LIB and $INCLUDE, but sometimes 
> they are named $lib and $include instead. Currently, we fail if this 
> is the case.
>
> I made a simple fix to cover this case. Ideally, we'd like to have 
> proper, full support of case insensitivity. Unfortunately, that is 
> hard to fix and the current lines are the result of much blood and 
> tears. I'm not very much inclined to try to "improve" them.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8068735
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8068735-support-lowercase-vs-env/webrev.01
>
> /Magnus



From magnus.ihse.bursie at oracle.com  Fri Jan  9 15:49:50 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 09 Jan 2015 16:49:50 +0100
Subject: RFR: JDK-8067060: build can still fail with spaces following
	-L on link lines
In-Reply-To: <54882EF0.9090603@oracle.com>
References: <54882EF0.9090603@oracle.com>
Message-ID: <54AFF89E.4080001@oracle.com>

On 2014-12-10 12:30, Erik Joelsson wrote:
> Hello,
>
> Embarrassingly enough, my last fix for the -L and space problem wasn't 
> correct. Here is a new fix where I'm reverting the macro definitions 
> from using define to simple = assignment. The latter automatically 
> strips leading whitespace and IMO fits better for the type of macro 
> that should not be called with $(eval ). (See bug for more detailed 
> explanation).
>
> This time I made sure to grep the build log on a mac for '-L ' to make 
> sure I didn't miss anything.
>
> Stuart: could you make sure this patch works since I can't repro the 
> actual failure?
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8067060
> Webrev: http://cr.openjdk.java.net/~erikj/8067060/webrev.jdk.01/

Looks good to me.

I prefer the "define" style for macros since it's more clear (at least 
to me :)) that it's a macro and not just a simple definition, but I 
agree that when it breaks otherwise, as it would in this case, the = 
assignment is useful.

/Magnus


From david.dehaven at oracle.com  Fri Jan  9 16:00:50 2015
From: david.dehaven at oracle.com (David DeHaven)
Date: Fri, 9 Jan 2015 08:00:50 -0800
Subject: De-universalizing hotspot in jdk8u
Message-ID: <E191CFA4-D089-459E-A74E-E72424EDDA3A@oracle.com>


We have this nice little comment in common/autoconf/jdk-options.m4:
  # On Macosx universal binaries are produced, but they only contain
  # 64 bit intel. This invalidates control of which jvms are built
  # from configure, but only server is valid anyway. Fix this
  # when hotspot makefiles are rewritten.
  if test "x$MACOSX_UNIVERSAL" = xtrue; then
    HOTSPOT_TARGET=universal_${HOTSPOT_EXPORT}
  fi


So.. I turned it off:
  if test "x$OPENJDK_TARGET_OS" = "xmacosx"; then
#    MACOSX_UNIVERSAL="true"
    MACOSX_UNIVERSAL="false"
  fi

And in hotspot/make/bsd/makefiles/defs.make:
# Universal build settings
ifeq ($(OS_VENDOR), Darwin)
  # Build universal binaries by default on Mac OS X
#  MACOSX_UNIVERSAL = true
  MACOSX_UNIVERSAL = false
  ifneq ($(ALT_MACOSX_UNIVERSAL),)

hotspot still seems to build happily (I'm kicking off tests now). Is there are particular reason this hasn't been done yet? I'd like to know before I pursue this as a means of eliminating our dependency on lipo which is causing an inordinate amount of grief when trying to build on 10.9 and later when Xcode 5+ is coinstalled. I have some logic to work around using the broken /usr/bin/lipo, but it doesn't help later in some "other" build target that ends up using '-arch i386 -arch x86_64'. It does not explicitly run lipo, it relies on gcc to do the fattening itself and so it fails even though I've gone to the effort of working around the broken lipo (and it isn't necessary anyways because it doesn't even build the i386 binaries even though it's supposed to be "universal").


Quite frankly I'd rather just remove all the universal binary stuff from hotspot, but I'm trying my best to minimize the changes there... the "other" problem I can handle easily.

-DrD-



From joe.darcy at oracle.com  Sat Jan 10 00:55:07 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Fri, 09 Jan 2015 16:55:07 -0800
Subject: JDK 9 RFR of JDK-8067099: Add deprecation lint warning to build
	of jdk repository
In-Reply-To: <5487EABD.7060509@oracle.com>
References: <5487A910.9000504@oracle.com> <5487EABD.7060509@oracle.com>
Message-ID: <54B0786B.6040702@oracle.com>

Hello,

Catching up on email after the holidays...


On 12/9/2014 10:39 PM, Erik Joelsson wrote:
> First, congratulations on almost being done fixing all the warnings!
>
> When removing the last warning exception, perhaps it's time to change 
> the comment next to this line too?

A fair point!

How about

--- old/make/common/SetupJavaCompilers.gmk    2015-01-09 
15:26:49.930781479 -0800
+++ new/make/common/SetupJavaCompilers.gmk    2015-01-09 
15:26:49.850781479 -0800
@@ -1,5 +1,5 @@
  #
-# Copyright (c) 2011, 2014, Oracle and/or its affiliates. All rights 
reserved.
+# Copyright (c) 2011, 2015, Oracle and/or its affiliates. All rights 
reserved.
  # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  #
  # This code is free software; you can redistribute it and/or modify it
@@ -30,9 +30,9 @@

  DISABLE_WARNINGS := 
-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally

-# To build with all warnings enabled, do the following:
+# If warnings needs to be non-fatal for testing purposes use a command 
like:
  # make JAVAC_WARNINGS="-Xlint:all -Xmaxwarns 10000"
-JAVAC_WARNINGS := -Xlint:all,-deprecation -Werror
+JAVAC_WARNINGS := -Xlint:all -Werror

  # The BOOT_JAVAC setup uses the boot jdk compiler to compile the tools
  # and the interim javac, to be run by the boot jdk.

(Also viewable at http://cr.openjdk.java.net/~darcy/8067099.0/)

Thanks,

-Joe

>
> /Erik
>
> On 2014-12-10 02:59, joe darcy wrote:
>> Hello,
>>
>> The time approaches when the one remaining category of lint warning 
>> still present in the jdk repo, deprecation, will be eliminated. In 
>> anticipation of that happy day, please review this simple patch to 
>> enable the warning in the build:
>>
>> diff -r f7c11da0b048 make/common/SetupJavaCompilers.gmk
>> --- a/make/common/SetupJavaCompilers.gmk    Thu Dec 04 15:21:09 2014 
>> -0800
>> +++ b/make/common/SetupJavaCompilers.gmk    Tue Dec 09 17:30:32 2014 
>> -0800
>> @@ -32,7 +32,7 @@
>>
>>  # To build with all warnings enabled, do the following:
>>  # make JAVAC_WARNINGS="-Xlint:all -Xmaxwarns 10000"
>> -JAVAC_WARNINGS := -Xlint:all,-deprecation -Werror
>> +JAVAC_WARNINGS := -Xlint:all -Werror
>>
>>  # The BOOT_JAVAC setup uses the boot jdk compiler to compile the tools
>>  # and the interim javac, to be run by the boot jdk.
>>
>> As usual for this kind of change,  a jprt job will be used to verify 
>> the fix is valid on all platforms, etc.
>>
>> Thanks,
>>
>> -Joe
>



From david.dehaven at oracle.com  Sat Jan 10 04:45:32 2015
From: david.dehaven at oracle.com (David DeHaven)
Date: Fri, 9 Jan 2015 20:45:32 -0800
Subject: [8u60] RFR: 8043340: [macosx] Fix hard-wired paths to JavaVM.framework
Message-ID: <39719ED3-1F4E-4E6C-AA9F-A3C4766537B4@oracle.com>


Please review the open source changes for 8043340. The goal here is to get jdk8u to build on Mac OS X 10.9+ systems where Xcode 5+ and Xcode 4 are co-installed, a configuration which is becoming more and more commonplace as more developers are focusing on JDK 9 now (which needs Xcode 5 installed), not to mention new systems ship with 10.10 which only supports the Xcode 5/6 command line tools. It's too much of a hassle to maintain separate systems for building jdk8u and JPRT isn't suitable for frequent changes so something must be done to address this.

The jdk changes are similar to those done for JDK9, though I removed the changes for building with Xcode 5 (JDK-8043591) since we do not support building JDK 8 with clang.

The hotspot changes are almost identical, the lack of SYSROOT_CFLAGS necessitated changing the logic in saproc.make a bit. It still builds with or without spec.gmk, though without it you will either need to define SDKPATH or have a sane Xcode 4 installation.

For the top level build system:
- most of the logic of sanitizing the Xcode build environment is in toolchain.m4
- the LIPO variable was removed since it was completely unused
- OTOOL was moved to after the Xcode sanitizing so it can be picked up from DEVELOPER_DIR if needed
- MACOSX_UNIVERSAL is now being set to false by default and ALT_MACOSX_UNIVERSAL was added to hotspot-spec.gmk.in so the hotspot build is in sync with the jdk build (this was a bug, IMHO)

That last change removed any need to run lipo (only done in hotspot), so the fact that /usr/bin/lipo is broken with Xcode 4 is a non-issue.

There is a weird case where some early versions of the Xcode 5 command line tools installed /usr/bin/{gcc|g++} as a symlink to {clang|clang++}, that case is handled by putting $DEVELOPER_DIR/usr/bin on the path so autoconf picks up the actual gcc executable.

JBS Issue:
https://bugs.openjdk.java.net/browse/JDK-8043340

Webrevs:
http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/top
http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/hotspot
http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/jdk

JPRT runs are being kicked off. I'll have one run from hotspot directly. I'll post results here.

-DrD-



From david.holmes at oracle.com  Sun Jan 11 23:02:22 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 12 Jan 2015 09:02:22 +1000
Subject: De-universalizing hotspot in jdk8u
In-Reply-To: <E191CFA4-D089-459E-A74E-E72424EDDA3A@oracle.com>
References: <E191CFA4-D089-459E-A74E-E72424EDDA3A@oracle.com>
Message-ID: <54B300FE.2000804@oracle.com>

Hi David,

On 10/01/2015 2:00 AM, David DeHaven wrote:
>
> We have this nice little comment in common/autoconf/jdk-options.m4:
>    # On Macosx universal binaries are produced, but they only contain
>    # 64 bit intel. This invalidates control of which jvms are built
>    # from configure, but only server is valid anyway. Fix this
>    # when hotspot makefiles are rewritten.
>    if test "x$MACOSX_UNIVERSAL" = xtrue; then
>      HOTSPOT_TARGET=universal_${HOTSPOT_EXPORT}
>    fi
>
>
> So.. I turned it off:
>    if test "x$OPENJDK_TARGET_OS" = "xmacosx"; then
> #    MACOSX_UNIVERSAL="true"
>      MACOSX_UNIVERSAL="false"
>    fi
>
> And in hotspot/make/bsd/makefiles/defs.make:
> # Universal build settings
> ifeq ($(OS_VENDOR), Darwin)
>    # Build universal binaries by default on Mac OS X
> #  MACOSX_UNIVERSAL = true
>    MACOSX_UNIVERSAL = false
>    ifneq ($(ALT_MACOSX_UNIVERSAL),)
>
> hotspot still seems to build happily (I'm kicking off tests now). Is there are particular reason this hasn't been done yet? I'd like to know before I pursue this as a means of eliminating our dependency on lipo which is causing an inordinate amount of grief when trying to build on 10.9 and later when Xcode 5+ is coinstalled. I have some logic to work around using the broken /usr/bin/lipo, but it doesn't help later in some "other" build target that ends up using '-arch i386 -arch x86_64'. It does not explicitly run lipo, it relies on gcc to do the fattening itself and so it fails even though I've gone to the effort of working around the broken lipo (and it isn't necessary anyways because it doesn't even build the i386 binaries even though it's supposed to be "universal").

The hotspot makefiles still haven't been rewritten (though Magnus had 
been working on it).

Also I was under the impression that we used the universal stuff because 
we had to deliver in a particular way on OSX. But I don't know the 
details and the people who dealt with the original OSX port effort are 
no longer here.

David H.

>
> Quite frankly I'd rather just remove all the universal binary stuff from hotspot, but I'm trying my best to minimize the changes there... the "other" problem I can handle easily.
>
> -DrD-
>


From david.holmes at oracle.com  Mon Jan 12 02:45:41 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 12 Jan 2015 12:45:41 +1000
Subject: RFR: JDK-8067479: verify-modules fails in bootcycle build
In-Reply-To: <54AFE70C.3070208@oracle.com>
References: <54AFE70C.3070208@oracle.com>
Message-ID: <54B33555.8030206@oracle.com>

Hi Erik,

On 10/01/2015 12:34 AM, Erik Joelsson wrote:
> Hello,
>
> Please review this patch which fixes the verify-modules target when
> running bootcycle build, and also reenables verify-modules when running
> "make images".
>
> There were two problems:
>
> * The bootcycle build configuration was broken so that both the normal
> and the bootcycle build used the same HOTSPOT_DIST directory. The
> consequence of this was that verify-modules worked when run on its own,
> but not if bootcycle-images had been run before. This is fixed in
> bootcycle-spec.gmk.in.
>
> * Since javac in JDK 9 no longer emits classes for implicitly compiled
> sources, certain classes in sa-jdi.jar were not compiled during the
> bootcycle build. I fixed this by adding the missing classes to sa.files.
> Not having the classes there might have been intentional (in at least
> some cases), but since they were compiled anyway, I felt it safer to
> just add them to the list to fix this issue. If these classes shouldn't
> be included, then they need to be properly removed in a followup fix.

SA is owned by serviceability - cc'd. Changes seem okay as a solution to 
immediate problem, but I don't think anyone expects the IA64 stuff to 
still be needed. It is on the todo list to eradicate IA64 IIRC.

Looks like there is limited awareness of the need to keep sa.files up to 
date. :(

Thanks,
David

> Bug: https://bugs.openjdk.java.net/browse/JDK-8067479
> Webrev: http://cr.openjdk.java.net/~erikj/8067479/webrev.01/
>
> Since this is changing hotspot, I assume it will need to go in through a
> hotspot forest. Which one?
>
> /Erik


From dean.long at oracle.com  Mon Jan 12 04:31:28 2015
From: dean.long at oracle.com (Dean Long)
Date: Sun, 11 Jan 2015 20:31:28 -0800
Subject: RFR: AARCH64: Top-level JDK changes
In-Reply-To: <CA+3eh13Byz2VWW6GA_X00np7DU=-xp7nmA-t1iCygU4EU7FOjA@mail.gmail.com>
References: <545CFFA9.4070107@redhat.com>	<545D0290.5080307@oracle.com>
	<CA+3eh13Byz2VWW6GA_X00np7DU=-xp7nmA-t1iCygU4EU7FOjA@mail.gmail.com>
Message-ID: <54B34E20.5030506@oracle.com>

I found a small problem with the new config.sub wrapper.  It works with 
the bash shell but not with the dash shell.
The problem seems to be with this line:

     result=`. $DIR/autoconf-config.sub $sub_args "$@"`

"dash" doesn't seem to support args passed with ".", so $sub_args "$@" 
are ignored.

dl


From erik.joelsson at oracle.com  Mon Jan 12 10:20:09 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 12 Jan 2015 11:20:09 +0100
Subject: JDK 9 RFR of JDK-8067099: Add deprecation lint warning to build
	of jdk repository
In-Reply-To: <54B0786B.6040702@oracle.com>
References: <5487A910.9000504@oracle.com> <5487EABD.7060509@oracle.com>
	<54B0786B.6040702@oracle.com>
Message-ID: <54B39FD9.3080904@oracle.com>

Looks good to me.

/Erik

On 2015-01-10 01:55, joe darcy wrote:
> Hello,
>
> Catching up on email after the holidays...
>
>
> On 12/9/2014 10:39 PM, Erik Joelsson wrote:
>> First, congratulations on almost being done fixing all the warnings!
>>
>> When removing the last warning exception, perhaps it's time to change 
>> the comment next to this line too?
>
> A fair point!
>
> How about
>
> --- old/make/common/SetupJavaCompilers.gmk    2015-01-09 
> 15:26:49.930781479 -0800
> +++ new/make/common/SetupJavaCompilers.gmk    2015-01-09 
> 15:26:49.850781479 -0800
> @@ -1,5 +1,5 @@
>  #
> -# Copyright (c) 2011, 2014, Oracle and/or its affiliates. All rights 
> reserved.
> +# Copyright (c) 2011, 2015, Oracle and/or its affiliates. All rights 
> reserved.
>  # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  #
>  # This code is free software; you can redistribute it and/or modify it
> @@ -30,9 +30,9 @@
>
>  DISABLE_WARNINGS := 
> -Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally
>
> -# To build with all warnings enabled, do the following:
> +# If warnings needs to be non-fatal for testing purposes use a 
> command like:
>  # make JAVAC_WARNINGS="-Xlint:all -Xmaxwarns 10000"
> -JAVAC_WARNINGS := -Xlint:all,-deprecation -Werror
> +JAVAC_WARNINGS := -Xlint:all -Werror
>
>  # The BOOT_JAVAC setup uses the boot jdk compiler to compile the tools
>  # and the interim javac, to be run by the boot jdk.
>
> (Also viewable at http://cr.openjdk.java.net/~darcy/8067099.0/)
>
> Thanks,
>
> -Joe
>
>>
>> /Erik
>>
>> On 2014-12-10 02:59, joe darcy wrote:
>>> Hello,
>>>
>>> The time approaches when the one remaining category of lint warning 
>>> still present in the jdk repo, deprecation, will be eliminated. In 
>>> anticipation of that happy day, please review this simple patch to 
>>> enable the warning in the build:
>>>
>>> diff -r f7c11da0b048 make/common/SetupJavaCompilers.gmk
>>> --- a/make/common/SetupJavaCompilers.gmk    Thu Dec 04 15:21:09 2014 
>>> -0800
>>> +++ b/make/common/SetupJavaCompilers.gmk    Tue Dec 09 17:30:32 2014 
>>> -0800
>>> @@ -32,7 +32,7 @@
>>>
>>>  # To build with all warnings enabled, do the following:
>>>  # make JAVAC_WARNINGS="-Xlint:all -Xmaxwarns 10000"
>>> -JAVAC_WARNINGS := -Xlint:all,-deprecation -Werror
>>> +JAVAC_WARNINGS := -Xlint:all -Werror
>>>
>>>  # The BOOT_JAVAC setup uses the boot jdk compiler to compile the tools
>>>  # and the interim javac, to be run by the boot jdk.
>>>
>>> As usual for this kind of change,  a jprt job will be used to verify 
>>> the fix is valid on all platforms, etc.
>>>
>>> Thanks,
>>>
>>> -Joe
>>
>



From aph at redhat.com  Mon Jan 12 10:25:12 2015
From: aph at redhat.com (Andrew Haley)
Date: Mon, 12 Jan 2015 10:25:12 +0000
Subject: RFR: AARCH64: Top-level JDK changes
In-Reply-To: <54B34E20.5030506@oracle.com>
References: <545CFFA9.4070107@redhat.com>	<545D0290.5080307@oracle.com>	<CA+3eh13Byz2VWW6GA_X00np7DU=-xp7nmA-t1iCygU4EU7FOjA@mail.gmail.com>
	<54B34E20.5030506@oracle.com>
Message-ID: <54B3A108.9070203@redhat.com>

On 12/01/15 04:31, Dean Long wrote:
> I found a small problem with the new config.sub wrapper.  It works with 
> the bash shell but not with the dash shell.
> The problem seems to be with this line:
> 
>      result=`. $DIR/autoconf-config.sub $sub_args "$@"`
> 
> "dash" doesn't seem to support args passed with ".", so $sub_args "$@" 
> are ignored.

Thank you.  Sorry for the breakage; I didn't intend to use any
non-portable shell idioms.  I'm not expert enough to say whether this
is a bug in dash, but I don't suppose that matters: we are where we
are.

There's no reason not to replace the "." with "bash".  Do you want me
to do anything?

Andrew.


From erik.joelsson at oracle.com  Mon Jan 12 10:35:56 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 12 Jan 2015 11:35:56 +0100
Subject: [8u60] RFR: 8043340: [macosx] Fix hard-wired paths to
	JavaVM.framework
In-Reply-To: <39719ED3-1F4E-4E6C-AA9F-A3C4766537B4@oracle.com>
References: <39719ED3-1F4E-4E6C-AA9F-A3C4766537B4@oracle.com>
Message-ID: <54B3A38C.10909@oracle.com>

Hello,

These changes look ok to me.

With these changes, configure will unconditionally fail if trying to use 
XCode 5. I know we don't officially support using XCode 5 for JDK 8, but 
aren't people working around it with some patches? How hard would it be 
to make it at least build?

/Erik

On 2015-01-10 05:45, David DeHaven wrote:
> Please review the open source changes for 8043340. The goal here is to get jdk8u to build on Mac OS X 10.9+ systems where Xcode 5+ and Xcode 4 are co-installed, a configuration which is becoming more and more commonplace as more developers are focusing on JDK 9 now (which needs Xcode 5 installed), not to mention new systems ship with 10.10 which only supports the Xcode 5/6 command line tools. It's too much of a hassle to maintain separate systems for building jdk8u and JPRT isn't suitable for frequent changes so something must be done to address this.
>
> The jdk changes are similar to those done for JDK9, though I removed the changes for building with Xcode 5 (JDK-8043591) since we do not support building JDK 8 with clang.
>
> The hotspot changes are almost identical, the lack of SYSROOT_CFLAGS necessitated changing the logic in saproc.make a bit. It still builds with or without spec.gmk, though without it you will either need to define SDKPATH or have a sane Xcode 4 installation.
>
> For the top level build system:
> - most of the logic of sanitizing the Xcode build environment is in toolchain.m4
> - the LIPO variable was removed since it was completely unused
> - OTOOL was moved to after the Xcode sanitizing so it can be picked up from DEVELOPER_DIR if needed
> - MACOSX_UNIVERSAL is now being set to false by default and ALT_MACOSX_UNIVERSAL was added to hotspot-spec.gmk.in so the hotspot build is in sync with the jdk build (this was a bug, IMHO)
>
> That last change removed any need to run lipo (only done in hotspot), so the fact that /usr/bin/lipo is broken with Xcode 4 is a non-issue.
>
> There is a weird case where some early versions of the Xcode 5 command line tools installed /usr/bin/{gcc|g++} as a symlink to {clang|clang++}, that case is handled by putting $DEVELOPER_DIR/usr/bin on the path so autoconf picks up the actual gcc executable.
>
> JBS Issue:
> https://bugs.openjdk.java.net/browse/JDK-8043340
>
> Webrevs:
> http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/top
> http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/hotspot
> http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/jdk
>
> JPRT runs are being kicked off. I'll have one run from hotspot directly. I'll post results here.
>
> -DrD-
>



From erik.joelsson at oracle.com  Mon Jan 12 10:41:20 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 12 Jan 2015 11:41:20 +0100
Subject: De-universalizing hotspot in jdk8u
In-Reply-To: <54B300FE.2000804@oracle.com>
References: <E191CFA4-D089-459E-A74E-E72424EDDA3A@oracle.com>
	<54B300FE.2000804@oracle.com>
Message-ID: <54B3A4D0.3080604@oracle.com>


On 2015-01-12 00:02, David Holmes wrote:
> Hi David,
>
> On 10/01/2015 2:00 AM, David DeHaven wrote:
>>
>> We have this nice little comment in common/autoconf/jdk-options.m4:
>>    # On Macosx universal binaries are produced, but they only contain
>>    # 64 bit intel. This invalidates control of which jvms are built
>>    # from configure, but only server is valid anyway. Fix this
>>    # when hotspot makefiles are rewritten.
>>    if test "x$MACOSX_UNIVERSAL" = xtrue; then
>>      HOTSPOT_TARGET=universal_${HOTSPOT_EXPORT}
>>    fi
>>
>>
>> So.. I turned it off:
>>    if test "x$OPENJDK_TARGET_OS" = "xmacosx"; then
>> #    MACOSX_UNIVERSAL="true"
>>      MACOSX_UNIVERSAL="false"
>>    fi
>>
>> And in hotspot/make/bsd/makefiles/defs.make:
>> # Universal build settings
>> ifeq ($(OS_VENDOR), Darwin)
>>    # Build universal binaries by default on Mac OS X
>> #  MACOSX_UNIVERSAL = true
>>    MACOSX_UNIVERSAL = false
>>    ifneq ($(ALT_MACOSX_UNIVERSAL),)
>>
>> hotspot still seems to build happily (I'm kicking off tests now). Is 
>> there are particular reason this hasn't been done yet? I'd like to 
>> know before I pursue this as a means of eliminating our dependency on 
>> lipo which is causing an inordinate amount of grief when trying to 
>> build on 10.9 and later when Xcode 5+ is coinstalled. I have some 
>> logic to work around using the broken /usr/bin/lipo, but it doesn't 
>> help later in some "other" build target that ends up using '-arch 
>> i386 -arch x86_64'. It does not explicitly run lipo, it relies on gcc 
>> to do the fattening itself and so it fails even though I've gone to 
>> the effort of working around the broken lipo (and it isn't necessary 
>> anyways because it doesn't even build the i386 binaries even though 
>> it's supposed to be "universal").
>
> The hotspot makefiles still haven't been rewritten (though Magnus had 
> been working on it).
>
> Also I was under the impression that we used the universal stuff 
> because we had to deliver in a particular way on OSX. But I don't know 
> the details and the people who dealt with the original OSX port effort 
> are no longer here.
>
I don't know why Hotspot is packaged as a universal binary. In the jdk, 
only libJObjC was built as a universal binary and that lib was removed 
before JDK 8 shipped. What part of Macosx would need to interact 
directly with libjvm.dylib in a way that required a (fake) universal 
format, but no other libs in the jdk? I would say go ahead and change it.

/Erik

> David H.
>
>>
>> Quite frankly I'd rather just remove all the universal binary stuff 
>> from hotspot, but I'm trying my best to minimize the changes there... 
>> the "other" problem I can handle easily.
>>
>> -DrD-
>>



From david.holmes at oracle.com  Mon Jan 12 11:26:37 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 12 Jan 2015 21:26:37 +1000
Subject: De-universalizing hotspot in jdk8u
In-Reply-To: <54B3A4D0.3080604@oracle.com>
References: <E191CFA4-D089-459E-A74E-E72424EDDA3A@oracle.com>
	<54B300FE.2000804@oracle.com> <54B3A4D0.3080604@oracle.com>
Message-ID: <54B3AF6D.20607@oracle.com>

cc'ing macosx-port-dev and hotspot-dev

On 12/01/2015 8:41 PM, Erik Joelsson wrote:
>
> On 2015-01-12 00:02, David Holmes wrote:
>> Hi David,
>>
>> On 10/01/2015 2:00 AM, David DeHaven wrote:
>>>
>>> We have this nice little comment in common/autoconf/jdk-options.m4:
>>>    # On Macosx universal binaries are produced, but they only contain
>>>    # 64 bit intel. This invalidates control of which jvms are built
>>>    # from configure, but only server is valid anyway. Fix this
>>>    # when hotspot makefiles are rewritten.
>>>    if test "x$MACOSX_UNIVERSAL" = xtrue; then
>>>      HOTSPOT_TARGET=universal_${HOTSPOT_EXPORT}
>>>    fi
>>>
>>>
>>> So.. I turned it off:
>>>    if test "x$OPENJDK_TARGET_OS" = "xmacosx"; then
>>> #    MACOSX_UNIVERSAL="true"
>>>      MACOSX_UNIVERSAL="false"
>>>    fi
>>>
>>> And in hotspot/make/bsd/makefiles/defs.make:
>>> # Universal build settings
>>> ifeq ($(OS_VENDOR), Darwin)
>>>    # Build universal binaries by default on Mac OS X
>>> #  MACOSX_UNIVERSAL = true
>>>    MACOSX_UNIVERSAL = false
>>>    ifneq ($(ALT_MACOSX_UNIVERSAL),)
>>>
>>> hotspot still seems to build happily (I'm kicking off tests now). Is
>>> there are particular reason this hasn't been done yet? I'd like to
>>> know before I pursue this as a means of eliminating our dependency on
>>> lipo which is causing an inordinate amount of grief when trying to
>>> build on 10.9 and later when Xcode 5+ is coinstalled. I have some
>>> logic to work around using the broken /usr/bin/lipo, but it doesn't
>>> help later in some "other" build target that ends up using '-arch
>>> i386 -arch x86_64'. It does not explicitly run lipo, it relies on gcc
>>> to do the fattening itself and so it fails even though I've gone to
>>> the effort of working around the broken lipo (and it isn't necessary
>>> anyways because it doesn't even build the i386 binaries even though
>>> it's supposed to be "universal").
>>
>> The hotspot makefiles still haven't been rewritten (though Magnus had
>> been working on it).
>>
>> Also I was under the impression that we used the universal stuff
>> because we had to deliver in a particular way on OSX. But I don't know
>> the details and the people who dealt with the original OSX port effort
>> are no longer here.
>>
> I don't know why Hotspot is packaged as a universal binary. In the jdk,
> only libJObjC was built as a universal binary and that lib was removed
> before JDK 8 shipped. What part of Macosx would need to interact
> directly with libjvm.dylib in a way that required a (fake) universal
> format, but no other libs in the jdk? I would say go ahead and change it.

In the spirit of "never take down a fence until you know why it was put 
up in the first place" I've cc'd macosx-port-dev to see if there is 
anyone around who recalls why hotspot is using the universal binary feature.

David H.
-------

> /Erik
>
>> David H.
>>
>>>
>>> Quite frankly I'd rather just remove all the universal binary stuff
>>> from hotspot, but I'm trying my best to minimize the changes there...
>>> the "other" problem I can handle easily.
>>>
>>> -DrD-
>>>
>


From tim.bell at oracle.com  Mon Jan 12 11:43:21 2015
From: tim.bell at oracle.com (Tim Bell)
Date: Mon, 12 Jan 2015 03:43:21 -0800
Subject: RFR: JDK-8042707: Source changes needed to build JDK 9 with Visual
	Studio 2013 (VS2013)
In-Reply-To: <54AE9A6D.2030101@oracle.com>
References: <54AE9A6D.2030101@oracle.com>
Message-ID: <54B3B359.208@oracle.com>

Erik:

Looks good to me.  Thanks for picking this up - I struggled with the 
problem for months.

Tim

> Please review this patch, which adds support for building with 
> different versions of Visual Studio and in particular adds support for 
> VS2013. In order to control which version to use, I've introduced a 
> new configure parameter "--with-toolchain-version". On windows, this 
> parameter will have the valid values 2010, 2012 and 2013. The default 
> is still 2010. Note that 2012 was added for convenience, but has not 
> been tested to actually work. The longer term goal is to switch the 
> official compiler used for JDK 9 to VS2013. This is just the first step.
>
> The main difference that needed to be addressed was that 
> _STATIC_CPPLIB is no longer supported since VS2012, so we will now 
> have to bundle another runtime dll (MSVCP). Also, since the build 
> needs to be compatible with multiple versions of VS, we can no longer 
> hard code the name msvcr100.dll. I changed the names of the dlls into 
> macros that get added to the preprocessor command line. Note that the 
> implementation for msvcp*.dll in java_md.c could perhaps be more 
> elegant. I'm not familiar enough with the APIs, but if someone would 
> like to improve on it, please do.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8042707
> Webrevs:
> http://cr.openjdk.java.net/~erikj/8042707/webrev.root.01/
> http://cr.openjdk.java.net/~erikj/8042707/webrev.jdk.01/
>
> Here is a patch for make/jprt.properties that adds new build and test 
> platforms using the new compilers for windows and macosx. If you apply 
> this and run JPRT, windows and mac platforms will be built and tested 
> with both the old and the new compilers. I would like to commit this 
> change too, but will do it separately later.
>
> diff -r ef5c7075496d make/jprt.properties
> --- a/make/jprt.properties
> +++ b/make/jprt.properties
> @@ -115,6 +115,12 @@
>      ${my.i586.default.build.configure.args}                \
>      ${jprt.productOpen.build.configure.args}
>
> +jprt.windows_i586_6.2.build.configure.args= \
> + --with-toolchain-version=2013 \
> +    ${jprt.i586.build.configure.args}
> +jprt.windows_x64_6.2.build.configure.args= \
> +    --with-toolchain-version=2013
> +
>  ########
>  #
>  # Build targets and options (default/jdk)
> @@ -130,8 +136,11 @@
>      linux_i586_2.6-{product|fastdebug},                    \
>      linux_x64_2.6-{product|fastdebug},                    \
>      macosx_x64_10.7-{product|fastdebug},                \
> -    windows_i586_6.1-{product|fastdebug},                \
> -    windows_x64_6.1-{product|fastdebug}
> +    macosx_x64_10.9-{product|fastdebug},                \
> +    windows_i586_6.1-{product|fastdebug},                         \
> + windows_x64_6.1-{product|fastdebug}, \
> + windows_i586_6.2-{product|fastdebug}, \
> +    windows_x64_6.2-{product|fastdebug}
>
>  # Test target list (no fastdebug & limited c2 testing)
>  my.test.target.set=                            \
> @@ -140,8 +149,11 @@
>      linux_i586_2.6-product-{c1|c2}-TESTNAME,                \
>      linux_x64_2.6-product-c2-TESTNAME,                    \
>      macosx_x64_10.7-product-c2-TESTNAME,                \
> +    macosx_x64_10.9-product-c2-TESTNAME,                \
>      windows_i586_6.1-product-c1-TESTNAME,                \
> -    windows_x64_6.1-product-c2-TESTNAME
> +    windows_x64_6.1-product-c2-TESTNAME,                \
> +    windows_i586_6.2-product-c1-TESTNAME,                \
> +    windows_x64_6.2-product-c2-TESTNAME
>
>  # Default vm test targets (testset=default)
>  my.test.targets.default=                        \
>
> /Erik



From magnus.ihse.bursie at oracle.com  Mon Jan 12 11:49:34 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 12 Jan 2015 12:49:34 +0100
Subject: RFR: AARCH64: Top-level JDK changes
In-Reply-To: <54B34E20.5030506@oracle.com>
References: <545CFFA9.4070107@redhat.com>	<545D0290.5080307@oracle.com>	<CA+3eh13Byz2VWW6GA_X00np7DU=-xp7nmA-t1iCygU4EU7FOjA@mail.gmail.com>
	<54B34E20.5030506@oracle.com>
Message-ID: <54B3B4CE.8060804@oracle.com>

On 2015-01-12 05:31, Dean Long wrote:
> I found a small problem with the new config.sub wrapper.  It works 
> with the bash shell but not with the dash shell.
> The problem seems to be with this line:
>
>     result=`. $DIR/autoconf-config.sub $sub_args "$@"`
>
> "dash" doesn't seem to support args passed with ".", so $sub_args "$@" 
> are ignored.

bash is the required shell for running configure. We do not support 
non-bash shells. In fact, we go to lengths to try to ensure that we are 
indeed running under bash.

/Magnus


From hannes.wallnoefer at oracle.com  Thu Jan  8 13:16:13 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Thu, 08 Jan 2015 14:16:13 +0100
Subject: RFR 8068650: https://bugs.openjdk.java.net/browse/JDK-8068650
In-Reply-To: <54AE2920.7080107@oracle.com>
References: <54AE2920.7080107@oracle.com>
Message-ID: <54AE831D.8090305@oracle.com>

+1

Am 2015-01-08 um 07:52 schrieb A. Sundararajan:
> Hi,
>
> Please review http://cr.openjdk.java.net/~sundar/8068650/ for 
> https://bugs.openjdk.java.net/browse/JDK-8068650
>
> This issue was caused by another makefile fix to generate docs for 
> nashorn. I'm cc'ing nashorn-dev and jdk8u-dev as the fix has to be in 
> jdk8u release(s). jdk9 has proper makefile changes (jdk8u only issue).
>
> Thanks,
> -Sundar



From david.dehaven at oracle.com  Mon Jan 12 15:17:30 2015
From: david.dehaven at oracle.com (David DeHaven)
Date: Mon, 12 Jan 2015 07:17:30 -0800
Subject: De-universalizing hotspot in jdk8u
In-Reply-To: <54B3AF6D.20607@oracle.com>
References: <E191CFA4-D089-459E-A74E-E72424EDDA3A@oracle.com>
	<54B300FE.2000804@oracle.com> <54B3A4D0.3080604@oracle.com>
	<54B3AF6D.20607@oracle.com>
Message-ID: <825EBFC2-6DE1-4550-842B-217C06532C9B@oracle.com>


>>>> We have this nice little comment in common/autoconf/jdk-options.m4:
>>>>   # On Macosx universal binaries are produced, but they only contain
>>>>   # 64 bit intel. This invalidates control of which jvms are built
>>>>   # from configure, but only server is valid anyway. Fix this
>>>>   # when hotspot makefiles are rewritten.
>>>>   if test "x$MACOSX_UNIVERSAL" = xtrue; then
>>>>     HOTSPOT_TARGET=universal_${HOTSPOT_EXPORT}
>>>>   fi
>>>> 
>>>> 
>>>> So.. I turned it off:
>>>>   if test "x$OPENJDK_TARGET_OS" = "xmacosx"; then
>>>> #    MACOSX_UNIVERSAL="true"
>>>>     MACOSX_UNIVERSAL="false"
>>>>   fi
>>>> 
>>>> And in hotspot/make/bsd/makefiles/defs.make:
>>>> # Universal build settings
>>>> ifeq ($(OS_VENDOR), Darwin)
>>>>   # Build universal binaries by default on Mac OS X
>>>> #  MACOSX_UNIVERSAL = true
>>>>   MACOSX_UNIVERSAL = false
>>>>   ifneq ($(ALT_MACOSX_UNIVERSAL),)
>>>> 
>>>> hotspot still seems to build happily (I'm kicking off tests now). Is
>>>> there are particular reason this hasn't been done yet? I'd like to
>>>> know before I pursue this as a means of eliminating our dependency on
>>>> lipo which is causing an inordinate amount of grief when trying to
>>>> build on 10.9 and later when Xcode 5+ is coinstalled. I have some
>>>> logic to work around using the broken /usr/bin/lipo, but it doesn't
>>>> help later in some "other" build target that ends up using '-arch
>>>> i386 -arch x86_64'. It does not explicitly run lipo, it relies on gcc
>>>> to do the fattening itself and so it fails even though I've gone to
>>>> the effort of working around the broken lipo (and it isn't necessary
>>>> anyways because it doesn't even build the i386 binaries even though
>>>> it's supposed to be "universal").
>>> 
>>> The hotspot makefiles still haven't been rewritten (though Magnus had
>>> been working on it).
>>> 
>>> Also I was under the impression that we used the universal stuff
>>> because we had to deliver in a particular way on OSX. But I don't know
>>> the details and the people who dealt with the original OSX port effort
>>> are no longer here.
>>> 
>> I don't know why Hotspot is packaged as a universal binary. In the jdk,
>> only libJObjC was built as a universal binary and that lib was removed
>> before JDK 8 shipped. What part of Macosx would need to interact
>> directly with libjvm.dylib in a way that required a (fake) universal
>> format, but no other libs in the jdk? I would say go ahead and change it.
> 
> In the spirit of "never take down a fence until you know why it was put up in the first place" I've cc'd macosx-port-dev to see if there is anyone around who recalls why hotspot is using the universal binary feature.

I hear you.

My best guess is we'd initially planned on supporting 32 bit but (???) and the easiest way to deliver is in a universal binary. Note that we don't actually deliver universal binaries as the JVM is 64 bit only, or at least there are not nearly enough components there to run a full 32 bit JVM.

-DrD-



From david.dehaven at oracle.com  Mon Jan 12 15:28:34 2015
From: david.dehaven at oracle.com (David DeHaven)
Date: Mon, 12 Jan 2015 07:28:34 -0800
Subject: [8u60] RFR: 8043340: [macosx] Fix hard-wired paths to
	JavaVM.framework
In-Reply-To: <54B3A38C.10909@oracle.com>
References: <39719ED3-1F4E-4E6C-AA9F-A3C4766537B4@oracle.com>
	<54B3A38C.10909@oracle.com>
Message-ID: <8B01B84D-5B6F-478E-ABF1-33F5ADE2F826@oracle.com>


It won't build at all with Xcode 5, there is no gcc compiler and the clang changes were never backported to jdk8u.

-DrD-

> Hello,
> 
> These changes look ok to me.
> 
> With these changes, configure will unconditionally fail if trying to use XCode 5. I know we don't officially support using XCode 5 for JDK 8, but aren't people working around it with some patches? How hard would it be to make it at least build?
> 
> /Erik
> 
> On 2015-01-10 05:45, David DeHaven wrote:
>> Please review the open source changes for 8043340. The goal here is to get jdk8u to build on Mac OS X 10.9+ systems where Xcode 5+ and Xcode 4 are co-installed, a configuration which is becoming more and more commonplace as more developers are focusing on JDK 9 now (which needs Xcode 5 installed), not to mention new systems ship with 10.10 which only supports the Xcode 5/6 command line tools. It's too much of a hassle to maintain separate systems for building jdk8u and JPRT isn't suitable for frequent changes so something must be done to address this.
>> 
>> The jdk changes are similar to those done for JDK9, though I removed the changes for building with Xcode 5 (JDK-8043591) since we do not support building JDK 8 with clang.
>> 
>> The hotspot changes are almost identical, the lack of SYSROOT_CFLAGS necessitated changing the logic in saproc.make a bit. It still builds with or without spec.gmk, though without it you will either need to define SDKPATH or have a sane Xcode 4 installation.
>> 
>> For the top level build system:
>> - most of the logic of sanitizing the Xcode build environment is in toolchain.m4
>> - the LIPO variable was removed since it was completely unused
>> - OTOOL was moved to after the Xcode sanitizing so it can be picked up from DEVELOPER_DIR if needed
>> - MACOSX_UNIVERSAL is now being set to false by default and ALT_MACOSX_UNIVERSAL was added to hotspot-spec.gmk.in so the hotspot build is in sync with the jdk build (this was a bug, IMHO)
>> 
>> That last change removed any need to run lipo (only done in hotspot), so the fact that /usr/bin/lipo is broken with Xcode 4 is a non-issue.
>> 
>> There is a weird case where some early versions of the Xcode 5 command line tools installed /usr/bin/{gcc|g++} as a symlink to {clang|clang++}, that case is handled by putting $DEVELOPER_DIR/usr/bin on the path so autoconf picks up the actual gcc executable.
>> 
>> JBS Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8043340
>> 
>> Webrevs:
>> http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/top
>> http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/hotspot
>> http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/jdk
>> 
>> JPRT runs are being kicked off. I'll have one run from hotspot directly. I'll post results here.
>> 
>> -DrD-
>> 
> 



From david.dehaven at oracle.com  Mon Jan 12 16:25:21 2015
From: david.dehaven at oracle.com (David DeHaven)
Date: Mon, 12 Jan 2015 08:25:21 -0800
Subject: [8u60] RFR: 8043340: [macosx] Fix hard-wired paths to
	JavaVM.framework
In-Reply-To: <8B01B84D-5B6F-478E-ABF1-33F5ADE2F826@oracle.com>
References: <39719ED3-1F4E-4E6C-AA9F-A3C4766537B4@oracle.com>
	<54B3A38C.10909@oracle.com>
	<8B01B84D-5B6F-478E-ABF1-33F5ADE2F826@oracle.com>
Message-ID: <08C63261-D594-404E-892B-BDE2898B505A@oracle.com>


Or rather, the point of this exercise is to eliminate the hacks to get it to build with Xcode 5 (I'm not sure if anyone was truly successful with that). It's far better to just build with Xcode 4.6.3, and with these changes you don't even need to pre-sanitize your Xcode environment.

A proper build setup would have Xcode 5 or 6 installed in /Applications/Xcode.app (generally MAS managed) and Xcode 4.6.3 (still available for download on ADC) somewhere NOT directly in /Applications (the Mac App Store has a nasty habit of "upgrading" it when it sees it there). I keep mine in /Applications/old along with a copy of Xcode 5.1.1 for test purposes.

The --with-xcode-path argument is optional, you should also be able to build with Xcode 4 selected via "sudo xcode-select -switch /path/to/Xcode4.app". I leave MAS managed Xcode (currently 6) active as I'm constantly bouncing between projects and it's a hassle to have to remember to reset the active toolchain, so I thought it best to allow configure to be provided a path.


I'm kind of bummed I didn't get to show my really nasty hack for working around the broken lipo stub tool, it was so horrible it could be considered artwork! :)

-DrD-

> It won't build at all with Xcode 5, there is no gcc compiler and the clang changes were never backported to jdk8u.
> 
> -DrD-
> 
>> Hello,
>> 
>> These changes look ok to me.
>> 
>> With these changes, configure will unconditionally fail if trying to use XCode 5. I know we don't officially support using XCode 5 for JDK 8, but aren't people working around it with some patches? How hard would it be to make it at least build?
>> 
>> /Erik
>> 
>> On 2015-01-10 05:45, David DeHaven wrote:
>>> Please review the open source changes for 8043340. The goal here is to get jdk8u to build on Mac OS X 10.9+ systems where Xcode 5+ and Xcode 4 are co-installed, a configuration which is becoming more and more commonplace as more developers are focusing on JDK 9 now (which needs Xcode 5 installed), not to mention new systems ship with 10.10 which only supports the Xcode 5/6 command line tools. It's too much of a hassle to maintain separate systems for building jdk8u and JPRT isn't suitable for frequent changes so something must be done to address this.
>>> 
>>> The jdk changes are similar to those done for JDK9, though I removed the changes for building with Xcode 5 (JDK-8043591) since we do not support building JDK 8 with clang.
>>> 
>>> The hotspot changes are almost identical, the lack of SYSROOT_CFLAGS necessitated changing the logic in saproc.make a bit. It still builds with or without spec.gmk, though without it you will either need to define SDKPATH or have a sane Xcode 4 installation.
>>> 
>>> For the top level build system:
>>> - most of the logic of sanitizing the Xcode build environment is in toolchain.m4
>>> - the LIPO variable was removed since it was completely unused
>>> - OTOOL was moved to after the Xcode sanitizing so it can be picked up from DEVELOPER_DIR if needed
>>> - MACOSX_UNIVERSAL is now being set to false by default and ALT_MACOSX_UNIVERSAL was added to hotspot-spec.gmk.in so the hotspot build is in sync with the jdk build (this was a bug, IMHO)
>>> 
>>> That last change removed any need to run lipo (only done in hotspot), so the fact that /usr/bin/lipo is broken with Xcode 4 is a non-issue.
>>> 
>>> There is a weird case where some early versions of the Xcode 5 command line tools installed /usr/bin/{gcc|g++} as a symlink to {clang|clang++}, that case is handled by putting $DEVELOPER_DIR/usr/bin on the path so autoconf picks up the actual gcc executable.
>>> 
>>> JBS Issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8043340
>>> 
>>> Webrevs:
>>> http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/top
>>> http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/hotspot
>>> http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/jdk
>>> 
>>> JPRT runs are being kicked off. I'll have one run from hotspot directly. I'll post results here.
>>> 
>>> -DrD-
>>> 
>> 
> 



From erik.joelsson at oracle.com  Mon Jan 12 16:30:08 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 12 Jan 2015 17:30:08 +0100
Subject: [8u60] RFR: 8043340: [macosx] Fix hard-wired paths to
	JavaVM.framework
In-Reply-To: <08C63261-D594-404E-892B-BDE2898B505A@oracle.com>
References: <39719ED3-1F4E-4E6C-AA9F-A3C4766537B4@oracle.com>
	<54B3A38C.10909@oracle.com>
	<8B01B84D-5B6F-478E-ABF1-33F5ADE2F826@oracle.com>
	<08C63261-D594-404E-892B-BDE2898B505A@oracle.com>
Message-ID: <54B3F690.5090309@oracle.com>

I'm happy with that answer. Thanks!

/Erik

On 2015-01-12 17:25, David DeHaven wrote:
> Or rather, the point of this exercise is to eliminate the hacks to get it to build with Xcode 5 (I'm not sure if anyone was truly successful with that). It's far better to just build with Xcode 4.6.3, and with these changes you don't even need to pre-sanitize your Xcode environment.
>
> A proper build setup would have Xcode 5 or 6 installed in /Applications/Xcode.app (generally MAS managed) and Xcode 4.6.3 (still available for download on ADC) somewhere NOT directly in /Applications (the Mac App Store has a nasty habit of "upgrading" it when it sees it there). I keep mine in /Applications/old along with a copy of Xcode 5.1.1 for test purposes.
>
> The --with-xcode-path argument is optional, you should also be able to build with Xcode 4 selected via "sudo xcode-select -switch /path/to/Xcode4.app". I leave MAS managed Xcode (currently 6) active as I'm constantly bouncing between projects and it's a hassle to have to remember to reset the active toolchain, so I thought it best to allow configure to be provided a path.
>
>
> I'm kind of bummed I didn't get to show my really nasty hack for working around the broken lipo stub tool, it was so horrible it could be considered artwork! :)
>
> -DrD-
>
>> It won't build at all with Xcode 5, there is no gcc compiler and the clang changes were never backported to jdk8u.
>>
>> -DrD-
>>
>>> Hello,
>>>
>>> These changes look ok to me.
>>>
>>> With these changes, configure will unconditionally fail if trying to use XCode 5. I know we don't officially support using XCode 5 for JDK 8, but aren't people working around it with some patches? How hard would it be to make it at least build?
>>>
>>> /Erik
>>>
>>> On 2015-01-10 05:45, David DeHaven wrote:
>>>> Please review the open source changes for 8043340. The goal here is to get jdk8u to build on Mac OS X 10.9+ systems where Xcode 5+ and Xcode 4 are co-installed, a configuration which is becoming more and more commonplace as more developers are focusing on JDK 9 now (which needs Xcode 5 installed), not to mention new systems ship with 10.10 which only supports the Xcode 5/6 command line tools. It's too much of a hassle to maintain separate systems for building jdk8u and JPRT isn't suitable for frequent changes so something must be done to address this.
>>>>
>>>> The jdk changes are similar to those done for JDK9, though I removed the changes for building with Xcode 5 (JDK-8043591) since we do not support building JDK 8 with clang.
>>>>
>>>> The hotspot changes are almost identical, the lack of SYSROOT_CFLAGS necessitated changing the logic in saproc.make a bit. It still builds with or without spec.gmk, though without it you will either need to define SDKPATH or have a sane Xcode 4 installation.
>>>>
>>>> For the top level build system:
>>>> - most of the logic of sanitizing the Xcode build environment is in toolchain.m4
>>>> - the LIPO variable was removed since it was completely unused
>>>> - OTOOL was moved to after the Xcode sanitizing so it can be picked up from DEVELOPER_DIR if needed
>>>> - MACOSX_UNIVERSAL is now being set to false by default and ALT_MACOSX_UNIVERSAL was added to hotspot-spec.gmk.in so the hotspot build is in sync with the jdk build (this was a bug, IMHO)
>>>>
>>>> That last change removed any need to run lipo (only done in hotspot), so the fact that /usr/bin/lipo is broken with Xcode 4 is a non-issue.
>>>>
>>>> There is a weird case where some early versions of the Xcode 5 command line tools installed /usr/bin/{gcc|g++} as a symlink to {clang|clang++}, that case is handled by putting $DEVELOPER_DIR/usr/bin on the path so autoconf picks up the actual gcc executable.
>>>>
>>>> JBS Issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8043340
>>>>
>>>> Webrevs:
>>>> http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/top
>>>> http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/hotspot
>>>> http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/jdk
>>>>
>>>> JPRT runs are being kicked off. I'll have one run from hotspot directly. I'll post results here.
>>>>
>>>> -DrD-
>>>>



From david.dehaven at oracle.com  Mon Jan 12 17:05:28 2015
From: david.dehaven at oracle.com (David DeHaven)
Date: Mon, 12 Jan 2015 09:05:28 -0800
Subject: [8u60] RFR: 8043340: [macosx] Fix hard-wired paths to
	JavaVM.framework
In-Reply-To: <08C63261-D594-404E-892B-BDE2898B505A@oracle.com>
References: <39719ED3-1F4E-4E6C-AA9F-A3C4766537B4@oracle.com>
	<54B3A38C.10909@oracle.com>
	<8B01B84D-5B6F-478E-ABF1-33F5ADE2F826@oracle.com>
	<08C63261-D594-404E-892B-BDE2898B505A@oracle.com>
Message-ID: <D4150E19-D909-4AA9-AD43-E00DA084D015@oracle.com>


> The --with-xcode-path argument is optional, you should also be able to build with Xcode 4 selected via "sudo xcode-select -switch /path/to/Xcode4.app". I leave MAS managed Xcode (currently 6) active as I'm constantly bouncing between projects and it's a hassle to have to remember to reset the active toolchain, so I thought it best to allow configure to be provided a path.

Ugh. I broke something along the way, this doesn't *quite* work.

xcrun complains with "xcrun: error: missing DEVELOPER_DIR path:"

I think I'm exporting an empty DEVELOPER_DIR. I shall fix and update.

-DrD-



From naoto.sato at oracle.com  Mon Jan 12 17:08:22 2015
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 12 Jan 2015 09:08:22 -0800
Subject: Fix currency-related build failure starting 12/31/2014
In-Reply-To: <54A31613.4000905@ezchip.com>
References: <54A31613.4000905@ezchip.com>
Message-ID: <54B3FF86.4000901@oracle.com>

Hi Chris,

Thank you for reporting this problem. We are aware of this issue and 
will be fixed in the next update release.

Naoto

On 12/30/14, 1:16 PM, Chris Metcalf wrote:
> Our JDK 1.6 and 1.7 builds began failing today with the message "Error:
> time is more than 10 years from present: 1104530400000".  At midnight
> Turkish time on Dec 31, 2004, the new Turkish lira (TRY) replaced the
> old lira (TRL) at 1,000,000:1.  You may note that this was exactly 10
> years ago today.
>
> Some enterprising long-ago coder included a sanity test that all
> currency conversions happen within 10 years of the current moment, but
> clearly they must have meant "no more than 10 years into the future".
> To correct this, I remove the Math.abs() from the code in question.
>
> I admit to not being familiar with the bug submission and patch
> submission process for OpenJDK, but hopefully as a trivial fix there is
> no issue with copyright assignment or other technicalities.  I just
> submit this in hope that it avoids more folks wasting their time on this
> issue.
>
> ---
> openjdk/jdk/make/tools/src/build/tools/generatecurrencydata/GenerateCurrencyData.java
> 2014-12-30 20:49:40.000000000 -0500
> +++
> openjdk/jdk/make/tools/src/build/tools/generatecurrencydata/GenerateCurrencyData.java
> 2014-12-30 20:49:40.000000000 -0500
> @@ -281,7 +281,7 @@
>               checkCurrencyCode(newCurrency);
>               String timeString = currencyInfo.substring(4, length - 4);
>               long time = format.parse(timeString).getTime();
> -            if (Math.abs(time - System.currentTimeMillis()) > ((long)
> 10) * 365 * 24 * 60 * 60 * 1000) {
> +            if (time - System.currentTimeMillis() > ((long) 10) * 365 *
> 24 * 60 * 60 * 1000) {
>                   throw new RuntimeException("time is more than 10 years
> from present: " + time);
>               }
>               specialCaseCutOverTimes[specialCaseCount] = time;
>


From daniel.daugherty at oracle.com  Mon Jan 12 18:54:55 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 12 Jan 2015 11:54:55 -0700
Subject: De-universalizing hotspot in jdk8u
In-Reply-To: <825EBFC2-6DE1-4550-842B-217C06532C9B@oracle.com>
References: <E191CFA4-D089-459E-A74E-E72424EDDA3A@oracle.com>
	<54B300FE.2000804@oracle.com> <54B3A4D0.3080604@oracle.com>
	<54B3AF6D.20607@oracle.com>
	<825EBFC2-6DE1-4550-842B-217C06532C9B@oracle.com>
Message-ID: <54B4187F.5060608@oracle.com>

On 1/12/15 8:17 AM, David DeHaven wrote:
>>>>> We have this nice little comment in common/autoconf/jdk-options.m4:
>>>>>    # On Macosx universal binaries are produced, but they only contain
>>>>>    # 64 bit intel. This invalidates control of which jvms are built
>>>>>    # from configure, but only server is valid anyway. Fix this
>>>>>    # when hotspot makefiles are rewritten.
>>>>>    if test "x$MACOSX_UNIVERSAL" = xtrue; then
>>>>>      HOTSPOT_TARGET=universal_${HOTSPOT_EXPORT}
>>>>>    fi
>>>>>
>>>>>
>>>>> So.. I turned it off:
>>>>>    if test "x$OPENJDK_TARGET_OS" = "xmacosx"; then
>>>>> #    MACOSX_UNIVERSAL="true"
>>>>>      MACOSX_UNIVERSAL="false"
>>>>>    fi
>>>>>
>>>>> And in hotspot/make/bsd/makefiles/defs.make:
>>>>> # Universal build settings
>>>>> ifeq ($(OS_VENDOR), Darwin)
>>>>>    # Build universal binaries by default on Mac OS X
>>>>> #  MACOSX_UNIVERSAL = true
>>>>>    MACOSX_UNIVERSAL = false
>>>>>    ifneq ($(ALT_MACOSX_UNIVERSAL),)
>>>>>
>>>>> hotspot still seems to build happily (I'm kicking off tests now). Is
>>>>> there are particular reason this hasn't been done yet? I'd like to
>>>>> know before I pursue this as a means of eliminating our dependency on
>>>>> lipo which is causing an inordinate amount of grief when trying to
>>>>> build on 10.9 and later when Xcode 5+ is coinstalled. I have some
>>>>> logic to work around using the broken /usr/bin/lipo, but it doesn't
>>>>> help later in some "other" build target that ends up using '-arch
>>>>> i386 -arch x86_64'. It does not explicitly run lipo, it relies on gcc
>>>>> to do the fattening itself and so it fails even though I've gone to
>>>>> the effort of working around the broken lipo (and it isn't necessary
>>>>> anyways because it doesn't even build the i386 binaries even though
>>>>> it's supposed to be "universal").
>>>> The hotspot makefiles still haven't been rewritten (though Magnus had
>>>> been working on it).
>>>>
>>>> Also I was under the impression that we used the universal stuff
>>>> because we had to deliver in a particular way on OSX. But I don't know
>>>> the details and the people who dealt with the original OSX port effort
>>>> are no longer here.
>>>>
>>> I don't know why Hotspot is packaged as a universal binary. In the jdk,
>>> only libJObjC was built as a universal binary and that lib was removed
>>> before JDK 8 shipped. What part of Macosx would need to interact
>>> directly with libjvm.dylib in a way that required a (fake) universal
>>> format, but no other libs in the jdk? I would say go ahead and change it.
>> In the spirit of "never take down a fence until you know why it was put up in the first place" I've cc'd macosx-port-dev to see if there is anyone around who recalls why hotspot is using the universal binary feature.
> I hear you.
>
> My best guess is we'd initially planned on supporting 32 bit but (???) and the easiest way to deliver is in a universal binary. Note that we don't actually deliver universal binaries as the JVM is 64 bit only, or at least there are not nearly enough components there to run a full 32 bit JVM.
>
> -DrD-

We (Jim Melvin did the work) included universal support in HotSpot
to not preclude someone else from doing the 32-bit MacOS X port and
providing it via OpenJDK channels. The rest of the JDK did not
include universal support, but the hotspot code would have served
as an example way forward...

However, we never heard from anyone willing to do the 32-bit port...

Dan



From david.dehaven at oracle.com  Mon Jan 12 19:06:30 2015
From: david.dehaven at oracle.com (David DeHaven)
Date: Mon, 12 Jan 2015 11:06:30 -0800
Subject: De-universalizing hotspot in jdk8u
In-Reply-To: <54B4187F.5060608@oracle.com>
References: <E191CFA4-D089-459E-A74E-E72424EDDA3A@oracle.com>
	<54B300FE.2000804@oracle.com> <54B3A4D0.3080604@oracle.com>
	<54B3AF6D.20607@oracle.com>
	<825EBFC2-6DE1-4550-842B-217C06532C9B@oracle.com>
	<54B4187F.5060608@oracle.com>
Message-ID: <ABE1EB60-5249-45DA-A809-3202F886CBD3@oracle.com>


>>>> I don't know why Hotspot is packaged as a universal binary. In the jdk,
>>>> only libJObjC was built as a universal binary and that lib was removed
>>>> before JDK 8 shipped. What part of Macosx would need to interact
>>>> directly with libjvm.dylib in a way that required a (fake) universal
>>>> format, but no other libs in the jdk? I would say go ahead and change it.
>>> In the spirit of "never take down a fence until you know why it was put up in the first place" I've cc'd macosx-port-dev to see if there is anyone around who recalls why hotspot is using the universal binary feature.
>> I hear you.
>> 
>> My best guess is we'd initially planned on supporting 32 bit but (???) and the easiest way to deliver is in a universal binary. Note that we don't actually deliver universal binaries as the JVM is 64 bit only, or at least there are not nearly enough components there to run a full 32 bit JVM.
> 
> We (Jim Melvin did the work) included universal support in HotSpot
> to not preclude someone else from doing the 32-bit MacOS X port and
> providing it via OpenJDK channels. The rest of the JDK did not
> include universal support, but the hotspot code would have served
> as an example way forward...
> 
> However, we never heard from anyone willing to do the 32-bit port...

Thanks for the explanation Daniel. I'm preserving what's there in the same spirit, but turning off universal by default since it's unnecessary. It sounds to me like this is the correct approach.

-DrD-



From Sergey.Bylokhov at oracle.com  Mon Jan 12 20:29:16 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 12 Jan 2015 23:29:16 +0300
Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from the
	desktop module
Message-ID: <54B42E9C.8010905@oracle.com>

Hello.
Please review a fix for jdk 9.
In the fix a sun.datatransfer and a java.awt.datatransfer packages were 
moved to the separate module java.datatransfer.
But sun.awt.datatransfer still located in java.desktop. I tested full 
jdk(all modules included) on osx using a jck, and it works without 
problems, at least no new issues were found. But datatransfer area is 
quite unstable after a bunch of the latest fixes.
I still cannot replace java.desktop in modules.xml, because of some 
another dependencies(See comments in the bug)

Bug: https://bugs.openjdk.java.net/browse/JDK-8056298
Webrev can be found at:
http://cr.openjdk.java.net/~serb/8056298/webrev.01/jdk/webrev.01
http://cr.openjdk.java.net/~serb/8056298/webrev.01/root/webrev.01

-- 
Best regards, Sergey.



From Alan.Bateman at oracle.com  Mon Jan 12 20:42:16 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 12 Jan 2015 20:42:16 +0000
Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from
	the desktop module
In-Reply-To: <54B42E9C.8010905@oracle.com>
References: <54B42E9C.8010905@oracle.com>
Message-ID: <54B431A8.5020904@oracle.com>

On 12/01/2015 20:29, Sergey Bylokhov wrote:
> Hello.
> Please review a fix for jdk 9.
> In the fix a sun.datatransfer and a java.awt.datatransfer packages 
> were moved to the separate module java.datatransfer.
> But sun.awt.datatransfer still located in java.desktop. I tested full 
> jdk(all modules included) on osx using a jck, and it works without 
> problems, at least no new issues were found. But datatransfer area is 
> quite unstable after a bunch of the latest fixes.
> I still cannot replace java.desktop in modules.xml, because of some 
> another dependencies(See comments in the bug)
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8056298
> Webrev can be found at:
> http://cr.openjdk.java.net/~serb/8056298/webrev.01/jdk/webrev.01
> http://cr.openjdk.java.net/~serb/8056298/webrev.01/root/webrev.01
>
Thanks for doing this. I think it looks okay except for modules.xml 
where it looks like there may be a few issues.

1. You've updated the definition of java.corba to depend on 
java.datatransfer but I don't think this is needed (is there code in 
java.corba that uses this API?).

2. Same thing needs to be checked in java.xml.bind, jdk.jconsole and 
jdk.runtime where it's not clear to me that code in these modules uses 
this API.

2. The update to java.activation to depend on java.datatransfer looks 
right but shouldn't you drop the dependency on java.desktop?

I don't have any other comments except to mention that java.xml.soap has 
been subsumed into java.xml.ws. Those changes are in jdk9/dev and it 
looks like jdk9/client might be a bit out of date.

-Alan



From Sergey.Bylokhov at oracle.com  Mon Jan 12 20:50:21 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 12 Jan 2015 23:50:21 +0300
Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from
	the desktop module
In-Reply-To: <54B431A8.5020904@oracle.com>
References: <54B42E9C.8010905@oracle.com> <54B431A8.5020904@oracle.com>
Message-ID: <54B4338D.9020008@oracle.com>

On 12.01.2015 23:42, Alan Bateman wrote:
> On 12/01/2015 20:29, Sergey Bylokhov wrote:
>> Hello.
>> Please review a fix for jdk 9.
>> In the fix a sun.datatransfer and a java.awt.datatransfer packages 
>> were moved to the separate module java.datatransfer.
>> But sun.awt.datatransfer still located in java.desktop. I tested full 
>> jdk(all modules included) on osx using a jck, and it works without 
>> problems, at least no new issues were found. But datatransfer area is 
>> quite unstable after a bunch of the latest fixes.
>> I still cannot replace java.desktop in modules.xml, because of some 
>> another dependencies(See comments in the bug)
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8056298
>> Webrev can be found at:
>> http://cr.openjdk.java.net/~serb/8056298/webrev.01/jdk/webrev.01
>> http://cr.openjdk.java.net/~serb/8056298/webrev.01/root/webrev.01
>>
> Thanks for doing this. I think it looks okay except for modules.xml 
> where it looks like there may be a few issues.
>
> 1. You've updated the definition of java.corba to depend on 
> java.datatransfer but I don't think this is needed (is there code in 
> java.corba that uses this API?).
>
> 2. Same thing needs to be checked in java.xml.bind, jdk.jconsole and 
> jdk.runtime where it's not clear to me that code in these modules uses 
> this API.
You are right, that's seems unnecessary, i will double check and resend 
a new version.
>
> 2. The update to java.activation to depend on java.datatransfer looks 
> right but shouldn't you drop the dependency on java.desktop?
java.activation depends on java.beans also
>
> I don't have any other comments except to mention that java.xml.soap 
> has been subsumed into java.xml.ws. Those changes are in jdk9/dev and 
> it looks like jdk9/client might be a bit out of date.
I think that a pit before integration to the master will be a good 
thing, so I'll wait nearest dev2client synchronization
>
> -Alan
>


-- 
Best regards, Sergey.



From Alan.Bateman at oracle.com  Mon Jan 12 20:54:19 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 12 Jan 2015 20:54:19 +0000
Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from
	the desktop module
In-Reply-To: <54B4338D.9020008@oracle.com>
References: <54B42E9C.8010905@oracle.com> <54B431A8.5020904@oracle.com>
	<54B4338D.9020008@oracle.com>
Message-ID: <54B4347B.5080806@oracle.com>

On 12/01/2015 20:50, Sergey Bylokhov wrote:
> On 12.01.2015 23:42, Alan Bateman wrote:
>> On 12/01/2015 20:29, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review a fix for jdk 9.
>>> In the fix a sun.datatransfer and a java.awt.datatransfer packages 
>>> were moved to the separate module java.datatransfer.
>>> But sun.awt.datatransfer still located in java.desktop. I tested 
>>> full jdk(all modules included) on osx using a jck, and it works 
>>> without problems, at least no new issues were found. But 
>>> datatransfer area is quite unstable after a bunch of the latest fixes.
>>> I still cannot replace java.desktop in modules.xml, because of some 
>>> another dependencies(See comments in the bug)
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8056298
>>> Webrev can be found at:
>>> http://cr.openjdk.java.net/~serb/8056298/webrev.01/jdk/webrev.01
>>> http://cr.openjdk.java.net/~serb/8056298/webrev.01/root/webrev.01
>>>
>> Thanks for doing this. I think it looks okay except for modules.xml 
>> where it looks like there may be a few issues.
>>
>> 1. You've updated the definition of java.corba to depend on 
>> java.datatransfer but I don't think this is needed (is there code in 
>> java.corba that uses this API?).
>>
>> 2. Same thing needs to be checked in java.xml.bind, jdk.jconsole and 
>> jdk.runtime where it's not clear to me that code in these modules 
>> uses this API.
> You are right, that's seems unnecessary, i will double check and 
> resend a new version.
>>
>> 2. The update to java.activation to depend on java.datatransfer looks 
>> right but shouldn't you drop the dependency on java.desktop?
> java.activation depends on java.beans also
Ah yes, I'd forgotten about that. We have JDK-8047773 to track 
addressing that dependency.

-Alan.



From astrange at apple.com  Mon Jan 12 19:20:09 2015
From: astrange at apple.com (Alex Strange)
Date: Mon, 12 Jan 2015 11:20:09 -0800
Subject: De-universalizing hotspot in jdk8u
In-Reply-To: <54B3AF6D.20607@oracle.com>
References: <E191CFA4-D089-459E-A74E-E72424EDDA3A@oracle.com>
	<54B300FE.2000804@oracle.com> <54B3A4D0.3080604@oracle.com>
	<54B3AF6D.20607@oracle.com>
Message-ID: <9B1E95A7-8496-4E59-9B00-FCC1F4B780FA@apple.com>


> On Jan 12, 2015, at 3:26 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> cc'ing macosx-port-dev and hotspot-dev
> 
> On 12/01/2015 8:41 PM, Erik Joelsson wrote:
>> 
>> On 2015-01-12 00:02, David Holmes wrote:
>>> Hi David,
>>> 
>>> On 10/01/2015 2:00 AM, David DeHaven wrote:
>>>> 
>>>> We have this nice little comment in common/autoconf/jdk-options.m4:
>>>>   # On Macosx universal binaries are produced, but they only contain
>>>>   # 64 bit intel. This invalidates control of which jvms are built
>>>>   # from configure, but only server is valid anyway. Fix this
>>>>   # when hotspot makefiles are rewritten.
>>>>   if test "x$MACOSX_UNIVERSAL" = xtrue; then
>>>>     HOTSPOT_TARGET=universal_${HOTSPOT_EXPORT}
>>>>   fi
>>>> 
>>>> 
>>>> So.. I turned it off:
>>>>   if test "x$OPENJDK_TARGET_OS" = "xmacosx"; then
>>>> #    MACOSX_UNIVERSAL="true"
>>>>     MACOSX_UNIVERSAL="false"
>>>>   fi
>>>> 
>>>> And in hotspot/make/bsd/makefiles/defs.make:
>>>> # Universal build settings
>>>> ifeq ($(OS_VENDOR), Darwin)
>>>>   # Build universal binaries by default on Mac OS X
>>>> #  MACOSX_UNIVERSAL = true
>>>>   MACOSX_UNIVERSAL = false
>>>>   ifneq ($(ALT_MACOSX_UNIVERSAL),)
>>>> 
>>>> hotspot still seems to build happily (I'm kicking off tests now). Is
>>>> there are particular reason this hasn't been done yet? I'd like to
>>>> know before I pursue this as a means of eliminating our dependency on
>>>> lipo which is causing an inordinate amount of grief when trying to
>>>> build on 10.9 and later when Xcode 5+ is coinstalled. I have some
>>>> logic to work around using the broken /usr/bin/lipo, but it doesn't
>>>> help later in some "other" build target that ends up using '-arch
>>>> i386 -arch x86_64'. It does not explicitly run lipo, it relies on gcc
>>>> to do the fattening itself and so it fails even though I've gone to
>>>> the effort of working around the broken lipo (and it isn't necessary
>>>> anyways because it doesn't even build the i386 binaries even though
>>>> it's supposed to be "universal").
>>> 
>>> The hotspot makefiles still haven't been rewritten (though Magnus had
>>> been working on it).
>>> 
>>> Also I was under the impression that we used the universal stuff
>>> because we had to deliver in a particular way on OSX. But I don't know
>>> the details and the people who dealt with the original OSX port effort
>>> are no longer here.
>>> 
>> I don't know why Hotspot is packaged as a universal binary. In the jdk,
>> only libJObjC was built as a universal binary and that lib was removed
>> before JDK 8 shipped. What part of Macosx would need to interact
>> directly with libjvm.dylib in a way that required a (fake) universal
>> format, but no other libs in the jdk? I would say go ahead and change it.
> 
> In the spirit of "never take down a fence until you know why it was put up in the first place" I've cc'd macosx-port-dev to see if there is anyone around who recalls why hotspot is using the universal binary feature.
> 
> David H.
> -------

I did the original universal binary work for hotspot when bringing up macosx-port.

At the time we were building and testing JDK 7 as universal (i386+x86-64) since e.g. some apps had JNI code that was only built 32-bit.
The other jdk components didn't need any makefile work, because the compiler can build them universal by itself, but hotspot autogenerates a lot of arch-specific code and it was easier to build it twice and glue them together in the makefile.

As long as Java is only been shipped 64-bit these days, I personally don't see a reason to keep it.


> /Erik
>> 
>>> David H.
>>> 
>>>> 
>>>> Quite frankly I'd rather just remove all the universal binary stuff
>>>> from hotspot, but I'm trying my best to minimize the changes there...
>>>> the "other" problem I can handle easily.
>>>> 
>>>> -DrD-
>>>> 
>> 



From bhavesh.x.patel at oracle.com  Mon Jan 12 23:40:59 2015
From: bhavesh.x.patel at oracle.com (Bhavesh Patel)
Date: Mon, 12 Jan 2015 15:40:59 -0800 (PST)
Subject: [8u40] Request for review and approval: 8068485: Update references of
	download.oracle.com to docs.oracle.com in javadoc makefile
Message-ID: <65fa6eb7-edab-410f-a57e-ae8f5d782a38@default>

Hi,
    In the javadoc makefile, there are references to http://download.oracle.com. This automatically gets redirected to http://docs.oracle.com. These references needs to be updated to point to https://docs.oracle.com.

JBS: https://bugs.openjdk.java.net/browse/JDK-8068485
Webrev: http://cr.openjdk.java.net/~bpatel/8068485/webrev.00/

    This fix is for 8u40. Can you please review it?

Thanks,
Bhavesh.


From david.holmes at oracle.com  Tue Jan 13 01:40:33 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 13 Jan 2015 11:40:33 +1000
Subject: De-universalizing hotspot in jdk8u
In-Reply-To: <9B1E95A7-8496-4E59-9B00-FCC1F4B780FA@apple.com>
References: <E191CFA4-D089-459E-A74E-E72424EDDA3A@oracle.com>
	<54B300FE.2000804@oracle.com> <54B3A4D0.3080604@oracle.com>
	<54B3AF6D.20607@oracle.com>
	<9B1E95A7-8496-4E59-9B00-FCC1F4B780FA@apple.com>
Message-ID: <54B47791.2040301@oracle.com>

On 13/01/2015 5:20 AM, Alex Strange wrote:
>
>> On Jan 12, 2015, at 3:26 AM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> cc'ing macosx-port-dev and hotspot-dev
>>
>> On 12/01/2015 8:41 PM, Erik Joelsson wrote:
>>>
>>> On 2015-01-12 00:02, David Holmes wrote:
>>>> Hi David,
>>>>
>>>> On 10/01/2015 2:00 AM, David DeHaven wrote:
>>>>>
>>>>> We have this nice little comment in common/autoconf/jdk-options.m4:
>>>>>    # On Macosx universal binaries are produced, but they only contain
>>>>>    # 64 bit intel. This invalidates control of which jvms are built
>>>>>    # from configure, but only server is valid anyway. Fix this
>>>>>    # when hotspot makefiles are rewritten.
>>>>>    if test "x$MACOSX_UNIVERSAL" = xtrue; then
>>>>>      HOTSPOT_TARGET=universal_${HOTSPOT_EXPORT}
>>>>>    fi
>>>>>
>>>>>
>>>>> So.. I turned it off:
>>>>>    if test "x$OPENJDK_TARGET_OS" = "xmacosx"; then
>>>>> #    MACOSX_UNIVERSAL="true"
>>>>>      MACOSX_UNIVERSAL="false"
>>>>>    fi
>>>>>
>>>>> And in hotspot/make/bsd/makefiles/defs.make:
>>>>> # Universal build settings
>>>>> ifeq ($(OS_VENDOR), Darwin)
>>>>>    # Build universal binaries by default on Mac OS X
>>>>> #  MACOSX_UNIVERSAL = true
>>>>>    MACOSX_UNIVERSAL = false
>>>>>    ifneq ($(ALT_MACOSX_UNIVERSAL),)
>>>>>
>>>>> hotspot still seems to build happily (I'm kicking off tests now). Is
>>>>> there are particular reason this hasn't been done yet? I'd like to
>>>>> know before I pursue this as a means of eliminating our dependency on
>>>>> lipo which is causing an inordinate amount of grief when trying to
>>>>> build on 10.9 and later when Xcode 5+ is coinstalled. I have some
>>>>> logic to work around using the broken /usr/bin/lipo, but it doesn't
>>>>> help later in some "other" build target that ends up using '-arch
>>>>> i386 -arch x86_64'. It does not explicitly run lipo, it relies on gcc
>>>>> to do the fattening itself and so it fails even though I've gone to
>>>>> the effort of working around the broken lipo (and it isn't necessary
>>>>> anyways because it doesn't even build the i386 binaries even though
>>>>> it's supposed to be "universal").
>>>>
>>>> The hotspot makefiles still haven't been rewritten (though Magnus had
>>>> been working on it).
>>>>
>>>> Also I was under the impression that we used the universal stuff
>>>> because we had to deliver in a particular way on OSX. But I don't know
>>>> the details and the people who dealt with the original OSX port effort
>>>> are no longer here.
>>>>
>>> I don't know why Hotspot is packaged as a universal binary. In the jdk,
>>> only libJObjC was built as a universal binary and that lib was removed
>>> before JDK 8 shipped. What part of Macosx would need to interact
>>> directly with libjvm.dylib in a way that required a (fake) universal
>>> format, but no other libs in the jdk? I would say go ahead and change it.
>>
>> In the spirit of "never take down a fence until you know why it was put up in the first place" I've cc'd macosx-port-dev to see if there is anyone around who recalls why hotspot is using the universal binary feature.
>>
>> David H.
>> -------
>
> I did the original universal binary work for hotspot when bringing up macosx-port.
>
> At the time we were building and testing JDK 7 as universal (i386+x86-64) since e.g. some apps had JNI code that was only built 32-bit.
> The other jdk components didn't need any makefile work, because the compiler can build them universal by itself, but hotspot autogenerates a lot of arch-specific code and it was easier to build it twice and glue them together in the makefile.
>
> As long as Java is only been shipped 64-bit these days, I personally don't see a reason to keep it.

Thanks for the info Alex. Based on that and Dan's response this proposed 
change seems good to go ahead.

David H.

>
>> /Erik
>>>
>>>> David H.
>>>>
>>>>>
>>>>> Quite frankly I'd rather just remove all the universal binary stuff
>>>>> from hotspot, but I'm trying my best to minimize the changes there...
>>>>> the "other" problem I can handle easily.
>>>>>
>>>>> -DrD-
>>>>>
>>>
>


From toby at telegraphics.com.au  Tue Jan 13 04:03:40 2015
From: toby at telegraphics.com.au (Toby Thain)
Date: Mon, 12 Jan 2015 23:03:40 -0500
Subject: Building openjdk8 - was Re: [8u60] RFR: 8043340: [macosx] Fix
	hard-wired paths to JavaVM.framework
In-Reply-To: <8B01B84D-5B6F-478E-ABF1-33F5ADE2F826@oracle.com>
References: <39719ED3-1F4E-4E6C-AA9F-A3C4766537B4@oracle.com>	<54B3A38C.10909@oracle.com>
	<8B01B84D-5B6F-478E-ABF1-33F5ADE2F826@oracle.com>
Message-ID: <54B4991C.904@telegraphics.com.au>

On 12/01/15 10:28 AM, David DeHaven wrote:
>
> It won't build at all with Xcode 5, there is no gcc compiler and the clang changes were never backported to jdk8u.
>

Yes. I believe those who have done this on Mavericks (including me) are 
using the apple-gcc4.2 binaries (e.g. the one that brew can install).

--Toby

> -DrD-
>
>> Hello,
>>
>> These changes look ok to me.
>>
>> With these changes, configure will unconditionally fail if trying to use XCode 5. I know we don't officially support using XCode 5 for JDK 8, but aren't people working around it with some patches? How hard would it be to make it at least build?
>>
>> /Erik
>>
>> On 2015-01-10 05:45, David DeHaven wrote:
>>> Please review the open source changes for 8043340. The goal here is to get jdk8u to build on Mac OS X 10.9+ systems where Xcode 5+ and Xcode 4 are co-installed, a configuration which is becoming more and more commonplace as more developers are focusing on JDK 9 now (which needs Xcode 5 installed), not to mention new systems ship with 10.10 which only supports the Xcode 5/6 command line tools. It's too much of a hassle to maintain separate systems for building jdk8u and JPRT isn't suitable for frequent changes so something must be done to address this.
>>>
>>> The jdk changes are similar to those done for JDK9, though I removed the changes for building with Xcode 5 (JDK-8043591) since we do not support building JDK 8 with clang.
>>>
>>> The hotspot changes are almost identical, the lack of SYSROOT_CFLAGS necessitated changing the logic in saproc.make a bit. It still builds with or without spec.gmk, though without it you will either need to define SDKPATH or have a sane Xcode 4 installation.
>>>
>>> For the top level build system:
>>> - most of the logic of sanitizing the Xcode build environment is in toolchain.m4
>>> - the LIPO variable was removed since it was completely unused
>>> - OTOOL was moved to after the Xcode sanitizing so it can be picked up from DEVELOPER_DIR if needed
>>> - MACOSX_UNIVERSAL is now being set to false by default and ALT_MACOSX_UNIVERSAL was added to hotspot-spec.gmk.in so the hotspot build is in sync with the jdk build (this was a bug, IMHO)
>>>
>>> That last change removed any need to run lipo (only done in hotspot), so the fact that /usr/bin/lipo is broken with Xcode 4 is a non-issue.
>>>
>>> There is a weird case where some early versions of the Xcode 5 command line tools installed /usr/bin/{gcc|g++} as a symlink to {clang|clang++}, that case is handled by putting $DEVELOPER_DIR/usr/bin on the path so autoconf picks up the actual gcc executable.
>>>
>>> JBS Issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8043340
>>>
>>> Webrevs:
>>> http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/top
>>> http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/hotspot
>>> http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v0/jdk
>>>
>>> JPRT runs are being kicked off. I'll have one run from hotspot directly. I'll post results here.
>>>
>>> -DrD-
>>>
>>
>
>



From erik.joelsson at oracle.com  Tue Jan 13 08:05:52 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 13 Jan 2015 09:05:52 +0100
Subject: [8u40] Request for review and approval: 8068485: Update references
	of download.oracle.com to docs.oracle.com in javadoc makefile
In-Reply-To: <65fa6eb7-edab-410f-a57e-ae8f5d782a38@default>
References: <65fa6eb7-edab-410f-a57e-ae8f5d782a38@default>
Message-ID: <54B4D1E0.6090006@oracle.com>

Looks good to me.

/Erik

On 2015-01-13 00:40, Bhavesh Patel wrote:
> Hi,
>      In the javadoc makefile, there are references to http://download.oracle.com. This automatically gets redirected to http://docs.oracle.com. These references needs to be updated to point to https://docs.oracle.com.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8068485
> Webrev: http://cr.openjdk.java.net/~bpatel/8068485/webrev.00/
>
>      This fix is for 8u40. Can you please review it?
>
> Thanks,
> Bhavesh.



From dean.long at oracle.com  Tue Jan 13 08:32:43 2015
From: dean.long at oracle.com (Dean Long)
Date: Tue, 13 Jan 2015 00:32:43 -0800
Subject: RFR: AARCH64: Top-level JDK changes
In-Reply-To: <54B3B4CE.8060804@oracle.com>
References: <545CFFA9.4070107@redhat.com>	<545D0290.5080307@oracle.com>	<CA+3eh13Byz2VWW6GA_X00np7DU=-xp7nmA-t1iCygU4EU7FOjA@mail.gmail.com>
	<54B34E20.5030506@oracle.com> <54B3B4CE.8060804@oracle.com>
Message-ID: <54B4D82B.3050608@oracle.com>

On 1/12/2015 3:49 AM, Magnus Ihse Bursie wrote:
> On 2015-01-12 05:31, Dean Long wrote:
>> I found a small problem with the new config.sub wrapper.  It works 
>> with the bash shell but not with the dash shell.
>> The problem seems to be with this line:
>>
>>     result=`. $DIR/autoconf-config.sub $sub_args "$@"`
>>
>> "dash" doesn't seem to support args passed with ".", so $sub_args 
>> "$@" are ignored.
>
> bash is the required shell for running configure. We do not support 
> non-bash shells. In fact, we go to lengths to try to ensure that we 
> are indeed running under bash.
>
> /Magnus
I was thinking 'bash configure' was enough, but it turns out 
'CONFIG_SHELL=bash bash configure' gives better results.

dl



From erik.joelsson at oracle.com  Tue Jan 13 08:41:33 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 13 Jan 2015 09:41:33 +0100
Subject: RFR: JDK-8042707: Source changes needed to build JDK 9 with Visual
	Studio 2013 (VS2013)
In-Reply-To: <54AFE98D.3070105@oracle.com>
References: <54AE9A6D.2030101@oracle.com> <54AFE98D.3070105@oracle.com>
Message-ID: <54B4DA3D.4020702@oracle.com>

Hello,

New webrev for root repo:
http://cr.openjdk.java.net/~erikj/8042707/webrev.root.02/

On 2015-01-09 15:45, Magnus Ihse Bursie wrote:
>
> It looks basically good to me. Some remarks on toolchain_windows.m4, 
> though.
>
> In TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT:
> # TODO: improve detection for other versions of VS
>
> This seems to be done now, so perhaps this can be removed :)
Done.
> ---
> Why is "vs_version" lowercase? It might be better to have local 
> variables in lower case (or not, I'm not sure we are consistent on 
> this?) but this breaks with the rest of the variables in the function 
> and looks strange, like it was intentionally signalling something. 
> (This goes for the vs_version in the other functions as well.)
Changed to upper case. Also introduced a common TOOLCHAIN_VERSION 
variable that is used in any non windows specific m4 file.
> ---
> # Work around the insanely named ProgramFiles(x86) env variable
> PROGRAMFILES_X86="`env | $SED -n 's/^ProgramFiles(x86)=//p'`"
>
> Yay! :-) I spent some time going crazy about that one before I gave 
> up. Never thought of that solution.
I think I found that on StackOverflow or similar site so can't claim credit.
> ---
> # FIXME will just assume default Visual Studio version
> if test "x$with_tools_dir" != x; then
> TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT([$with_tools_dir/../..],
>
> This seems broken. Have you tested it? You have to pass a version as 
> the first argument to TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT, 
> yes? I think we need to examine an explicitely given toolchain to have 
> it's version determined. Otherwise, the msvcr/msvcp handling code will 
> not function correctly. I suggest that we first check if 
> --with-toolchain-version is set and if so, respect it. Otherwise, 
> check the path given for the known names (VS_VS_INSTALLDIR_*), and if 
> none matches, abort and complain that version must be specified.
>
> Hm, actually, maybe the entire block of testing with_tools_dir should 
> be lifted up into TOOLCHAIN_FIND_VISUAL_STUDIO and handled 
> separately..? It doesn't really fit into 
> TOOLCHAIN_FIND_VISUAL_STUDIO_BAT_FILE anyhow.
>
I tinkered some with this, but ended up putting it back in 
TOOLCHAIN_FIND_VISUAL_STUDIO_BAT_FILE because it was simpler. It works 
now, but setting --with-tools-dir assumes you are pointing to the 
default version of Visual Studio. If you aren't, you must also set 
--with-toolchain-version for it to behave correctly. I suppose we could 
implement detection logic that would figure out which version it was, 
but I would rather not spend time on it when it's not the preferred way 
to configure this.

/Erik


From dean.long at oracle.com  Tue Jan 13 08:44:04 2015
From: dean.long at oracle.com (Dean Long)
Date: Tue, 13 Jan 2015 00:44:04 -0800
Subject: RFR: AARCH64: Top-level JDK changes
In-Reply-To: <54B3A108.9070203@redhat.com>
References: <545CFFA9.4070107@redhat.com>	<545D0290.5080307@oracle.com>	<CA+3eh13Byz2VWW6GA_X00np7DU=-xp7nmA-t1iCygU4EU7FOjA@mail.gmail.com>
	<54B34E20.5030506@oracle.com> <54B3A108.9070203@redhat.com>
Message-ID: <54B4DAD4.5060904@oracle.com>

On 1/12/2015 2:25 AM, Andrew Haley wrote:
> On 12/01/15 04:31, Dean Long wrote:
>> I found a small problem with the new config.sub wrapper.  It works with
>> the bash shell but not with the dash shell.
>> The problem seems to be with this line:
>>
>>       result=`. $DIR/autoconf-config.sub $sub_args "$@"`
>>
>> "dash" doesn't seem to support args passed with ".", so $sub_args "$@"
>> are ignored.
> Thank you.  Sorry for the breakage; I didn't intend to use any
> non-portable shell idioms.  I'm not expert enough to say whether this
> is a bug in dash, but I don't suppose that matters: we are where we
> are.
>
> There's no reason not to replace the "." with "bash".  Do you want me
> to do anything?

I guess not, since we only support bash.  However, I did notice another 
problem with the
same file.  "aarch64-linux-gnu" comes out as "aarch64-linux-gnu" instead of
"aarch64-unknown-linux-gnu".  I came up with a simpler version, where I 
replace
"aarch64-" with "arm-", run autoconf-config.sub, then replace "arm-" 
back to "aarch64-".

dl

> Andrew.



From aph at redhat.com  Tue Jan 13 09:08:19 2015
From: aph at redhat.com (Andrew Haley)
Date: Tue, 13 Jan 2015 09:08:19 +0000
Subject: RFR: AARCH64: Top-level JDK changes
In-Reply-To: <54B4DAD4.5060904@oracle.com>
References: <545CFFA9.4070107@redhat.com>	<545D0290.5080307@oracle.com>	<CA+3eh13Byz2VWW6GA_X00np7DU=-xp7nmA-t1iCygU4EU7FOjA@mail.gmail.com>
	<54B34E20.5030506@oracle.com> <54B3A108.9070203@redhat.com>
	<54B4DAD4.5060904@oracle.com>
Message-ID: <54B4E083.9040502@redhat.com>

On 13/01/15 08:44, Dean Long wrote:

> I came up with a simpler version, where I replace "aarch64-" with
> "arm-", run autoconf-config.sub, then replace "arm-" back to
> "aarch64-".

Thanks.  That sounds good to me.

Andrew.


From Sergey.Bylokhov at oracle.com  Tue Jan 13 11:40:34 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 13 Jan 2015 14:40:34 +0300
Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from
	the desktop module
In-Reply-To: <54B431A8.5020904@oracle.com>
References: <54B42E9C.8010905@oracle.com> <54B431A8.5020904@oracle.com>
Message-ID: <54B50432.5060300@oracle.com>

Hi, Alan.
On 12.01.2015 23:42, Alan Bateman wrote:
> Thanks for doing this. I think it looks okay except for modules.xml 
> where it looks like there may be a few issues.
>
> 1. You've updated the definition of java.corba to depend on 
> java.datatransfer but I don't think this is needed (is there code in 
> java.corba that uses this API?).
>
> 2. Same thing needs to be checked in java.xml.bind, jdk.jconsole and 
> jdk.runtime where it's not clear to me that code in these modules uses 
> this API.

java.datatransfer was removed everywhere except:

1. java.xml.bind
jaxws/src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/staxex/StreamingDataHandler.java:53: 
error: cannot access Transferable
public abstract class StreamingDataHandler extends DataHandler 
implements Closeable {

2. java.xml.soap
jaxws/src/java.xml.soap/share/classes/com/sun/xml/internal/messaging/saaj/soap/FastInfosetDataContentHandler.java:53: 
error: cannot find symbol
     public DataFlavor[] getTransferDataFlavors() { // throws Exceptio

3. java.xml.ws
jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/developer/StreamingDataHandler.java:51: 
error: cannot access Transferable
public abstract class StreamingDataHandler extends 
com.sun.xml.internal.org.jvnet.staxex.StreamingDataHandler {

The new versions:
http://cr.openjdk.java.net/~serb/8056298/webrev.02/jdk
http://cr.openjdk.java.net/~serb/8056298/webrev.02/root

Bug: https://bugs.openjdk.java.net/browse/JDK-8056298

>
> 2. The update to java.activation to depend on java.datatransfer looks 
> right but shouldn't you drop the dependency on java.desktop?
>
> I don't have any other comments except to mention that java.xml.soap 
> has been subsumed into java.xml.ws. Those changes are in jdk9/dev and 
> it looks like jdk9/client might be a bit out of date.
>
> -Alan
>


-- 
Best regards, Sergey.



From erik.joelsson at oracle.com  Tue Jan 13 12:57:20 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 13 Jan 2015 13:57:20 +0100
Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from
	the desktop module
In-Reply-To: <54B50432.5060300@oracle.com>
References: <54B42E9C.8010905@oracle.com> <54B431A8.5020904@oracle.com>
	<54B50432.5060300@oracle.com>
Message-ID: <54B51630.1000108@oracle.com>

The makefile change looks good to me.

/Erik

On 2015-01-13 12:40, Sergey Bylokhov wrote:
> Hi, Alan.
> On 12.01.2015 23:42, Alan Bateman wrote:
>> Thanks for doing this. I think it looks okay except for modules.xml 
>> where it looks like there may be a few issues.
>>
>> 1. You've updated the definition of java.corba to depend on 
>> java.datatransfer but I don't think this is needed (is there code in 
>> java.corba that uses this API?).
>>
>> 2. Same thing needs to be checked in java.xml.bind, jdk.jconsole and 
>> jdk.runtime where it's not clear to me that code in these modules 
>> uses this API.
>
> java.datatransfer was removed everywhere except:
>
> 1. java.xml.bind
> jaxws/src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/staxex/StreamingDataHandler.java:53: 
> error: cannot access Transferable
> public abstract class StreamingDataHandler extends DataHandler 
> implements Closeable {
>
> 2. java.xml.soap
> jaxws/src/java.xml.soap/share/classes/com/sun/xml/internal/messaging/saaj/soap/FastInfosetDataContentHandler.java:53: 
> error: cannot find symbol
>     public DataFlavor[] getTransferDataFlavors() { // throws Exceptio
>
> 3. java.xml.ws
> jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/developer/StreamingDataHandler.java:51: 
> error: cannot access Transferable
> public abstract class StreamingDataHandler extends 
> com.sun.xml.internal.org.jvnet.staxex.StreamingDataHandler {
>
> The new versions:
> http://cr.openjdk.java.net/~serb/8056298/webrev.02/jdk
> http://cr.openjdk.java.net/~serb/8056298/webrev.02/root
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8056298
>
>>
>> 2. The update to java.activation to depend on java.datatransfer looks 
>> right but shouldn't you drop the dependency on java.desktop?
>>
>> I don't have any other comments except to mention that java.xml.soap 
>> has been subsumed into java.xml.ws. Those changes are in jdk9/dev and 
>> it looks like jdk9/client might be a bit out of date.
>>
>> -Alan
>>
>
>



From Alan.Bateman at oracle.com  Tue Jan 13 13:15:09 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 13 Jan 2015 13:15:09 +0000
Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from
	the desktop module
In-Reply-To: <54B50432.5060300@oracle.com>
References: <54B42E9C.8010905@oracle.com> <54B431A8.5020904@oracle.com>
	<54B50432.5060300@oracle.com>
Message-ID: <54B51A5D.2090708@oracle.com>

On 13/01/2015 11:40, Sergey Bylokhov wrote:
> :
>
> The new versions:
> http://cr.openjdk.java.net/~serb/8056298/webrev.02/jdk
> http://cr.openjdk.java.net/~serb/8056298/webrev.02/root
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8056298
Thanks for the update. The only thing that isn't clear to me is the 
java.activation dependency on java.desktop where I assume the 
re-exports="true" should be removed (because the dependency on 
java.beans.Beans is not in any of the method signatures).

-Alan





From rkennke at redhat.com  Tue Jan 13 13:23:17 2015
From: rkennke at redhat.com (Roman Kennke)
Date: Tue, 13 Jan 2015 14:23:17 +0100
Subject: [PATCH] Fix Shark build in JDK9
In-Reply-To: <54AF66B9.8060900@oracle.com>
References: <1420641903.6838.9.camel@localhost>
	<54AD4C6B.1070702@oracle.com> <1420645301.6838.14.camel@localhost>
	<54AD5675.7010101@oracle.com> <1420647107.6838.15.camel@localhost>
	<54AD5BDF.1060401@oracle.com> <1420648161.6838.17.camel@localhost>
	<54AD639A.2060200@oracle.com> <1420662102.6838.23.camel@localhost>
	<54AE560B.3060200@oracle.com> <1420714881.6838.25.camel@localhost>
	<54AF66B9.8060900@oracle.com>
Message-ID: <1421155397.6838.43.camel@localhost>

Hi David,


> > - In ciTypeFlow.cpp only include some files and code only when building
> > C2. I don't think that code makes sense outside of C2. (That's the issue
> > that you've seen).
> 
> Looks okay but someone from compiler team needs to comment. There may be 
> other code that need adjusting.

It might be less intrusive to guard this with #ifndef SHARK instead of
#ifdef COMPILER2. I don't think it makes a difference though.

> > - In allocation.hpp, exclude the operator overrides for new etc, LLVM
> > does allocations itself, and this would blow up.
> 
> I'm intrigued as the allocation strategy is not tied to the compiler but 
> pervasive to the whole VM runtime.

In a comment it says this whole block is disabled in PRODUCT versions,
because of 3rd party code that might be in use. This is basically the
situation with Shark: we need to be able to do allocations in LLVM, and
LLVM doesn't know about Hotspot's allocation safeguards. That's why I
disable it for Shark builds.

> > - In handles.hpp and handles.inline.hpp, I added an argument
> > check_in_stack so that I can disable the in-stack check for the
> > SharkNativeWrapper. The SharkNativeWrapper is allocated on-heap and the
> > methodHandle inside the SharkNativeWrapper. I could have excluded that
> > check altogther using an #ifndef SHARK, but the way I implemented it
> > seemed more finegrained.
> 
> I'd prefer an ifndef SHARK rather than change the API.

Yeah ok, I understand that. However, I do not know how I can do an
#ifdef inside a #define block. I'd need to duplicate the whole block,
and put #ifdefs around those. This raises the question about code
maintainability though, any changes in one block need to be done in the
other block as well. I can do that if you prefer over the API change.
That being said, multi-line-#defines are evil anyway ;-)

Roman




From Sergey.Bylokhov at oracle.com  Tue Jan 13 13:52:28 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 13 Jan 2015 16:52:28 +0300
Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from
	the desktop module
In-Reply-To: <54B51A5D.2090708@oracle.com>
References: <54B42E9C.8010905@oracle.com> <54B431A8.5020904@oracle.com>
	<54B50432.5060300@oracle.com> <54B51A5D.2090708@oracle.com>
Message-ID: <54B5231C.4090809@oracle.com>

On 13.01.2015 16:15, Alan Bateman wrote:
> On 13/01/2015 11:40, Sergey Bylokhov wrote:
>> :
>>
>> The new versions:
>> http://cr.openjdk.java.net/~serb/8056298/webrev.02/jdk
>> http://cr.openjdk.java.net/~serb/8056298/webrev.02/root
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8056298
> Thanks for the update. The only thing that isn't clear to me is the 
> java.activation dependency on java.desktop where I assume the 
> re-exports="true" should be removed (because the dependency on 
> java.beans.Beans is not in any of the method signatures).
Yes it is unnecessary. The new versions:
http://cr.openjdk.java.net/~serb/8056298/webrev.03/jdk
http://cr.openjdk.java.net/~serb/8056298/webrev.03/root
>
> -Alan
>
>
>


-- 
Best regards, Sergey.



From Alan.Bateman at oracle.com  Tue Jan 13 14:05:23 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 13 Jan 2015 14:05:23 +0000
Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from
	the desktop module
In-Reply-To: <54B5231C.4090809@oracle.com>
References: <54B42E9C.8010905@oracle.com> <54B431A8.5020904@oracle.com>
	<54B50432.5060300@oracle.com> <54B51A5D.2090708@oracle.com>
	<54B5231C.4090809@oracle.com>
Message-ID: <54B52623.5010700@oracle.com>

On 13/01/2015 13:52, Sergey Bylokhov wrote:
> Yes it is unnecessary. The new versions:
> http://cr.openjdk.java.net/~serb/8056298/webrev.03/jdk
> http://cr.openjdk.java.net/~serb/8056298/webrev.03/root
This looks good to (and I assume that "make verify-images" passes).

-Alan.


From Sergey.Bylokhov at oracle.com  Tue Jan 13 14:17:03 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 13 Jan 2015 17:17:03 +0300
Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from
	the desktop module
In-Reply-To: <54B52623.5010700@oracle.com>
References: <54B42E9C.8010905@oracle.com> <54B431A8.5020904@oracle.com>
	<54B50432.5060300@oracle.com> <54B51A5D.2090708@oracle.com>
	<54B5231C.4090809@oracle.com> <54B52623.5010700@oracle.com>
Message-ID: <54B528DF.8020507@oracle.com>

On 13.01.2015 17:05, Alan Bateman wrote:
> On 13/01/2015 13:52, Sergey Bylokhov wrote:
>> Yes it is unnecessary. The new versions:
>> http://cr.openjdk.java.net/~serb/8056298/webrev.03/jdk
>> http://cr.openjdk.java.net/~serb/8056298/webrev.03/root
> This looks good to (and I assume that "make verify-images" passes).
Did you mean "make verify-modules"? I was under impression that it was 
added to the image target, seems not. I will check that.
>
> -Alan.


-- 
Best regards, Sergey.



From Alan.Bateman at oracle.com  Tue Jan 13 14:23:03 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 13 Jan 2015 14:23:03 +0000
Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from
	the desktop module
In-Reply-To: <54B528DF.8020507@oracle.com>
References: <54B42E9C.8010905@oracle.com> <54B431A8.5020904@oracle.com>
	<54B50432.5060300@oracle.com> <54B51A5D.2090708@oracle.com>
	<54B5231C.4090809@oracle.com> <54B52623.5010700@oracle.com>
	<54B528DF.8020507@oracle.com>
Message-ID: <54B52A47.8030501@oracle.com>

On 13/01/2015 14:17, Sergey Bylokhov wrote:
> On 13.01.2015 17:05, Alan Bateman wrote:
>> On 13/01/2015 13:52, Sergey Bylokhov wrote:
>>> Yes it is unnecessary. The new versions:
>>> http://cr.openjdk.java.net/~serb/8056298/webrev.03/jdk
>>> http://cr.openjdk.java.net/~serb/8056298/webrev.03/root
>> This looks good to (and I assume that "make verify-images" passes).
> Did you mean "make verify-modules"? I was under impression that it was 
> added to the image target, seems not. I will check that.
Typo in my mail, I meant verify-modules.

They are currently issues with verify-modules and boot cycle builds so I 
think verify-modules is currently disabled (at least in jdk9/dev). Erik 
is working on this via JDK-8067479.

-Alan.





From Sergey.Bylokhov at oracle.com  Tue Jan 13 15:45:49 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 13 Jan 2015 18:45:49 +0300
Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from
	the desktop module
In-Reply-To: <54B52A47.8030501@oracle.com>
References: <54B42E9C.8010905@oracle.com> <54B431A8.5020904@oracle.com>
	<54B50432.5060300@oracle.com> <54B51A5D.2090708@oracle.com>
	<54B5231C.4090809@oracle.com> <54B52623.5010700@oracle.com>
	<54B528DF.8020507@oracle.com> <54B52A47.8030501@oracle.com>
Message-ID: <54B53DAD.80407@oracle.com>

On 13.01.2015 17:23, Alan Bateman wrote:
> Typo in my mail, I meant verify-modules.
>
> They are currently issues with verify-modules and boot cycle builds so 
> I think verify-modules is currently disabled (at least in jdk9/dev). 
> Erik is working on this via JDK-8067479.
The new versions:
http://cr.openjdk.java.net/~serb/8056298/webrev.04/jdk
http://cr.openjdk.java.net/~serb/8056298/webrev.04/root
  - sun.reflect.misc and sun.security.util were exported to 
java.datatransfer.
  - jdk.hotspot.agent now depends on java.datatransfer
"make verify-modules" was completed w/o issues.

-- 
Best regards, Sergey.



From magnus.ihse.bursie at oracle.com  Tue Jan 13 16:04:56 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 13 Jan 2015 17:04:56 +0100
Subject: RFR: JDK-8042707: Source changes needed to build JDK 9 with Visual
	Studio 2013 (VS2013)
In-Reply-To: <54B4DA3D.4020702@oracle.com>
References: <54AE9A6D.2030101@oracle.com> <54AFE98D.3070105@oracle.com>
	<54B4DA3D.4020702@oracle.com>
Message-ID: <54B54228.2020005@oracle.com>

On 2015-01-13 09:41, Erik Joelsson wrote:
> Hello,
>
> New webrev for root repo:
> http://cr.openjdk.java.net/~erikj/8042707/webrev.root.02/

Fixes look good to me. Thanks!

/Magnus

>
> On 2015-01-09 15:45, Magnus Ihse Bursie wrote:
>>
>> It looks basically good to me. Some remarks on toolchain_windows.m4, 
>> though.
>>
>> In TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT:
>> # TODO: improve detection for other versions of VS
>>
>> This seems to be done now, so perhaps this can be removed :)
> Done.
>> ---
>> Why is "vs_version" lowercase? It might be better to have local 
>> variables in lower case (or not, I'm not sure we are consistent on 
>> this?) but this breaks with the rest of the variables in the function 
>> and looks strange, like it was intentionally signalling something. 
>> (This goes for the vs_version in the other functions as well.)
> Changed to upper case. Also introduced a common TOOLCHAIN_VERSION 
> variable that is used in any non windows specific m4 file.
>> ---
>> # Work around the insanely named ProgramFiles(x86) env variable
>> PROGRAMFILES_X86="`env | $SED -n 's/^ProgramFiles(x86)=//p'`"
>>
>> Yay! :-) I spent some time going crazy about that one before I gave 
>> up. Never thought of that solution.
> I think I found that on StackOverflow or similar site so can't claim 
> credit.
>> ---
>> # FIXME will just assume default Visual Studio version
>> if test "x$with_tools_dir" != x; then
>> TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT([$with_tools_dir/../..],
>>
>> This seems broken. Have you tested it? You have to pass a version as 
>> the first argument to TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT, 
>> yes? I think we need to examine an explicitely given toolchain to 
>> have it's version determined. Otherwise, the msvcr/msvcp handling 
>> code will not function correctly. I suggest that we first check if 
>> --with-toolchain-version is set and if so, respect it. Otherwise, 
>> check the path given for the known names (VS_VS_INSTALLDIR_*), and if 
>> none matches, abort and complain that version must be specified.
>>
>> Hm, actually, maybe the entire block of testing with_tools_dir should 
>> be lifted up into TOOLCHAIN_FIND_VISUAL_STUDIO and handled 
>> separately..? It doesn't really fit into 
>> TOOLCHAIN_FIND_VISUAL_STUDIO_BAT_FILE anyhow.
>>
> I tinkered some with this, but ended up putting it back in 
> TOOLCHAIN_FIND_VISUAL_STUDIO_BAT_FILE because it was simpler. It works 
> now, but setting --with-tools-dir assumes you are pointing to the 
> default version of Visual Studio. If you aren't, you must also set 
> --with-toolchain-version for it to behave correctly. I suppose we 
> could implement detection logic that would figure out which version it 
> was, but I would rather not spend time on it when it's not the 
> preferred way to configure this.
>
> /Erik



From kellyohair at gmail.com  Tue Jan 13 17:03:13 2015
From: kellyohair at gmail.com (Kelly O'Hair)
Date: Tue, 13 Jan 2015 09:03:13 -0800
Subject: Build Group Lead resignation
Message-ID: <D817DE9C-4A46-4D14-BF02-F711879DE9E5@gmail.com>


I wish to resign as Build Group Lead. It makes much more sense for someone closer to the OpenJDK build issues to be the lead of this group.

I would like to stay a group member and keep up-to-date on the activities, but I am unable to take on any significant role at this time.

According to the bylaws [1], a new Group Lead can now be nominated by any OpenJDK member of the Sponsoring Groups [2].


[1] http://openjdk.java.net/bylaws#group-lead
[2] http://openjdk.java.net/census#build

From mandy.chung at oracle.com  Tue Jan 13 17:26:59 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 13 Jan 2015 09:26:59 -0800
Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from
	the desktop module
In-Reply-To: <54B53DAD.80407@oracle.com>
References: <54B42E9C.8010905@oracle.com>
	<54B431A8.5020904@oracle.com>	<54B50432.5060300@oracle.com>
	<54B51A5D.2090708@oracle.com>	<54B5231C.4090809@oracle.com>
	<54B52623.5010700@oracle.com>	<54B528DF.8020507@oracle.com>
	<54B52A47.8030501@oracle.com> <54B53DAD.80407@oracle.com>
Message-ID: <54B55563.50203@oracle.com>

On 1/13/15 7:45 AM, Sergey Bylokhov wrote:
> On 13.01.2015 17:23, Alan Bateman wrote:
>> Typo in my mail, I meant verify-modules.
>>
>> They are currently issues with verify-modules and boot cycle builds 
>> so I think verify-modules is currently disabled (at least in 
>> jdk9/dev). Erik is working on this via JDK-8067479.
> The new versions:
> http://cr.openjdk.java.net/~serb/8056298/webrev.04/jdk
> http://cr.openjdk.java.net/~serb/8056298/webrev.04/root
>  - sun.reflect.misc and sun.security.util were exported to 
> java.datatransfer.
>  - jdk.hotspot.agent now depends on java.datatransfer
> "make verify-modules" was completed w/o issues.
>
Thanks for doing this. java.activation, java.xml.ws, jdk.hotspot.agent
uses java.awt.datatransfer.  I don't find java.xml.bind using it.

$ jdeps -p java.awt.datatransfer $BUILD_OUTPUTDIR/jdk/modules/*

The result shows that java.activation, java.xml.ws, jdk.hotspot.agent
uses java.awt.datatransfer (there is a bug in jdeps that didn't show
the module name correctly - will file a bug and fix it).

How do you find java.xml.bind depend on java.datatransfer?  You can
run this from your build:
$ jdk/bin/jdeps -s jdk/modules/java.xml.bind/

About the qualified exports from java.base:

java.awt.datatransfer.DataFlavor uses  
sun.security.util.SecurityConstants.GET_CLASSLOADER_PERMISSION

I suggest to remove this dependency by creating the instance
when security manager is on:
    new RuntimePermission("getClassLoader")

Mandy



From Sergey.Bylokhov at oracle.com  Tue Jan 13 17:34:07 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 13 Jan 2015 20:34:07 +0300
Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from
	the desktop module
In-Reply-To: <54B55563.50203@oracle.com>
References: <54B42E9C.8010905@oracle.com>
	<54B431A8.5020904@oracle.com>	<54B50432.5060300@oracle.com>
	<54B51A5D.2090708@oracle.com>	<54B5231C.4090809@oracle.com>
	<54B52623.5010700@oracle.com>	<54B528DF.8020507@oracle.com>
	<54B52A47.8030501@oracle.com> <54B53DAD.80407@oracle.com>
	<54B55563.50203@oracle.com>
Message-ID: <54B5570F.7050900@oracle.com>

On 13.01.2015 20:26, Mandy Chung wrote:
> On 1/13/15 7:45 AM, Sergey Bylokhov wrote:
>> On 13.01.2015 17:23, Alan Bateman wrote:
>>> Typo in my mail, I meant verify-modules.
>>>
>>> They are currently issues with verify-modules and boot cycle builds 
>>> so I think verify-modules is currently disabled (at least in 
>>> jdk9/dev). Erik is working on this via JDK-8067479.
>> The new versions:
>> http://cr.openjdk.java.net/~serb/8056298/webrev.04/jdk
>> http://cr.openjdk.java.net/~serb/8056298/webrev.04/root
>>  - sun.reflect.misc and sun.security.util were exported to 
>> java.datatransfer.
>>  - jdk.hotspot.agent now depends on java.datatransfer
>> "make verify-modules" was completed w/o issues.
>>
> Thanks for doing this. java.activation, java.xml.ws, jdk.hotspot.agent
> uses java.awt.datatransfer.  I don't find java.xml.bind using it.
>
> $ jdeps -p java.awt.datatransfer $BUILD_OUTPUTDIR/jdk/modules/*
>
> The result shows that java.activation, java.xml.ws, jdk.hotspot.agent
> uses java.awt.datatransfer (there is a bug in jdeps that didn't show
> the module name correctly - will file a bug and fix it).
>
> How do you find java.xml.bind depend on java.datatransfer?  You can
> run this from your build:
> $ jdk/bin/jdeps -s jdk/modules/java.xml.bind/
it does not compile w/o it:
java.xml.bind:
jaxws/src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/staxex/StreamingDataHandler.java:53: 
error: cannot access Transferable
public abstract class StreamingDataHandler extends DataHandler 
implements Closeable {

>
> About the qualified exports from java.base:
>
> java.awt.datatransfer.DataFlavor uses 
> sun.security.util.SecurityConstants.GET_CLASSLOADER_PERMISSION
>
> I suggest to remove this dependency by creating the instance
> when security manager is on:
>    new RuntimePermission("getClassLoader")
is it necessary? I prefer to use current solution as more readable.
>
> Mandy
>


-- 
Best regards, Sergey.



From mandy.chung at oracle.com  Tue Jan 13 18:26:07 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 13 Jan 2015 10:26:07 -0800
Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from
	the desktop module
In-Reply-To: <54B5570F.7050900@oracle.com>
References: <54B42E9C.8010905@oracle.com>
	<54B431A8.5020904@oracle.com>	<54B50432.5060300@oracle.com>
	<54B51A5D.2090708@oracle.com>	<54B5231C.4090809@oracle.com>
	<54B52623.5010700@oracle.com>	<54B528DF.8020507@oracle.com>
	<54B52A47.8030501@oracle.com> <54B53DAD.80407@oracle.com>
	<54B55563.50203@oracle.com> <54B5570F.7050900@oracle.com>
Message-ID: <54B5633F.7010403@oracle.com>

On 1/13/15 9:34 AM, Sergey Bylokhov wrote:
> On 13.01.2015 20:26, Mandy Chung wrote:
>> On 1/13/15 7:45 AM, Sergey Bylokhov wrote:
>>> On 13.01.2015 17:23, Alan Bateman wrote:
>>>> Typo in my mail, I meant verify-modules.
>>>>
>>>> They are currently issues with verify-modules and boot cycle builds 
>>>> so I think verify-modules is currently disabled (at least in 
>>>> jdk9/dev). Erik is working on this via JDK-8067479.
>>> The new versions:
>>> http://cr.openjdk.java.net/~serb/8056298/webrev.04/jdk
>>> http://cr.openjdk.java.net/~serb/8056298/webrev.04/root
>>>  - sun.reflect.misc and sun.security.util were exported to 
>>> java.datatransfer.
>>>  - jdk.hotspot.agent now depends on java.datatransfer
>>> "make verify-modules" was completed w/o issues.
>>>
>> Thanks for doing this. java.activation, java.xml.ws, jdk.hotspot.agent
>> uses java.awt.datatransfer.  I don't find java.xml.bind using it.
>>
>> $ jdeps -p java.awt.datatransfer $BUILD_OUTPUTDIR/jdk/modules/*
>>
>> The result shows that java.activation, java.xml.ws, jdk.hotspot.agent
>> uses java.awt.datatransfer (there is a bug in jdeps that didn't show
>> the module name correctly - will file a bug and fix it).
>>
>> How do you find java.xml.bind depend on java.datatransfer?  You can
>> run this from your build:
>> $ jdk/bin/jdeps -s jdk/modules/java.xml.bind/
> it does not compile w/o it:
> java.xml.bind:
> jaxws/src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/staxex/StreamingDataHandler.java:53: 
> error: cannot access Transferable
> public abstract class StreamingDataHandler extends DataHandler 
> implements Closeable {
>

I see.  java.xml.bind -> java.desktop is temporarily needed until the 
module system is in replace unless the build adds the re-exported module 
(i.e. java.datatransfer) to the sourcepath to compile java.xml.bind.

That change is fine.
>>
>> About the qualified exports from java.base:
>>
>> java.awt.datatransfer.DataFlavor uses 
>> sun.security.util.SecurityConstants.GET_CLASSLOADER_PERMISSION
>>
>> I suggest to remove this dependency by creating the instance
>> when security manager is on:
>>    new RuntimePermission("getClassLoader")
> is it necessary? I prefer to use current solution as more readable.

I'd like to keep the qualified exports to the ones which are absolutely 
needed.  Sharing common code is good while this "getClassLoader" 
permission is part of the specification and allowing desktop to access 
the entire sun.security.util package is more than it needs 
(java.datatransfer only depends on this static instance).  The cost of 
creating a Permission object is low and only when security manager is 
on.  I would recommend to replace the dependency on SecurityConstants.

Mandy


From Alan.Bateman at oracle.com  Tue Jan 13 18:51:24 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 13 Jan 2015 18:51:24 +0000
Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from
	the desktop module
In-Reply-To: <54B53DAD.80407@oracle.com>
References: <54B42E9C.8010905@oracle.com> <54B431A8.5020904@oracle.com>
	<54B50432.5060300@oracle.com> <54B51A5D.2090708@oracle.com>
	<54B5231C.4090809@oracle.com> <54B52623.5010700@oracle.com>
	<54B528DF.8020507@oracle.com> <54B52A47.8030501@oracle.com>
	<54B53DAD.80407@oracle.com>
Message-ID: <54B5692C.2000507@oracle.com>

On 13/01/2015 15:45, Sergey Bylokhov wrote:
> On 13.01.2015 17:23, Alan Bateman wrote:
>> Typo in my mail, I meant verify-modules.
>>
>> They are currently issues with verify-modules and boot cycle builds 
>> so I think verify-modules is currently disabled (at least in 
>> jdk9/dev). Erik is working on this via JDK-8067479.
> The new versions:
> http://cr.openjdk.java.net/~serb/8056298/webrev.04/jdk
> http://cr.openjdk.java.net/~serb/8056298/webrev.04/root
>  - sun.reflect.misc and sun.security.util were exported to 
> java.datatransfer.
>  - jdk.hotspot.agent now depends on java.datatransfer
> "make verify-modules" was completed w/o issues.
>
I think this looks okay. I see Mandy's comment about dropping the 
dependency on sun.security.util and that would be good to do (but can be 
another patch if you want).

-Alan


From dean.long at oracle.com  Tue Jan 13 18:56:21 2015
From: dean.long at oracle.com (Dean Long)
Date: Tue, 13 Jan 2015 10:56:21 -0800
Subject: RFR: AARCH64: Top-level JDK changes
In-Reply-To: <54B4E083.9040502@redhat.com>
References: <545CFFA9.4070107@redhat.com>	<545D0290.5080307@oracle.com>	<CA+3eh13Byz2VWW6GA_X00np7DU=-xp7nmA-t1iCygU4EU7FOjA@mail.gmail.com>
	<54B34E20.5030506@oracle.com> <54B3A108.9070203@redhat.com>
	<54B4DAD4.5060904@oracle.com> <54B4E083.9040502@redhat.com>
Message-ID: <54B56A55.3020803@oracle.com>

On 1/13/2015 1:08 AM, Andrew Haley wrote:
> On 13/01/15 08:44, Dean Long wrote:
>
>> I came up with a simpler version, where I replace "aarch64-" with
>> "arm-", run autoconf-config.sub, then replace "arm-" back to
>> "aarch64-".
> Thanks.  That sounds good to me.
>
> Andrew.

Here's the patch.  If it looks good, I can file a bug and push it to the 
staging repo.

dl


diff -r b052cb38b985 common/autoconf/build-aux/config.sub
--- a/common/autoconf/build-aux/config.sub      Thu Dec 11 15:05:06 2014 
-0800
+++ b/common/autoconf/build-aux/config.sub      Tue Jan 13 13:57:23 2015 
-0500
@@ -41,25 +41,8 @@
      case $1 in
          -- )   # Stop option processing
              shift; break ;;
-        aarch64-gnu )
-            sub_args="$sub_args aarch64-unknown-gnu"
-            shift; ;;
-        aarch64-linux )
-            sub_args="$sub_args aarch64-unknown-linux-gnu"
-            shift; ;;
-        aarch64-*-linux )
-            os=`echo $1 | sed 's/aarch64-\(.*\)-linux/\1/'`
-            config="aarch64-unknown-linux-gnu"
-            sub_args="$sub_args $config"
-            shift; ;;
-        aarch64-*-gnu )
-            os=`echo $1 | sed 's/aarch64-\(.*\)-gnu.*$/\1/'`
-            config="aarch64-unknown-gnu"
-            sub_args="$sub_args $config"
-            shift; ;;
-        aarch64-*-linux-* )
-            os=`echo $1 | sed 's/aarch64-\(.*\)-linux-.*$/'`
-            config="aarch64-unknown-linux-gnu"
+        aarch64-* )
+            config=`echo $1 | sed 's/^aarch64-/arm-/'`
              sub_args="$sub_args $config"
              shift; ;;
          - )    # Use stdin as input.
@@ -74,9 +57,7 @@
  result=`. $DIR/autoconf-config.sub $sub_args "$@"`
  exitcode=$?

-if [ "x$os" != "x" ] ; then
-    result=`echo $result | sed "s/-unknown-/-$os-/"`
-fi
+result=`echo $result | sed "s/^arm-/aarch64-/"`

  echo $result
  exit $exitcode



From Sergey.Bylokhov at oracle.com  Tue Jan 13 19:30:45 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 13 Jan 2015 22:30:45 +0300
Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from
	the desktop module
In-Reply-To: <54B5692C.2000507@oracle.com>
References: <54B42E9C.8010905@oracle.com> <54B431A8.5020904@oracle.com>
	<54B50432.5060300@oracle.com> <54B51A5D.2090708@oracle.com>
	<54B5231C.4090809@oracle.com> <54B52623.5010700@oracle.com>
	<54B528DF.8020507@oracle.com> <54B52A47.8030501@oracle.com>
	<54B53DAD.80407@oracle.com> <54B5692C.2000507@oracle.com>
Message-ID: <54B57265.3060307@oracle.com>

On 13.01.2015 21:51, Alan Bateman wrote:
> I think this looks okay. I see Mandy's comment about dropping the 
> dependency on sun.security.util and that would be good to do (but can 
> be another patch if you want).
ok. The new versions:
http://cr.openjdk.java.net/~serb/8056298/webrev.05/jdk
http://cr.openjdk.java.net/~serb/8056298/webrev.05/root
GET_CLASSLOADER_PERMISSION was removed.

-- 
Best regards, Sergey.



From mandy.chung at oracle.com  Tue Jan 13 19:43:26 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 13 Jan 2015 11:43:26 -0800
Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from
	the desktop module
In-Reply-To: <54B57265.3060307@oracle.com>
References: <54B42E9C.8010905@oracle.com> <54B431A8.5020904@oracle.com>
	<54B50432.5060300@oracle.com> <54B51A5D.2090708@oracle.com>
	<54B5231C.4090809@oracle.com> <54B52623.5010700@oracle.com>
	<54B528DF.8020507@oracle.com> <54B52A47.8030501@oracle.com>
	<54B53DAD.80407@oracle.com> <54B5692C.2000507@oracle.com>
	<54B57265.3060307@oracle.com>
Message-ID: <54B5755E.5010104@oracle.com>


On 1/13/2015 11:30 AM, Sergey Bylokhov wrote:
> On 13.01.2015 21:51, Alan Bateman wrote:
>> I think this looks okay. I see Mandy's comment about dropping the 
>> dependency on sun.security.util and that would be good to do (but can 
>> be another patch if you want).
> ok. The new versions:
> http://cr.openjdk.java.net/~serb/8056298/webrev.05/jdk
> http://cr.openjdk.java.net/~serb/8056298/webrev.05/root
> GET_CLASSLOADER_PERMISSION was removed.
>

Looks good.  Thanks for removing that dependency.

Mandy


From rkennke at redhat.com  Tue Jan 13 21:41:04 2015
From: rkennke at redhat.com (Roman Kennke)
Date: Tue, 13 Jan 2015 22:41:04 +0100
Subject: [PATCH] Fix Shark build in JDK9
In-Reply-To: <54AF66B9.8060900@oracle.com>
References: <1420641903.6838.9.camel@localhost>
	<54AD4C6B.1070702@oracle.com> <1420645301.6838.14.camel@localhost>
	<54AD5675.7010101@oracle.com> <1420647107.6838.15.camel@localhost>
	<54AD5BDF.1060401@oracle.com> <1420648161.6838.17.camel@localhost>
	<54AD639A.2060200@oracle.com> <1420662102.6838.23.camel@localhost>
	<54AE560B.3060200@oracle.com> <1420714881.6838.25.camel@localhost>
	<54AF66B9.8060900@oracle.com>
Message-ID: <1421185264.6838.46.camel@localhost>

Ok I think I found a way to avoid copying the whole #define block just
for one line. I define that line before (and empty in case of SHARK) and
use that inside the big #define.

http://cr.openjdk.java.net/~rkennke/shark-build-hotspot/webrev.02/

Please review and push if ok.

Roman

Am Freitag, den 09.01.2015 um 15:27 +1000 schrieb David Holmes:
> Hi Roman,
> 
> Commenting on the hotspot changes ...
> 
> On 8/01/2015 9:01 PM, Roman Kennke wrote:
> > Hi Erik,
> >
> > I'm CC-ing hotspot-dev for review of Hotspot code related changes.
> >
> > Yes, some additional changes to Hotspot are required. This is the full
> > set of changes needed to build and run Shark:
> >
> > http://cr.openjdk.java.net/~rkennke/shark-build-hotspot/webrev.01/
> >
> > In detail:
> >
> > - In the Makefile fix a typo to be able to build unzipped debuginfo.
> 
> Ok.
> 
> > - In ciTypeFlow.cpp only include some files and code only when building
> > C2. I don't think that code makes sense outside of C2. (That's the issue
> > that you've seen).
> 
> Looks okay but someone from compiler team needs to comment. There may be 
> other code that need adjusting.
> 
> > - In systemDictionary.cpp, exclude some code for Shark that creates and
> > checks native wrappers for method handle intrinsics. Invokedynamic stuff
> > is not yet implemented in Shark, so we can't do this.
> 
> Ok.
> 
> > - In allocation.hpp, exclude the operator overrides for new etc, LLVM
> > does allocations itself, and this would blow up.
> 
> I'm intrigued as the allocation strategy is not tied to the compiler but 
> pervasive to the whole VM runtime.
> 
> > - In handles.hpp and handles.inline.hpp, I added an argument
> > check_in_stack so that I can disable the in-stack check for the
> > SharkNativeWrapper. The SharkNativeWrapper is allocated on-heap and the
> > methodHandle inside the SharkNativeWrapper. I could have excluded that
> > check altogther using an #ifndef SHARK, but the way I implemented it
> > seemed more finegrained.
> 
> I'd prefer an ifndef SHARK rather than change the API.
> 
> Thanks,
> David
> 
> > - In SharkCompiler, I pulled out the code to initialize LLVM into its
> > own method, and the call to set_state(initialized) out of the
> > execution-engine-lock. This would otherwise complain about wrong
> > lock-ordering.
> > - In SharkRuntime, I changed the cast from intptr_t to oop to work with
> > the new picky compilers ;-)
> >
> > Please review.
> >
> > Thanks and best regards,
> > Roman
> >
> > Am Donnerstag, den 08.01.2015 um 11:03 +0100 schrieb Erik Joelsson:
> >> Hello Roman,
> >>
> >> This addition looks good to me.
> >>
> >> Thinking about what the others said, it might be inconvenient to have
> >> all this be pushed to different forests. I tried applying all the
> >> changes to jdk9/hs-rt, but I can't seem to build zeroshark.. Did you
> >> have more hotspot changes to be able to finish the build?
> >>
> >> My failure is:
> >>
> >>    ciTypeFlow.o
> >> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/ci/ciTypeFlow.cpp
> >> In file included from
> >> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/regmask.hpp:29:0,
> >>                    from
> >> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/compile.hpp:40,
> >>                    from
> >> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/ci/ciTypeFlow.cpp:38:
> >> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/optoreg.hpp:40:39:
> >> fatal error: adfiles/adGlobals_zero.hpp: No such file or directory
> >>
> >>   From what I can see, adfiles are not generated for zero or zeroshark
> >> builds, so the include should probably be removed.
> >>
> >> Would you still like me to push what you currently have to hs-rt?
> >>
> >> /Erik
> >>
> >> On 2015-01-07 21:21, Roman Kennke wrote:
> >>> Hi Erik,
> >>>
> >>> When I built Zero and Shark on my Raspberry Pi, I noticed another
> >>> problem when copying jvm.cfg into the right places. I fixed it in a
> >>> similar way as I did for the SA stuff:
> >>>
> >>> http://cr.openjdk.java.net/~rkennke/shark-build-jdk/webrev.02/
> >>>
> >>> I think that should be all for now.
> >>>
> >>> Please push that into JDK9 if you think that's fine.
> >>>
> >>> Best regards,
> >>> Roman
> >>>
> >>> Am Mittwoch, den 07.01.2015 um 17:49 +0100 schrieb Erik Joelsson:
> >>>> On 2015-01-07 17:29, Roman Kennke wrote:
> >>>>> Am Mittwoch, den 07.01.2015 um 17:16 +0100 schrieb Erik Joelsson:
> >>>>>> On 2015-01-07 17:11, Roman Kennke wrote:
> >>>>>>> Hi Erik,
> >>>>>>>
> >>>>>>> Do you have a bug for this?
> >>>>>>> No.
> >>>>>>>
> >>>>>>> I haven't pushed any changes to JDK in a while. Is it possible in the
> >>>>>>> meantime for me to create my own bugs? Otherwise, please file one for
> >>>>>>> me :-)
> >>>>>> You should be able to log in to https://bugs.openjdk.java.net and create
> >>>>>> bugs since you have an OpenJDK identity.
> >>>>> Done:
> >>>>>
> >>>>> https://bugs.openjdk.java.net/browse/JDK-8068598
> >>>>>
> >>>>> While I'm at it, is it possible for me to push my own changes (except
> >>>>> hotspot of course)? If yes, what needs to be done for regenerating the
> >>>>> configure files? Simply run autogen.sh in common/autoconf with whatever
> >>>>> version of autotools I have? Or doesn't it make sense at all b/c you
> >>>>> need to regenerate your closed scripts?
> >>>> It requires you to run common/autogen.sh yes, and that will require you
> >>>> to have autoconf 2.69 installed. But since we also need to regenerate
> >>>> the closed version, I can take care of the push for you. Will do it
> >>>> tomorrow if that's ok?
> >>>>
> >>>> /Erik
> >>>>> Roman
> >>>>>
> >>>
> >>
> >
> >




From david.dehaven at oracle.com  Wed Jan 14 03:09:06 2015
From: david.dehaven at oracle.com (David DeHaven)
Date: Tue, 13 Jan 2015 19:09:06 -0800
Subject: [8u60] RFR: 8043340: [macosx] Fix hard-wired paths to
	JavaVM.framework
In-Reply-To: <D4150E19-D909-4AA9-AD43-E00DA084D015@oracle.com>
References: <39719ED3-1F4E-4E6C-AA9F-A3C4766537B4@oracle.com>
	<54B3A38C.10909@oracle.com>
	<8B01B84D-5B6F-478E-ABF1-33F5ADE2F826@oracle.com>
	<08C63261-D594-404E-892B-BDE2898B505A@oracle.com>
	<D4150E19-D909-4AA9-AD43-E00DA084D015@oracle.com>
Message-ID: <4DC9B291-D302-428C-A5F7-177066C65991@oracle.com>


>> The --with-xcode-path argument is optional, you should also be able to build with Xcode 4 selected via "sudo xcode-select -switch /path/to/Xcode4.app". I leave MAS managed Xcode (currently 6) active as I'm constantly bouncing between projects and it's a hassle to have to remember to reset the active toolchain, so I thought it best to allow configure to be provided a path.
> 
> Ugh. I broke something along the way, this doesn't *quite* work.
> 
> xcrun complains with "xcrun: error: missing DEVELOPER_DIR path:"
> 
> I think I'm exporting an empty DEVELOPER_DIR. I shall fix and update.

TL;DR: Please review round 2:
http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v1/

(I removed generated-configure.sh to reduce the review size, it will be re-generated prior to pushing)


I've tested the following configuration scenarios (output from a shell script I cobbled together..)

field values:
XC6 - Xcode 6 installed in /Applications/Xcode.app
XC4 - Xcode 4 installed in some other dir
(empty) - Argument not passed to configure

Result meanings:
DEV_DIR set - configure succeeded, DEVELOPER_DIR was properly exported in spec.gmk
DEV_DIR NOT set - configure succeeded, DEVELOPER_DIR was not needed (XC4 must be selected to achieve this)
Configure failed - Configure properly failed when it detected Xcode > 4

"Selected" Xcode means version reported by xcode-select -p


| Xcode selected | --with-xcode-path | DEVELOPER_DIR     | result           |
-----------------------------------------------------------------------------
| XC4            |                   |                   | DEV_DIR NOT set  |
-----------------------------------------------------------------------------
| XC4            |                   | XC4               | DEV_DIR set      |
-----------------------------------------------------------------------------
| XC4            |                   | XC6               | Configure failed |
-----------------------------------------------------------------------------
| XC4            | XC4               |                   | DEV_DIR set      |
-----------------------------------------------------------------------------
| XC4            | XC4               | XC4               | DEV_DIR set      |
-----------------------------------------------------------------------------
| XC4            | XC4               | XC6               | DEV_DIR set      |
-----------------------------------------------------------------------------
| XC4            | XC6               |                   | Configure failed |
-----------------------------------------------------------------------------
| XC4            | XC6               | XC4               | Configure failed |
-----------------------------------------------------------------------------
| XC4            | XC6               | XC6               | Configure failed |
-----------------------------------------------------------------------------
| XC6            |                   |                   | Configure failed |
-----------------------------------------------------------------------------
| XC6            |                   | XC4               | DEV_DIR set      |
-----------------------------------------------------------------------------
| XC6            |                   | XC6               | Configure failed |
-----------------------------------------------------------------------------
| XC6            | XC4               |                   | DEV_DIR set      |
-----------------------------------------------------------------------------
| XC6            | XC4               | XC4               | DEV_DIR set      |
-----------------------------------------------------------------------------
| XC6            | XC4               | XC6               | DEV_DIR set      |
-----------------------------------------------------------------------------
| XC6            | XC6               |                   | Configure failed |
-----------------------------------------------------------------------------
| XC6            | XC6               | XC4               | Configure failed |
-----------------------------------------------------------------------------
| XC6            | XC6               | XC6               | Configure failed |
-----------------------------------------------------------------------------

All the results are as expected. Please note that --with-xcode-path overrides DEVELOPER_DIR, since that could be set in the environment.

(yeah, I went a little OCD on this...)

-DrD-



From david.holmes at oracle.com  Wed Jan 14 07:22:02 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 14 Jan 2015 17:22:02 +1000
Subject: [PATCH] Fix Shark build in JDK9
In-Reply-To: <1421185264.6838.46.camel@localhost>
References: <1420641903.6838.9.camel@localhost>		<54AD4C6B.1070702@oracle.com>
	<1420645301.6838.14.camel@localhost>		<54AD5675.7010101@oracle.com>
	<1420647107.6838.15.camel@localhost>		<54AD5BDF.1060401@oracle.com>
	<1420648161.6838.17.camel@localhost>		<54AD639A.2060200@oracle.com>
	<1420662102.6838.23.camel@localhost>		<54AE560B.3060200@oracle.com>
	<1420714881.6838.25.camel@localhost>	 <54AF66B9.8060900@oracle.com>
	<1421185264.6838.46.camel@localhost>
Message-ID: <54B6191A.9040800@oracle.com>

Hi Roman,

On 14/01/2015 7:41 AM, Roman Kennke wrote:
> Ok I think I found a way to avoid copying the whole #define block just
> for one line. I define that line before (and empty in case of SHARK) and
> use that inside the big #define.
>
> http://cr.openjdk.java.net/~rkennke/shark-build-hotspot/webrev.02/

Can you use SHARK_ONLY or NOT_SHARK macros? I think that would be cleaner.

Still need a second hotspot reviewer - preferably someone from compiler 
team.

And was a bug filed for this?

Thanks,
David

> Please review and push if ok.
>
> Roman
>
> Am Freitag, den 09.01.2015 um 15:27 +1000 schrieb David Holmes:
>> Hi Roman,
>>
>> Commenting on the hotspot changes ...
>>
>> On 8/01/2015 9:01 PM, Roman Kennke wrote:
>>> Hi Erik,
>>>
>>> I'm CC-ing hotspot-dev for review of Hotspot code related changes.
>>>
>>> Yes, some additional changes to Hotspot are required. This is the full
>>> set of changes needed to build and run Shark:
>>>
>>> http://cr.openjdk.java.net/~rkennke/shark-build-hotspot/webrev.01/
>>>
>>> In detail:
>>>
>>> - In the Makefile fix a typo to be able to build unzipped debuginfo.
>>
>> Ok.
>>
>>> - In ciTypeFlow.cpp only include some files and code only when building
>>> C2. I don't think that code makes sense outside of C2. (That's the issue
>>> that you've seen).
>>
>> Looks okay but someone from compiler team needs to comment. There may be
>> other code that need adjusting.
>>
>>> - In systemDictionary.cpp, exclude some code for Shark that creates and
>>> checks native wrappers for method handle intrinsics. Invokedynamic stuff
>>> is not yet implemented in Shark, so we can't do this.
>>
>> Ok.
>>
>>> - In allocation.hpp, exclude the operator overrides for new etc, LLVM
>>> does allocations itself, and this would blow up.
>>
>> I'm intrigued as the allocation strategy is not tied to the compiler but
>> pervasive to the whole VM runtime.
>>
>>> - In handles.hpp and handles.inline.hpp, I added an argument
>>> check_in_stack so that I can disable the in-stack check for the
>>> SharkNativeWrapper. The SharkNativeWrapper is allocated on-heap and the
>>> methodHandle inside the SharkNativeWrapper. I could have excluded that
>>> check altogther using an #ifndef SHARK, but the way I implemented it
>>> seemed more finegrained.
>>
>> I'd prefer an ifndef SHARK rather than change the API.
>>
>> Thanks,
>> David
>>
>>> - In SharkCompiler, I pulled out the code to initialize LLVM into its
>>> own method, and the call to set_state(initialized) out of the
>>> execution-engine-lock. This would otherwise complain about wrong
>>> lock-ordering.
>>> - In SharkRuntime, I changed the cast from intptr_t to oop to work with
>>> the new picky compilers ;-)
>>>
>>> Please review.
>>>
>>> Thanks and best regards,
>>> Roman
>>>
>>> Am Donnerstag, den 08.01.2015 um 11:03 +0100 schrieb Erik Joelsson:
>>>> Hello Roman,
>>>>
>>>> This addition looks good to me.
>>>>
>>>> Thinking about what the others said, it might be inconvenient to have
>>>> all this be pushed to different forests. I tried applying all the
>>>> changes to jdk9/hs-rt, but I can't seem to build zeroshark.. Did you
>>>> have more hotspot changes to be able to finish the build?
>>>>
>>>> My failure is:
>>>>
>>>>     ciTypeFlow.o
>>>> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/ci/ciTypeFlow.cpp
>>>> In file included from
>>>> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/regmask.hpp:29:0,
>>>>                     from
>>>> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/compile.hpp:40,
>>>>                     from
>>>> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/ci/ciTypeFlow.cpp:38:
>>>> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/optoreg.hpp:40:39:
>>>> fatal error: adfiles/adGlobals_zero.hpp: No such file or directory
>>>>
>>>>    From what I can see, adfiles are not generated for zero or zeroshark
>>>> builds, so the include should probably be removed.
>>>>
>>>> Would you still like me to push what you currently have to hs-rt?
>>>>
>>>> /Erik
>>>>
>>>> On 2015-01-07 21:21, Roman Kennke wrote:
>>>>> Hi Erik,
>>>>>
>>>>> When I built Zero and Shark on my Raspberry Pi, I noticed another
>>>>> problem when copying jvm.cfg into the right places. I fixed it in a
>>>>> similar way as I did for the SA stuff:
>>>>>
>>>>> http://cr.openjdk.java.net/~rkennke/shark-build-jdk/webrev.02/
>>>>>
>>>>> I think that should be all for now.
>>>>>
>>>>> Please push that into JDK9 if you think that's fine.
>>>>>
>>>>> Best regards,
>>>>> Roman
>>>>>
>>>>> Am Mittwoch, den 07.01.2015 um 17:49 +0100 schrieb Erik Joelsson:
>>>>>> On 2015-01-07 17:29, Roman Kennke wrote:
>>>>>>> Am Mittwoch, den 07.01.2015 um 17:16 +0100 schrieb Erik Joelsson:
>>>>>>>> On 2015-01-07 17:11, Roman Kennke wrote:
>>>>>>>>> Hi Erik,
>>>>>>>>>
>>>>>>>>> Do you have a bug for this?
>>>>>>>>> No.
>>>>>>>>>
>>>>>>>>> I haven't pushed any changes to JDK in a while. Is it possible in the
>>>>>>>>> meantime for me to create my own bugs? Otherwise, please file one for
>>>>>>>>> me :-)
>>>>>>>> You should be able to log in to https://bugs.openjdk.java.net and create
>>>>>>>> bugs since you have an OpenJDK identity.
>>>>>>> Done:
>>>>>>>
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8068598
>>>>>>>
>>>>>>> While I'm at it, is it possible for me to push my own changes (except
>>>>>>> hotspot of course)? If yes, what needs to be done for regenerating the
>>>>>>> configure files? Simply run autogen.sh in common/autoconf with whatever
>>>>>>> version of autotools I have? Or doesn't it make sense at all b/c you
>>>>>>> need to regenerate your closed scripts?
>>>>>> It requires you to run common/autogen.sh yes, and that will require you
>>>>>> to have autoconf 2.69 installed. But since we also need to regenerate
>>>>>> the closed version, I can take care of the push for you. Will do it
>>>>>> tomorrow if that's ok?
>>>>>>
>>>>>> /Erik
>>>>>>> Roman
>>>>>>>
>>>>>
>>>>
>>>
>>>
>
>


From erik.joelsson at oracle.com  Wed Jan 14 08:33:28 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 14 Jan 2015 09:33:28 +0100
Subject: [8u60] RFR: 8043340: [macosx] Fix hard-wired paths to
	JavaVM.framework
In-Reply-To: <4DC9B291-D302-428C-A5F7-177066C65991@oracle.com>
References: <39719ED3-1F4E-4E6C-AA9F-A3C4766537B4@oracle.com>
	<54B3A38C.10909@oracle.com>
	<8B01B84D-5B6F-478E-ABF1-33F5ADE2F826@oracle.com>
	<08C63261-D594-404E-892B-BDE2898B505A@oracle.com>
	<D4150E19-D909-4AA9-AD43-E00DA084D015@oracle.com>
	<4DC9B291-D302-428C-A5F7-177066C65991@oracle.com>
Message-ID: <54B629D8.8070700@oracle.com>

Hello,

This looks good to me. Thanks for the detailed table!

/Erik

On 2015-01-14 04:09, David DeHaven wrote:
>>> The --with-xcode-path argument is optional, you should also be able to build with Xcode 4 selected via "sudo xcode-select -switch /path/to/Xcode4.app". I leave MAS managed Xcode (currently 6) active as I'm constantly bouncing between projects and it's a hassle to have to remember to reset the active toolchain, so I thought it best to allow configure to be provided a path.
>> Ugh. I broke something along the way, this doesn't *quite* work.
>>
>> xcrun complains with "xcrun: error: missing DEVELOPER_DIR path:"
>>
>> I think I'm exporting an empty DEVELOPER_DIR. I shall fix and update.
> TL;DR: Please review round 2:
> http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v1/
>
> (I removed generated-configure.sh to reduce the review size, it will be re-generated prior to pushing)
>
>
> I've tested the following configuration scenarios (output from a shell script I cobbled together..)
>
> field values:
> XC6 - Xcode 6 installed in /Applications/Xcode.app
> XC4 - Xcode 4 installed in some other dir
> (empty) - Argument not passed to configure
>
> Result meanings:
> DEV_DIR set - configure succeeded, DEVELOPER_DIR was properly exported in spec.gmk
> DEV_DIR NOT set - configure succeeded, DEVELOPER_DIR was not needed (XC4 must be selected to achieve this)
> Configure failed - Configure properly failed when it detected Xcode > 4
>
> "Selected" Xcode means version reported by xcode-select -p
>
>
> | Xcode selected | --with-xcode-path | DEVELOPER_DIR     | result           |
> -----------------------------------------------------------------------------
> | XC4            |                   |                   | DEV_DIR NOT set  |
> -----------------------------------------------------------------------------
> | XC4            |                   | XC4               | DEV_DIR set      |
> -----------------------------------------------------------------------------
> | XC4            |                   | XC6               | Configure failed |
> -----------------------------------------------------------------------------
> | XC4            | XC4               |                   | DEV_DIR set      |
> -----------------------------------------------------------------------------
> | XC4            | XC4               | XC4               | DEV_DIR set      |
> -----------------------------------------------------------------------------
> | XC4            | XC4               | XC6               | DEV_DIR set      |
> -----------------------------------------------------------------------------
> | XC4            | XC6               |                   | Configure failed |
> -----------------------------------------------------------------------------
> | XC4            | XC6               | XC4               | Configure failed |
> -----------------------------------------------------------------------------
> | XC4            | XC6               | XC6               | Configure failed |
> -----------------------------------------------------------------------------
> | XC6            |                   |                   | Configure failed |
> -----------------------------------------------------------------------------
> | XC6            |                   | XC4               | DEV_DIR set      |
> -----------------------------------------------------------------------------
> | XC6            |                   | XC6               | Configure failed |
> -----------------------------------------------------------------------------
> | XC6            | XC4               |                   | DEV_DIR set      |
> -----------------------------------------------------------------------------
> | XC6            | XC4               | XC4               | DEV_DIR set      |
> -----------------------------------------------------------------------------
> | XC6            | XC4               | XC6               | DEV_DIR set      |
> -----------------------------------------------------------------------------
> | XC6            | XC6               |                   | Configure failed |
> -----------------------------------------------------------------------------
> | XC6            | XC6               | XC4               | Configure failed |
> -----------------------------------------------------------------------------
> | XC6            | XC6               | XC6               | Configure failed |
> -----------------------------------------------------------------------------
>
> All the results are as expected. Please note that --with-xcode-path overrides DEVELOPER_DIR, since that could be set in the environment.
>
> (yeah, I went a little OCD on this...)
>
> -DrD-
>



From erik.joelsson at oracle.com  Wed Jan 14 08:35:17 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 14 Jan 2015 09:35:17 +0100
Subject: [PATCH] Fix Shark build in JDK9
In-Reply-To: <54B6191A.9040800@oracle.com>
References: <1420641903.6838.9.camel@localhost>		<54AD4C6B.1070702@oracle.com>
	<1420645301.6838.14.camel@localhost>		<54AD5675.7010101@oracle.com>
	<1420647107.6838.15.camel@localhost>		<54AD5BDF.1060401@oracle.com>
	<1420648161.6838.17.camel@localhost>		<54AD639A.2060200@oracle.com>
	<1420662102.6838.23.camel@localhost>		<54AE560B.3060200@oracle.com>
	<1420714881.6838.25.camel@localhost>	 <54AF66B9.8060900@oracle.com>
	<1421185264.6838.46.camel@localhost> <54B6191A.9040800@oracle.com>
Message-ID: <54B62A45.2030600@oracle.com>


On 2015-01-14 08:22, David Holmes wrote:
> Hi Roman,
>
> On 14/01/2015 7:41 AM, Roman Kennke wrote:
>> Ok I think I found a way to avoid copying the whole #define block just
>> for one line. I define that line before (and empty in case of SHARK) and
>> use that inside the big #define.
>>
>> http://cr.openjdk.java.net/~rkennke/shark-build-hotspot/webrev.02/
>
> Can you use SHARK_ONLY or NOT_SHARK macros? I think that would be 
> cleaner.
>
> Still need a second hotspot reviewer - preferably someone from 
> compiler team.
>
> And was a bug filed for this?
>
A bug was filed at least: https://bugs.openjdk.java.net/browse/JDK-8068598

I promised to handle the push when it's all reviewed.

/Erik

> Thanks,
> David
>
>> Please review and push if ok.
>>
>> Roman
>>
>> Am Freitag, den 09.01.2015 um 15:27 +1000 schrieb David Holmes:
>>> Hi Roman,
>>>
>>> Commenting on the hotspot changes ...
>>>
>>> On 8/01/2015 9:01 PM, Roman Kennke wrote:
>>>> Hi Erik,
>>>>
>>>> I'm CC-ing hotspot-dev for review of Hotspot code related changes.
>>>>
>>>> Yes, some additional changes to Hotspot are required. This is the full
>>>> set of changes needed to build and run Shark:
>>>>
>>>> http://cr.openjdk.java.net/~rkennke/shark-build-hotspot/webrev.01/
>>>>
>>>> In detail:
>>>>
>>>> - In the Makefile fix a typo to be able to build unzipped debuginfo.
>>>
>>> Ok.
>>>
>>>> - In ciTypeFlow.cpp only include some files and code only when 
>>>> building
>>>> C2. I don't think that code makes sense outside of C2. (That's the 
>>>> issue
>>>> that you've seen).
>>>
>>> Looks okay but someone from compiler team needs to comment. There 
>>> may be
>>> other code that need adjusting.
>>>
>>>> - In systemDictionary.cpp, exclude some code for Shark that creates 
>>>> and
>>>> checks native wrappers for method handle intrinsics. Invokedynamic 
>>>> stuff
>>>> is not yet implemented in Shark, so we can't do this.
>>>
>>> Ok.
>>>
>>>> - In allocation.hpp, exclude the operator overrides for new etc, LLVM
>>>> does allocations itself, and this would blow up.
>>>
>>> I'm intrigued as the allocation strategy is not tied to the compiler 
>>> but
>>> pervasive to the whole VM runtime.
>>>
>>>> - In handles.hpp and handles.inline.hpp, I added an argument
>>>> check_in_stack so that I can disable the in-stack check for the
>>>> SharkNativeWrapper. The SharkNativeWrapper is allocated on-heap and 
>>>> the
>>>> methodHandle inside the SharkNativeWrapper. I could have excluded that
>>>> check altogther using an #ifndef SHARK, but the way I implemented it
>>>> seemed more finegrained.
>>>
>>> I'd prefer an ifndef SHARK rather than change the API.
>>>
>>> Thanks,
>>> David
>>>
>>>> - In SharkCompiler, I pulled out the code to initialize LLVM into its
>>>> own method, and the call to set_state(initialized) out of the
>>>> execution-engine-lock. This would otherwise complain about wrong
>>>> lock-ordering.
>>>> - In SharkRuntime, I changed the cast from intptr_t to oop to work 
>>>> with
>>>> the new picky compilers ;-)
>>>>
>>>> Please review.
>>>>
>>>> Thanks and best regards,
>>>> Roman
>>>>
>>>> Am Donnerstag, den 08.01.2015 um 11:03 +0100 schrieb Erik Joelsson:
>>>>> Hello Roman,
>>>>>
>>>>> This addition looks good to me.
>>>>>
>>>>> Thinking about what the others said, it might be inconvenient to have
>>>>> all this be pushed to different forests. I tried applying all the
>>>>> changes to jdk9/hs-rt, but I can't seem to build zeroshark.. Did you
>>>>> have more hotspot changes to be able to finish the build?
>>>>>
>>>>> My failure is:
>>>>>
>>>>>     ciTypeFlow.o
>>>>> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/ci/ciTypeFlow.cpp
>>>>> In file included from
>>>>> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/regmask.hpp:29:0,
>>>>>                     from
>>>>> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/compile.hpp:40,
>>>>>                     from
>>>>> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/ci/ciTypeFlow.cpp:38:
>>>>> /localhome/hg/jdk9-hs-rt/hotspot/src/share/vm/opto/optoreg.hpp:40:39:
>>>>> fatal error: adfiles/adGlobals_zero.hpp: No such file or directory
>>>>>
>>>>>    From what I can see, adfiles are not generated for zero or 
>>>>> zeroshark
>>>>> builds, so the include should probably be removed.
>>>>>
>>>>> Would you still like me to push what you currently have to hs-rt?
>>>>>
>>>>> /Erik
>>>>>
>>>>> On 2015-01-07 21:21, Roman Kennke wrote:
>>>>>> Hi Erik,
>>>>>>
>>>>>> When I built Zero and Shark on my Raspberry Pi, I noticed another
>>>>>> problem when copying jvm.cfg into the right places. I fixed it in a
>>>>>> similar way as I did for the SA stuff:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~rkennke/shark-build-jdk/webrev.02/
>>>>>>
>>>>>> I think that should be all for now.
>>>>>>
>>>>>> Please push that into JDK9 if you think that's fine.
>>>>>>
>>>>>> Best regards,
>>>>>> Roman
>>>>>>
>>>>>> Am Mittwoch, den 07.01.2015 um 17:49 +0100 schrieb Erik Joelsson:
>>>>>>> On 2015-01-07 17:29, Roman Kennke wrote:
>>>>>>>> Am Mittwoch, den 07.01.2015 um 17:16 +0100 schrieb Erik Joelsson:
>>>>>>>>> On 2015-01-07 17:11, Roman Kennke wrote:
>>>>>>>>>> Hi Erik,
>>>>>>>>>>
>>>>>>>>>> Do you have a bug for this?
>>>>>>>>>> No.
>>>>>>>>>>
>>>>>>>>>> I haven't pushed any changes to JDK in a while. Is it 
>>>>>>>>>> possible in the
>>>>>>>>>> meantime for me to create my own bugs? Otherwise, please file 
>>>>>>>>>> one for
>>>>>>>>>> me :-)
>>>>>>>>> You should be able to log in to https://bugs.openjdk.java.net 
>>>>>>>>> and create
>>>>>>>>> bugs since you have an OpenJDK identity.
>>>>>>>> Done:
>>>>>>>>
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8068598
>>>>>>>>
>>>>>>>> While I'm at it, is it possible for me to push my own changes 
>>>>>>>> (except
>>>>>>>> hotspot of course)? If yes, what needs to be done for 
>>>>>>>> regenerating the
>>>>>>>> configure files? Simply run autogen.sh in common/autoconf with 
>>>>>>>> whatever
>>>>>>>> version of autotools I have? Or doesn't it make sense at all 
>>>>>>>> b/c you
>>>>>>>> need to regenerate your closed scripts?
>>>>>>> It requires you to run common/autogen.sh yes, and that will 
>>>>>>> require you
>>>>>>> to have autoconf 2.69 installed. But since we also need to 
>>>>>>> regenerate
>>>>>>> the closed version, I can take care of the push for you. Will do it
>>>>>>> tomorrow if that's ok?
>>>>>>>
>>>>>>> /Erik
>>>>>>>> Roman
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>
>>



From magnus.ihse.bursie at oracle.com  Wed Jan 14 13:27:15 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 14 Jan 2015 14:27:15 +0100
Subject: RFR: AARCH64: Top-level JDK changes
In-Reply-To: <54B4D82B.3050608@oracle.com>
References: <545CFFA9.4070107@redhat.com>	<545D0290.5080307@oracle.com>	<CA+3eh13Byz2VWW6GA_X00np7DU=-xp7nmA-t1iCygU4EU7FOjA@mail.gmail.com>
	<54B34E20.5030506@oracle.com> <54B3B4CE.8060804@oracle.com>
	<54B4D82B.3050608@oracle.com>
Message-ID: <54B66EB3.3020601@oracle.com>

On 2015-01-13 09:32, Dean Long wrote:
> On 1/12/2015 3:49 AM, Magnus Ihse Bursie wrote:
>> On 2015-01-12 05:31, Dean Long wrote:
>>> I found a small problem with the new config.sub wrapper.  It works 
>>> with the bash shell but not with the dash shell.
>>> The problem seems to be with this line:
>>>
>>>     result=`. $DIR/autoconf-config.sub $sub_args "$@"`
>>>
>>> "dash" doesn't seem to support args passed with ".", so $sub_args 
>>> "$@" are ignored.
>>
>> bash is the required shell for running configure. We do not support 
>> non-bash shells. In fact, we go to lengths to try to ensure that we 
>> are indeed running under bash.
>>
>> /Magnus
> I was thinking 'bash configure' was enough, but it turns out 
> 'CONFIG_SHELL=bash bash configure' gives better results.

Hm, that's interesting. We were attempting to automatically use bash in 
the real configure script, regardless of what shell the user had to 
start the top-level configure wrapper.

If you try the patch below, does it work better when you run "dash 
configure"?

diff --git a/common/autoconf/configure b/common/autoconf/configure
--- a/common/autoconf/configure
+++ b/common/autoconf/configure
@@ -36,6 +36,13 @@
    shift
  fi

+if test "x$BASH" = x; then
+  echo "Error: This script must be run using bash." 1>&2
+  exit 1
+fi
+# Force autoconf to use bash
+export CONFIG_SHELL=$BASH
+
  conf_script_dir="$TOPDIR/common/autoconf"

  if [ "$CUSTOM_CONFIG_DIR" = "" ]; then

/Magnus



From sean.coffey at oracle.com  Wed Jan 14 13:31:20 2015
From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=)
Date: Wed, 14 Jan 2015 13:31:20 +0000
Subject: [8u40] Request for review and approval: 8068485: Update references
	of download.oracle.com to docs.oracle.com in javadoc makefile
In-Reply-To: <54B4D1E0.6090006@oracle.com>
References: <65fa6eb7-edab-410f-a57e-ae8f5d782a38@default>
	<54B4D1E0.6090006@oracle.com>
Message-ID: <54B66FA8.4040203@oracle.com>

Hi Bhavesh,

Approved for jdk8u-dev. I'll help push this patch and the other 2 doc 
related ones (8068491, 8068495) to jdk8u-dev. I'll also work with you on 
getting these into 8u40.

regards,
Sean.

On 13/01/15 08:05, Erik Joelsson wrote:
> Looks good to me.
>
> /Erik
>
> On 2015-01-13 00:40, Bhavesh Patel wrote:
>> Hi,
>>      In the javadoc makefile, there are references to 
>> http://download.oracle.com. This automatically gets redirected to 
>> http://docs.oracle.com. These references needs to be updated to point 
>> to https://docs.oracle.com.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8068485
>> Webrev: http://cr.openjdk.java.net/~bpatel/8068485/webrev.00/
>>
>>      This fix is for 8u40. Can you please review it?
>>
>> Thanks,
>> Bhavesh.
>



From mbd at terma.com  Wed Jan 14 14:35:25 2015
From: mbd at terma.com (Mads Bondo Dydensborg)
Date: Wed, 14 Jan 2015 14:35:25 +0000
Subject: Problems building jdk8 in Windows - stalls at hotspot, surprisingly
	continues, refuses to link
Message-ID: <BCECF94448C3704799FDEB187695635BB613B4@EXCH01.terma.com>

Hi there

I am trying to build jdk8 on Windows 7 64 bit, using cygwin and MS Visual Studio Express. I am pretty experienced in building stuff in Unix/Linux, but Windows is new to me.

Principally, I am using the guide at http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html, but for reasons I cannot fathom, I am unable to retrieve the sources using hg. So, I am using the source package that can be found on this page: http://download.java.net/openjdk/jdk8/ (132-03).

I am using 

$ java -version
java version "1.7.0_72"
Java(TM) SE Runtime Environment (build 1.7.0_72-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.72-b04, mixed mode)

As the boot Java, freetype is installed, a copy of the .dll.a file has been made.

I believe I am past the configure step, with the following final output from it:
====================================================
A new configuration has been successfully created in
/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/build/windows-x86-normal-server-release
using configure arguments '--with-target-bits=32'.
Configuration summary:
* Debug level:??? release
* JDK variant:??? normal
* JVM variants:?? server
* OpenJDK target: OS: windows, CPU architecture: x86, address length: 32
Tools summary:
* Environment:??? cygwin version 1.7.17(0.262/5/3) (root at /cygdrive/c/apps/cygwin)
* Boot JDK:?????? java version "1.7.0_72"? Java(TM) SE Runtime Environment (build 1.7.0_72-b14)? Java HotSpot(TM) 64-Bit Server VM (build 24.72-b04, mixed mode)?? (at /cygdrive/c/progra~1/java/jdk17~1.0_7)
* C Compiler:???? Microsoft CL.EXE version 16.00.30319.01 (at /cygdrive/c/progra~2/micros~1.0/vc/bin/cl)
* C++ Compiler:?? Microsoft CL.EXE version 16.00.30319.01 (at /cygdrive/c/progra~2/micros~1.0/vc/bin/cl)
Build performance summary:
* Cores to use:?? 7
* Memory limit:?? 15950 MB
* ccache status:? not available for your system

However, when I try to build, the results are not uplifting. I have tried a couple of different targets, but common for all I have tried, is that they stall/hang somewhere while building the hotspot target. Say, e.g, when trying the JDK:

make LOG=trace JOBS=1 jdk

it will stall here:
+ nmake -NOLOGO -f C:/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/hotspot/make/windows/build.make Variant=compiler2 'WorkSpace=C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\hotspot' 'BootStrapDir=C:\progra~1\java\jdk17~1.0_7' BuildUser=mbd ARCH=x86 BUILDARCH=i486 Platform_arch=x86 Platform_arch_model=x86_32 ENABLE_FULL_DEBUG_SYMBOLS=1 ZIP_DEBUGINFO_FILES=1 'RM=rm -f' ZIPEXE=zip JDK_MKTG_VERSION=8.0 JDK_MAJOR_VER=1 JDK_MINOR_VER=8 JDK_MICRO_VER=0 JDK_BUILD_NUMBER=0 BUILD_WIN_SA=1 'CXX=C:\progra~2\micros~1.0\vc\bin\cl.exe' 'LD=C:\progra~2\micros~1.0\vc\bin\link.exe' 'RC=C:\progra~2\micros~3\windows\v7.0a\bin\rc.exe' 'MT=C:\progra~2\micros~3\windows\v7.0a\bin\mt.exe' 'BOOTDIR=C:\progra~1\java\jdk17~1.0_7' 'OUTPUTDIR=C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\build\windows-x86-normal-server-release\hotspot' 'GAMMADIR=C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\hotspot' MAKE_VERBOSE=y HOTSPOT_RELEASE_VERSION=25.0-b70 JRE_RELEASE_VERSION=1.8.0-internal-mbd_2015_01_14_13_33-b00 HOTSPOT_BUILD_VERSION= product?
??????? cd windows_i486_compiler2
??????? nmake -nologo -f C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\hotspot\make\windows\makefiles\top.make BUILD_FLAVOR=product ARCH=x86
nmake in ./generated
??????? cd generated && "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\nmake.EXE" -NOLOGO -f C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\hotspot\make\windows\makefiles\generated.make? DIR=.\generated BUILD_FLAVOR=product

Now, I thought it was hanging, but while I tried to figure out more on the web, this particular build suddenly - after a stall about 30-45 minutes - proceeded, and eventually, after a few minutes, produced:

C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"25.0-b70\"" /D "JRE_RELEASE_VERSION=\"1.8.0-internal-mbd_2015_01_14_13_33-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"mbd\"" /D "HOTSPOT_VM_DISTRO=\"OpenJDK\"" /I "..\generated"  /I "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\hotspot\src\share\vm"  /I "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\hotspot\src\share\vm\precompiled"  /I "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\hotspot\src\share\vm\prims"  /I "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\hotspot\src\os\windows\vm"  /I "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c ..\generated\adfiles\ad_x86_32.cpp ..\generated\adfiles\ad_x86_32_clone.cpp ..\generated\adfiles\ad_x86_32_expand.cpp ..\generated\adfiles\ad_x86_32_format.cpp ..\generated\adfiles\ad_x86_32_gen.cpp ..\generated\adfiles\ad_x86_32_misc.cpp ..\generated\adfiles\ad_x86_32_peephole.cpp ..\generated\adfiles\ad_x86_32_pipeline.cpp ..\generated\adfiles\dfa_x86_32.cpp
ad_x86_32.cpp
ad_x86_32_clone.cpp
ad_x86_32_expand.cpp
ad_x86_32_format.cpp
ad_x86_32_gen.cpp
ad_x86_32_misc.cpp
ad_x86_32_peephole.cpp
ad_x86_32_pipeline.cpp
dfa_x86_32.cpp
        sh C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\hotspot/make/windows/build_vm_def.sh
        C:\progra~2\micros~1.0\vc\bin\link.exe @C:\apps\cygwin\tmp\nm76D6.tmp
   Creating library jvm.lib and object jvm.exp

LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt
NMAKE : fatal error U1077: 'C:\progra~2\micros~1.0\vc\bin\link.exe' : return code '0x463'
Stop.
NMAKE : fatal error U1077: 'cd' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\nmake.EXE"' : return code '0x2'
Stop.
Makefile:216: recipe for target `generic_build2' failed
make[3]: *** [generic_build2] Error 2
make[3]: Leaving directory `/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/hotspot/make'
Makefile:167: recipe for target `product' failed
make[2]: *** [product] Error 2
make[2]: Leaving directory `/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/hotspot/make'
HotspotWrapper.gmk:44: recipe for target `/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/build/windows-x86-normal-server-release/hotspot/_hotspot.timestamp' failed
make[1]: *** [/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/build/windows-x86-normal-server-release/hotspot/_hotspot.timestamp] Error 2
make[1]: Leaving directory `/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/make'
/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk//make/Main.gmk:108: recipe for target `hotspot-only' failed
make: *** [hotspot-only] Error 2

I am a bit stumped at this time, and would much appreciate a hand. I have the config.log and build.log preserved, but at this point, I did not want to spam the list more than necessary.

Any help/ideas/suggestions much appreciated.

Thanks

Mads


From Roger.Riggs at Oracle.com  Wed Jan 14 14:49:21 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 14 Jan 2015 09:49:21 -0500
Subject: Problems building jdk8 in Windows - stalls at hotspot,
	surprisingly continues, refuses to link
In-Reply-To: <BCECF94448C3704799FDEB187695635BB613B4@EXCH01.terma.com>
References: <BCECF94448C3704799FDEB187695635BB613B4@EXCH01.terma.com>
Message-ID: <54B681F1.3010504@Oracle.com>

Hi,

I saw that error message "COFF: file invalid or corrupt" using VS 2010
before I installed the Visual Studio 2010_x86_sp1.  Worked ok after.

$.02, Roger

On 1/14/2015 9:35 AM, Mads Bondo Dydensborg wrote:
> Hi there
>
> I am trying to build jdk8 on Windows 7 64 bit, using cygwin and MS Visual Studio Express. I am pretty experienced in building stuff in Unix/Linux, but Windows is new to me.
>
> Principally, I am using the guide at http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html, but for reasons I cannot fathom, I am unable to retrieve the sources using hg. So, I am using the source package that can be found on this page: http://download.java.net/openjdk/jdk8/ (132-03).
>
> I am using
>
> $ java -version
> java version "1.7.0_72"
> Java(TM) SE Runtime Environment (build 1.7.0_72-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 24.72-b04, mixed mode)
>
> As the boot Java, freetype is installed, a copy of the .dll.a file has been made.
>
> I believe I am past the configure step, with the following final output from it:
> ====================================================
> A new configuration has been successfully created in
> /cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/build/windows-x86-normal-server-release
> using configure arguments '--with-target-bits=32'.
> Configuration summary:
> * Debug level:    release
> * JDK variant:    normal
> * JVM variants:   server
> * OpenJDK target: OS: windows, CPU architecture: x86, address length: 32
> Tools summary:
> * Environment:    cygwin version 1.7.17(0.262/5/3) (root at /cygdrive/c/apps/cygwin)
> * Boot JDK:       java version "1.7.0_72"  Java(TM) SE Runtime Environment (build 1.7.0_72-b14)  Java HotSpot(TM) 64-Bit Server VM (build 24.72-b04, mixed mode)   (at /cygdrive/c/progra~1/java/jdk17~1.0_7)
> * C Compiler:     Microsoft CL.EXE version 16.00.30319.01 (at /cygdrive/c/progra~2/micros~1.0/vc/bin/cl)
> * C++ Compiler:   Microsoft CL.EXE version 16.00.30319.01 (at /cygdrive/c/progra~2/micros~1.0/vc/bin/cl)
> Build performance summary:
> * Cores to use:   7
> * Memory limit:   15950 MB
> * ccache status:  not available for your system
>
> However, when I try to build, the results are not uplifting. I have tried a couple of different targets, but common for all I have tried, is that they stall/hang somewhere while building the hotspot target. Say, e.g, when trying the JDK:
>
> make LOG=trace JOBS=1 jdk
>
> it will stall here:
> + nmake -NOLOGO -f C:/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/hotspot/make/windows/build.make Variant=compiler2 'WorkSpace=C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\hotspot' 'BootStrapDir=C:\progra~1\java\jdk17~1.0_7' BuildUser=mbd ARCH=x86 BUILDARCH=i486 Platform_arch=x86 Platform_arch_model=x86_32 ENABLE_FULL_DEBUG_SYMBOLS=1 ZIP_DEBUGINFO_FILES=1 'RM=rm -f' ZIPEXE=zip JDK_MKTG_VERSION=8.0 JDK_MAJOR_VER=1 JDK_MINOR_VER=8 JDK_MICRO_VER=0 JDK_BUILD_NUMBER=0 BUILD_WIN_SA=1 'CXX=C:\progra~2\micros~1.0\vc\bin\cl.exe' 'LD=C:\progra~2\micros~1.0\vc\bin\link.exe' 'RC=C:\progra~2\micros~3\windows\v7.0a\bin\rc.exe' 'MT=C:\progra~2\micros~3\windows\v7.0a\bin\mt.exe' 'BOOTDIR=C:\progra~1\java\jdk17~1.0_7' 'OUTPUTDIR=C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\build\windows-x86-normal-server-release\hotspot' 'GAMMADIR=C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\hotspot' MAKE_VERBOSE=y HOTSPOT_RELEASE_VERSION=25.0-b70 JRE_RELEASE_VERSION=1.8.0-internal-mbd_2015_01_14_13_33-b00 HOTSPOT_BUILD_VERSION= product
>          cd windows_i486_compiler2
>          nmake -nologo -f C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\hotspot\make\windows\makefiles\top.make BUILD_FLAVOR=product ARCH=x86
> nmake in ./generated
>          cd generated && "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\nmake.EXE" -NOLOGO -f C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\hotspot\make\windows\makefiles\generated.make  DIR=.\generated BUILD_FLAVOR=product
>
> Now, I thought it was hanging, but while I tried to figure out more on the web, this particular build suddenly - after a stall about 30-45 minutes - proceeded, and eventually, after a few minutes, produced:
>
> C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"25.0-b70\"" /D "JRE_RELEASE_VERSION=\"1.8.0-internal-mbd_2015_01_14_13_33-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"mbd\"" /D "HOTSPOT_VM_DISTRO=\"OpenJDK\"" /I "..\generated"  /I "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\hotspot\src\share\vm"  /I "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\hotspot\src\share\vm\precompiled"  /I "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\hotspot\src\share\vm\prims"  /I "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\hotspot\src\os\windows\vm"  /I "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c ..\generated\adfiles\ad_x86_32.cpp ..\generated\adfiles\ad_x86_32_clone.cpp ..\generated\adfiles\ad_x86_32_expand.cpp ..\generated\adfiles\ad_x86_32_format.cpp ..\generated\adfiles\ad_x86_32_gen.cpp ..\generated\adfiles\ad_x86_32_misc.cpp ..\generated\adfiles\ad_x86_32_peephole.cpp ..\generated\adfiles\ad_x86_32_pipeline.cpp ..\generated\adfiles\dfa_x86_32.cpp
> ad_x86_32.cpp
> ad_x86_32_clone.cpp
> ad_x86_32_expand.cpp
> ad_x86_32_format.cpp
> ad_x86_32_gen.cpp
> ad_x86_32_misc.cpp
> ad_x86_32_peephole.cpp
> ad_x86_32_pipeline.cpp
> dfa_x86_32.cpp
>          sh C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\hotspot/make/windows/build_vm_def.sh
>          C:\progra~2\micros~1.0\vc\bin\link.exe @C:\apps\cygwin\tmp\nm76D6.tmp
>     Creating library jvm.lib and object jvm.exp
>
> LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt
> NMAKE : fatal error U1077: 'C:\progra~2\micros~1.0\vc\bin\link.exe' : return code '0x463'
> Stop.
> NMAKE : fatal error U1077: 'cd' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\nmake.EXE"' : return code '0x2'
> Stop.
> Makefile:216: recipe for target `generic_build2' failed
> make[3]: *** [generic_build2] Error 2
> make[3]: Leaving directory `/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/hotspot/make'
> Makefile:167: recipe for target `product' failed
> make[2]: *** [product] Error 2
> make[2]: Leaving directory `/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/hotspot/make'
> HotspotWrapper.gmk:44: recipe for target `/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/build/windows-x86-normal-server-release/hotspot/_hotspot.timestamp' failed
> make[1]: *** [/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/build/windows-x86-normal-server-release/hotspot/_hotspot.timestamp] Error 2
> make[1]: Leaving directory `/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/make'
> /home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk//make/Main.gmk:108: recipe for target `hotspot-only' failed
> make: *** [hotspot-only] Error 2
>
> I am a bit stumped at this time, and would much appreciate a hand. I have the config.log and build.log preserved, but at this point, I did not want to spam the list more than necessary.
>
> Any help/ideas/suggestions much appreciated.
>
> Thanks
>
> Mads




From mbd at terma.com  Wed Jan 14 15:20:55 2015
From: mbd at terma.com (Mads Bondo Dydensborg)
Date: Wed, 14 Jan 2015 15:20:55 +0000
Subject: Problems building jdk8 in Windows - stalls at hotspot,
	surprisingly continues, refuses to link
In-Reply-To: <54B681F1.3010504@Oracle.com>
References: <BCECF94448C3704799FDEB187695635BB613B4@EXCH01.terma.com>
	<54B681F1.3010504@Oracle.com>
Message-ID: <BCECF94448C3704799FDEB187695635BB61403@EXCH01.terma.com>

Thanks, Roger, have installed, is testing.

It still stalls though, so I will have to return on the linker issues later.

Thanks,

Mads

Mads Bondo Dydensborg
Senior Software Architect
Development Programs
Terma A/S


-----Original Message-----
From: build-dev [mailto:build-dev-bounces at openjdk.java.net] On Behalf Of Roger Riggs
Sent: 14. januar 2015 15:49
To: build-dev at openjdk.java.net
Subject: Re: Problems building jdk8 in Windows - stalls at hotspot, surprisingly continues, refuses to link

Hi,

I saw that error message "COFF: file invalid or corrupt" using VS 2010 before I installed the Visual Studio 2010_x86_sp1.  Worked ok after.

$.02, Roger

On 1/14/2015 9:35 AM, Mads Bondo Dydensborg wrote:
> Hi there
>
> I am trying to build jdk8 on Windows 7 64 bit, using cygwin and MS Visual Studio Express. I am pretty experienced in building stuff in Unix/Linux, but Windows is new to me.
>
> Principally, I am using the guide at http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html, but for reasons I cannot fathom, I am unable to retrieve the sources using hg. So, I am using the source package that can be found on this page: http://download.java.net/openjdk/jdk8/ (132-03).
>
> I am using
>
> $ java -version
> java version "1.7.0_72"
> Java(TM) SE Runtime Environment (build 1.7.0_72-b14) Java HotSpot(TM) 
> 64-Bit Server VM (build 24.72-b04, mixed mode)
>
> As the boot Java, freetype is installed, a copy of the .dll.a file has been made.
>
> I believe I am past the configure step, with the following final output from it:
> ====================================================
> A new configuration has been successfully created in 
> /cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_201
> 4/openjdk/build/windows-x86-normal-server-release
> using configure arguments '--with-target-bits=32'.
> Configuration summary:
> * Debug level:    release
> * JDK variant:    normal
> * JVM variants:   server
> * OpenJDK target: OS: windows, CPU architecture: x86, address length: 
> 32 Tools summary:
> * Environment:    cygwin version 1.7.17(0.262/5/3) (root at /cygdrive/c/apps/cygwin)
> * Boot JDK:       java version "1.7.0_72"  Java(TM) SE Runtime Environment (build 1.7.0_72-b14)  Java HotSpot(TM) 64-Bit Server VM (build 24.72-b04, mixed mode)   (at /cygdrive/c/progra~1/java/jdk17~1.0_7)
> * C Compiler:     Microsoft CL.EXE version 16.00.30319.01 (at /cygdrive/c/progra~2/micros~1.0/vc/bin/cl)
> * C++ Compiler:   Microsoft CL.EXE version 16.00.30319.01 (at /cygdrive/c/progra~2/micros~1.0/vc/bin/cl)
> Build performance summary:
> * Cores to use:   7
> * Memory limit:   15950 MB
> * ccache status:  not available for your system
>
> However, when I try to build, the results are not uplifting. I have tried a couple of different targets, but common for all I have tried, is that they stall/hang somewhere while building the hotspot target. Say, e.g, when trying the JDK:
>
> make LOG=trace JOBS=1 jdk
>
> it will stall here:
> + nmake -NOLOGO -f 
> + C:/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openj
> + dk/hotspot/make/windows/build.make Variant=compiler2 
> + 'WorkSpace=C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar
> + _2014\openjdk\hotspot' 'BootStrapDir=C:\progra~1\java\jdk17~1.0_7' 
> + BuildUser=mbd ARCH=x86 BUILDARCH=i486 Platform_arch=x86 
> + Platform_arch_model=x86_32 ENABLE_FULL_DEBUG_SYMBOLS=1 
> + ZIP_DEBUGINFO_FILES=1 'RM=rm -f' ZIPEXE=zip JDK_MKTG_VERSION=8.0 
> + JDK_MAJOR_VER=1 JDK_MINOR_VER=8 JDK_MICRO_VER=0 JDK_BUILD_NUMBER=0 
> + BUILD_WIN_SA=1 'CXX=C:\progra~2\micros~1.0\vc\bin\cl.exe' 
> + 'LD=C:\progra~2\micros~1.0\vc\bin\link.exe' 
> + 'RC=C:\progra~2\micros~3\windows\v7.0a\bin\rc.exe' 
> + 'MT=C:\progra~2\micros~3\windows\v7.0a\bin\mt.exe' 
> + 'BOOTDIR=C:\progra~1\java\jdk17~1.0_7' 
> + 'OUTPUTDIR=C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar
> + _2014\openjdk\build\windows-x86-normal-server-release\hotspot' 
> + 'GAMMADIR=C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_
> + 2014\openjdk\hotspot' MAKE_VERBOSE=y 
> + HOTSPOT_RELEASE_VERSION=25.0-b70 
> + JRE_RELEASE_VERSION=1.8.0-internal-mbd_2015_01_14_13_33-b00 
> + HOTSPOT_BUILD_VERSION= product
>          cd windows_i486_compiler2
>          nmake -nologo -f 
> C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\hotspot\make\windows\makefiles\top.make BUILD_FLAVOR=product ARCH=x86 nmake in ./generated
>          cd generated && "C:\Program Files (x86)\Microsoft Visual 
> Studio 10.0\VC\BIN\nmake.EXE" -NOLOGO -f 
> C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk
> \hotspot\make\windows\makefiles\generated.make  DIR=.\generated 
> BUILD_FLAVOR=product
>
> Now, I thought it was hanging, but while I tried to figure out more on the web, this particular build suddenly - after a stall about 30-45 minutes - proceeded, and eventually, after a few minutes, produced:
>
> C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D 
> "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D 
> TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D 
> TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D 
> TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D 
> _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D 
> "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D 
> "HOTSPOT_RELEASE_VERSION=\"25.0-b70\"" /D 
> "JRE_RELEASE_VERSION=\"1.8.0-internal-mbd_2015_01_14_13_33-b00\"" /D 
> "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D 
> "HOTSPOT_BUILD_USER=\"mbd\"" /D "HOTSPOT_VM_DISTRO=\"OpenJDK\"" /I 
> "..\generated"  /I 
> "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjd
> k\hotspot\src\share\vm"  /I 
> "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjd
> k\hotspot\src\share\vm\precompiled"  /I 
> "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjd
> k\hotspot\src\share\vm\prims"  /I 
> "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjd
> k\hotspot\src\os\windows\vm"  /I 
> "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjd
> k\hotspot\src\os_cpu\windows_x86\vm"  /I 
> "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjd
> k\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" 
> /Yu"precompiled.hpp" /c ..\generated\adfiles\ad_x86_32.cpp 
> ..\generated\adfiles\ad_x86_32_clone.cpp 
> ..\generated\adfiles\ad_x86_32_expand.cpp 
> ..\generated\adfiles\ad_x86_32_format.cpp 
> ..\generated\adfiles\ad_x86_32_gen.cpp 
> ..\generated\adfiles\ad_x86_32_misc.cpp 
> ..\generated\adfiles\ad_x86_32_peephole.cpp 
> ..\generated\adfiles\ad_x86_32_pipeline.cpp 
> ..\generated\adfiles\dfa_x86_32.cpp
> ad_x86_32.cpp
> ad_x86_32_clone.cpp
> ad_x86_32_expand.cpp
> ad_x86_32_format.cpp
> ad_x86_32_gen.cpp
> ad_x86_32_misc.cpp
> ad_x86_32_peephole.cpp
> ad_x86_32_pipeline.cpp
> dfa_x86_32.cpp
>          sh C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\hotspot/make/windows/build_vm_def.sh
>          C:\progra~2\micros~1.0\vc\bin\link.exe @C:\apps\cygwin\tmp\nm76D6.tmp
>     Creating library jvm.lib and object jvm.exp
>
> LINK : fatal error LNK1123: failure during conversion to COFF: file 
> invalid or corrupt NMAKE : fatal error U1077: 'C:\progra~2\micros~1.0\vc\bin\link.exe' : return code '0x463'
> Stop.
> NMAKE : fatal error U1077: 'cd' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\nmake.EXE"' : return code '0x2'
> Stop.
> Makefile:216: recipe for target `generic_build2' failed
> make[3]: *** [generic_build2] Error 2
> make[3]: Leaving directory `/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/hotspot/make'
> Makefile:167: recipe for target `product' failed
> make[2]: *** [product] Error 2
> make[2]: Leaving directory `/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/hotspot/make'
> HotspotWrapper.gmk:44: recipe for target 
> `/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_20
> 14/openjdk/build/windows-x86-normal-server-release/hotspot/_hotspot.ti
> mestamp' failed
> make[1]: *** 
> [/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_20
> 14/openjdk/build/windows-x86-normal-server-release/hotspot/_hotspot.ti
> mestamp] Error 2
> make[1]: Leaving directory `/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/make'
> /home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk//make/Main.gm
> k:108: recipe for target `hotspot-only' failed
> make: *** [hotspot-only] Error 2
>
> I am a bit stumped at this time, and would much appreciate a hand. I have the config.log and build.log preserved, but at this point, I did not want to spam the list more than necessary.
>
> Any help/ideas/suggestions much appreciated.
>
> Thanks
>
> Mads




From erik.joelsson at oracle.com  Wed Jan 14 16:11:09 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 14 Jan 2015 17:11:09 +0100
Subject: RFR: JDK-8068902: Solaris build fails with new 10u10 devkit
Message-ID: <54B6951D.90706@oracle.com>

Hello,

Please review this small patch, which moves the SYSROOT_CFLAGS and 
SYSROOT_LDFLAGS to the back of the compiler and linker command lines. On 
linux, this shouldn't matter as we don't need to override the --sysroot 
option. On Solaris, such an option does not exist, but instead we set an 
explicit -I flag pointing to the system include directory. This -I flag 
must be added after all other -I flags on the command line, as 
otherwise, system headers would override application headers, instead of 
the other way around. The same goes for -L flags when linking.

Bug: https://bugs.openjdk.java.net/browse/JDK-8068902
Webrev: http://cr.openjdk.java.net/~erikj/8068902/webrev.root.01/

/Erik


From david.dehaven at oracle.com  Wed Jan 14 20:23:50 2015
From: david.dehaven at oracle.com (David DeHaven)
Date: Wed, 14 Jan 2015 12:23:50 -0800
Subject: [8u60] RFR: 8043340: [macosx] Fix hard-wired paths to
	JavaVM.framework
In-Reply-To: <54B629D8.8070700@oracle.com>
References: <39719ED3-1F4E-4E6C-AA9F-A3C4766537B4@oracle.com>
	<54B3A38C.10909@oracle.com>
	<8B01B84D-5B6F-478E-ABF1-33F5ADE2F826@oracle.com>
	<08C63261-D594-404E-892B-BDE2898B505A@oracle.com>
	<D4150E19-D909-4AA9-AD43-E00DA084D015@oracle.com>
	<4DC9B291-D302-428C-A5F7-177066C65991@oracle.com>
	<54B629D8.8070700@oracle.com>
Message-ID: <D2D2D84B-C2C0-4E0C-9885-FF0B9FAC1470@oracle.com>


Can someone from hotspot-dev please look at the hotspot changes?

-DrD-

> Hello,
> 
> This looks good to me. Thanks for the detailed table!
> 
> /Erik
> 
> On 2015-01-14 04:09, David DeHaven wrote:
>>>> The --with-xcode-path argument is optional, you should also be able to build with Xcode 4 selected via "sudo xcode-select -switch /path/to/Xcode4.app". I leave MAS managed Xcode (currently 6) active as I'm constantly bouncing between projects and it's a hassle to have to remember to reset the active toolchain, so I thought it best to allow configure to be provided a path.
>>> Ugh. I broke something along the way, this doesn't *quite* work.
>>> 
>>> xcrun complains with "xcrun: error: missing DEVELOPER_DIR path:"
>>> 
>>> I think I'm exporting an empty DEVELOPER_DIR. I shall fix and update.
>> TL;DR: Please review round 2:
>> http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v1/
>> 
>> (I removed generated-configure.sh to reduce the review size, it will be re-generated prior to pushing)
>> 
>> 
>> I've tested the following configuration scenarios (output from a shell script I cobbled together..)
>> 
>> field values:
>> XC6 - Xcode 6 installed in /Applications/Xcode.app
>> XC4 - Xcode 4 installed in some other dir
>> (empty) - Argument not passed to configure
>> 
>> Result meanings:
>> DEV_DIR set - configure succeeded, DEVELOPER_DIR was properly exported in spec.gmk
>> DEV_DIR NOT set - configure succeeded, DEVELOPER_DIR was not needed (XC4 must be selected to achieve this)
>> Configure failed - Configure properly failed when it detected Xcode > 4
>> 
>> "Selected" Xcode means version reported by xcode-select -p
>> 
>> 
>> | Xcode selected | --with-xcode-path | DEVELOPER_DIR     | result           |
>> -----------------------------------------------------------------------------
>> | XC4            |                   |                   | DEV_DIR NOT set  |
>> -----------------------------------------------------------------------------
>> | XC4            |                   | XC4               | DEV_DIR set      |
>> -----------------------------------------------------------------------------
>> | XC4            |                   | XC6               | Configure failed |
>> -----------------------------------------------------------------------------
>> | XC4            | XC4               |                   | DEV_DIR set      |
>> -----------------------------------------------------------------------------
>> | XC4            | XC4               | XC4               | DEV_DIR set      |
>> -----------------------------------------------------------------------------
>> | XC4            | XC4               | XC6               | DEV_DIR set      |
>> -----------------------------------------------------------------------------
>> | XC4            | XC6               |                   | Configure failed |
>> -----------------------------------------------------------------------------
>> | XC4            | XC6               | XC4               | Configure failed |
>> -----------------------------------------------------------------------------
>> | XC4            | XC6               | XC6               | Configure failed |
>> -----------------------------------------------------------------------------
>> | XC6            |                   |                   | Configure failed |
>> -----------------------------------------------------------------------------
>> | XC6            |                   | XC4               | DEV_DIR set      |
>> -----------------------------------------------------------------------------
>> | XC6            |                   | XC6               | Configure failed |
>> -----------------------------------------------------------------------------
>> | XC6            | XC4               |                   | DEV_DIR set      |
>> -----------------------------------------------------------------------------
>> | XC6            | XC4               | XC4               | DEV_DIR set      |
>> -----------------------------------------------------------------------------
>> | XC6            | XC4               | XC6               | DEV_DIR set      |
>> -----------------------------------------------------------------------------
>> | XC6            | XC6               |                   | Configure failed |
>> -----------------------------------------------------------------------------
>> | XC6            | XC6               | XC4               | Configure failed |
>> -----------------------------------------------------------------------------
>> | XC6            | XC6               | XC6               | Configure failed |
>> -----------------------------------------------------------------------------
>> 
>> All the results are as expected. Please note that --with-xcode-path overrides DEVELOPER_DIR, since that could be set in the environment.
>> 
>> (yeah, I went a little OCD on this...)
>> 
>> -DrD-
>> 
> 



From dean.long at oracle.com  Wed Jan 14 22:02:42 2015
From: dean.long at oracle.com (Dean Long)
Date: Wed, 14 Jan 2015 14:02:42 -0800
Subject: RFR: AARCH64: Top-level JDK changes
In-Reply-To: <54B66EB3.3020601@oracle.com>
References: <545CFFA9.4070107@redhat.com>	<545D0290.5080307@oracle.com>	<CA+3eh13Byz2VWW6GA_X00np7DU=-xp7nmA-t1iCygU4EU7FOjA@mail.gmail.com>
	<54B34E20.5030506@oracle.com> <54B3B4CE.8060804@oracle.com>
	<54B4D82B.3050608@oracle.com> <54B66EB3.3020601@oracle.com>
Message-ID: <54B6E782.3040405@oracle.com>

On 1/14/2015 5:27 AM, Magnus Ihse Bursie wrote:
> On 2015-01-13 09:32, Dean Long wrote:
>> On 1/12/2015 3:49 AM, Magnus Ihse Bursie wrote:
>>> On 2015-01-12 05:31, Dean Long wrote:
>>>> I found a small problem with the new config.sub wrapper.  It works 
>>>> with the bash shell but not with the dash shell.
>>>> The problem seems to be with this line:
>>>>
>>>>     result=`. $DIR/autoconf-config.sub $sub_args "$@"`
>>>>
>>>> "dash" doesn't seem to support args passed with ".", so $sub_args 
>>>> "$@" are ignored.
>>>
>>> bash is the required shell for running configure. We do not support 
>>> non-bash shells. In fact, we go to lengths to try to ensure that we 
>>> are indeed running under bash.
>>>
>>> /Magnus
>> I was thinking 'bash configure' was enough, but it turns out 
>> 'CONFIG_SHELL=bash bash configure' gives better results.
>
> Hm, that's interesting. We were attempting to automatically use bash 
> in the real configure script, regardless of what shell the user had to 
> start the top-level configure wrapper.
>
> If you try the patch below, does it work better when you run "dash 
> configure"?
>
> diff --git a/common/autoconf/configure b/common/autoconf/configure
> --- a/common/autoconf/configure
> +++ b/common/autoconf/configure
> @@ -36,6 +36,13 @@
>    shift
>  fi
>
> +if test "x$BASH" = x; then
> +  echo "Error: This script must be run using bash." 1>&2
> +  exit 1
> +fi
> +# Force autoconf to use bash
> +export CONFIG_SHELL=$BASH
> +
>  conf_script_dir="$TOPDIR/common/autoconf"
>
>  if [ "$CUSTOM_CONFIG_DIR" = "" ]; then
>
> /Magnus
>

Yes, that patch solves the problem.

dl


From tim.bell at oracle.com  Wed Jan 14 23:15:20 2015
From: tim.bell at oracle.com (Tim Bell)
Date: Wed, 14 Jan 2015 15:15:20 -0800
Subject: RFR: JDK-8068902: Solaris build fails with new 10u10 devkit
In-Reply-To: <54B6951D.90706@oracle.com>
References: <54B6951D.90706@oracle.com>
Message-ID: <54B6F888.2030207@oracle.com>

Hello Erik:

> Please review this small patch, which moves the SYSROOT_CFLAGS and 
> SYSROOT_LDFLAGS to the back of the compiler and linker command lines. 
> On linux, this shouldn't matter as we don't need to override the 
> --sysroot option. On Solaris, such an option does not exist, but 
> instead we set an explicit -I flag pointing to the system include 
> directory. This -I flag must be added after all other -I flags on the 
> command line, as otherwise, system headers would override application 
> headers, instead of the other way around. The same goes for -L flags 
> when linking.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8068902
> Webrev: http://cr.openjdk.java.net/~erikj/8068902/webrev.root.01/
>

Looks good to me.

Tim



From dean.long at oracle.com  Wed Jan 14 23:34:15 2015
From: dean.long at oracle.com (Dean Long)
Date: Wed, 14 Jan 2015 15:34:15 -0800
Subject: AARCH64: RFR (XS) 8068927: AARCH64: better handling of aarch64-
	triples (was RFR: AARCH64: Top-level JDK changes)
In-Reply-To: <54B56A55.3020803@oracle.com>
References: <545CFFA9.4070107@redhat.com>	<545D0290.5080307@oracle.com>	<CA+3eh13Byz2VWW6GA_X00np7DU=-xp7nmA-t1iCygU4EU7FOjA@mail.gmail.com>	<54B34E20.5030506@oracle.com>
	<54B3A108.9070203@redhat.com>	<54B4DAD4.5060904@oracle.com>
	<54B4E083.9040502@redhat.com> <54B56A55.3020803@oracle.com>
Message-ID: <54B6FCF7.1010202@oracle.com>

Can I get a review for this?

https://bugs.openjdk.java.net/browse/JDK-8068927
http://cr.openjdk.java.net/~dlong/8068927/webrev/

thanks,

dl

On 1/13/2015 10:56 AM, Dean Long wrote:
> On 1/13/2015 1:08 AM, Andrew Haley wrote:
>> On 13/01/15 08:44, Dean Long wrote:
>>
>>> I came up with a simpler version, where I replace "aarch64-" with
>>> "arm-", run autoconf-config.sub, then replace "arm-" back to
>>> "aarch64-".
>> Thanks.  That sounds good to me.
>>
>> Andrew.
>
> Here's the patch.  If it looks good, I can file a bug and push it to 
> the staging repo.
>
> dl
>
>
> diff -r b052cb38b985 common/autoconf/build-aux/config.sub
> --- a/common/autoconf/build-aux/config.sub      Thu Dec 11 15:05:06 
> 2014 -0800
> +++ b/common/autoconf/build-aux/config.sub      Tue Jan 13 13:57:23 
> 2015 -0500
> @@ -41,25 +41,8 @@
>      case $1 in
>          -- )   # Stop option processing
>              shift; break ;;
> -        aarch64-gnu )
> -            sub_args="$sub_args aarch64-unknown-gnu"
> -            shift; ;;
> -        aarch64-linux )
> -            sub_args="$sub_args aarch64-unknown-linux-gnu"
> -            shift; ;;
> -        aarch64-*-linux )
> -            os=`echo $1 | sed 's/aarch64-\(.*\)-linux/\1/'`
> -            config="aarch64-unknown-linux-gnu"
> -            sub_args="$sub_args $config"
> -            shift; ;;
> -        aarch64-*-gnu )
> -            os=`echo $1 | sed 's/aarch64-\(.*\)-gnu.*$/\1/'`
> -            config="aarch64-unknown-gnu"
> -            sub_args="$sub_args $config"
> -            shift; ;;
> -        aarch64-*-linux-* )
> -            os=`echo $1 | sed 's/aarch64-\(.*\)-linux-.*$/'`
> -            config="aarch64-unknown-linux-gnu"
> +        aarch64-* )
> +            config=`echo $1 | sed 's/^aarch64-/arm-/'`
>              sub_args="$sub_args $config"
>              shift; ;;
>          - )    # Use stdin as input.
> @@ -74,9 +57,7 @@
>  result=`. $DIR/autoconf-config.sub $sub_args "$@"`
>  exitcode=$?
>
> -if [ "x$os" != "x" ] ; then
> -    result=`echo $result | sed "s/-unknown-/-$os-/"`
> -fi
> +result=`echo $result | sed "s/^arm-/aarch64-/"`
>
>  echo $result
>  exit $exitcode
>



From david.holmes at oracle.com  Thu Jan 15 05:58:25 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 15 Jan 2015 15:58:25 +1000
Subject: [8u60] RFR: 8043340: [macosx] Fix hard-wired paths to
	JavaVM.framework
In-Reply-To: <D2D2D84B-C2C0-4E0C-9885-FF0B9FAC1470@oracle.com>
References: <39719ED3-1F4E-4E6C-AA9F-A3C4766537B4@oracle.com>	<54B3A38C.10909@oracle.com>	<8B01B84D-5B6F-478E-ABF1-33F5ADE2F826@oracle.com>	<08C63261-D594-404E-892B-BDE2898B505A@oracle.com>	<D4150E19-D909-4AA9-AD43-E00DA084D015@oracle.com>	<4DC9B291-D302-428C-A5F7-177066C65991@oracle.com>	<54B629D8.8070700@oracle.com>
	<D2D2D84B-C2C0-4E0C-9885-FF0B9FAC1470@oracle.com>
Message-ID: <54B75701.1080507@oracle.com>

On 15/01/2015 6:23 AM, David DeHaven wrote:
>
> Can someone from hotspot-dev please look at the hotspot changes?

Looks okay to me.

Thanks,
David H.

> -DrD-
>
>> Hello,
>>
>> This looks good to me. Thanks for the detailed table!
>>
>> /Erik
>>
>> On 2015-01-14 04:09, David DeHaven wrote:
>>>>> The --with-xcode-path argument is optional, you should also be able to build with Xcode 4 selected via "sudo xcode-select -switch /path/to/Xcode4.app". I leave MAS managed Xcode (currently 6) active as I'm constantly bouncing between projects and it's a hassle to have to remember to reset the active toolchain, so I thought it best to allow configure to be provided a path.
>>>> Ugh. I broke something along the way, this doesn't *quite* work.
>>>>
>>>> xcrun complains with "xcrun: error: missing DEVELOPER_DIR path:"
>>>>
>>>> I think I'm exporting an empty DEVELOPER_DIR. I shall fix and update.
>>> TL;DR: Please review round 2:
>>> http://cr.openjdk.java.net/~ddehaven/8043340/jdk8u/v1/
>>>
>>> (I removed generated-configure.sh to reduce the review size, it will be re-generated prior to pushing)
>>>
>>>
>>> I've tested the following configuration scenarios (output from a shell script I cobbled together..)
>>>
>>> field values:
>>> XC6 - Xcode 6 installed in /Applications/Xcode.app
>>> XC4 - Xcode 4 installed in some other dir
>>> (empty) - Argument not passed to configure
>>>
>>> Result meanings:
>>> DEV_DIR set - configure succeeded, DEVELOPER_DIR was properly exported in spec.gmk
>>> DEV_DIR NOT set - configure succeeded, DEVELOPER_DIR was not needed (XC4 must be selected to achieve this)
>>> Configure failed - Configure properly failed when it detected Xcode > 4
>>>
>>> "Selected" Xcode means version reported by xcode-select -p
>>>
>>>
>>> | Xcode selected | --with-xcode-path | DEVELOPER_DIR     | result           |
>>> -----------------------------------------------------------------------------
>>> | XC4            |                   |                   | DEV_DIR NOT set  |
>>> -----------------------------------------------------------------------------
>>> | XC4            |                   | XC4               | DEV_DIR set      |
>>> -----------------------------------------------------------------------------
>>> | XC4            |                   | XC6               | Configure failed |
>>> -----------------------------------------------------------------------------
>>> | XC4            | XC4               |                   | DEV_DIR set      |
>>> -----------------------------------------------------------------------------
>>> | XC4            | XC4               | XC4               | DEV_DIR set      |
>>> -----------------------------------------------------------------------------
>>> | XC4            | XC4               | XC6               | DEV_DIR set      |
>>> -----------------------------------------------------------------------------
>>> | XC4            | XC6               |                   | Configure failed |
>>> -----------------------------------------------------------------------------
>>> | XC4            | XC6               | XC4               | Configure failed |
>>> -----------------------------------------------------------------------------
>>> | XC4            | XC6               | XC6               | Configure failed |
>>> -----------------------------------------------------------------------------
>>> | XC6            |                   |                   | Configure failed |
>>> -----------------------------------------------------------------------------
>>> | XC6            |                   | XC4               | DEV_DIR set      |
>>> -----------------------------------------------------------------------------
>>> | XC6            |                   | XC6               | Configure failed |
>>> -----------------------------------------------------------------------------
>>> | XC6            | XC4               |                   | DEV_DIR set      |
>>> -----------------------------------------------------------------------------
>>> | XC6            | XC4               | XC4               | DEV_DIR set      |
>>> -----------------------------------------------------------------------------
>>> | XC6            | XC4               | XC6               | DEV_DIR set      |
>>> -----------------------------------------------------------------------------
>>> | XC6            | XC6               |                   | Configure failed |
>>> -----------------------------------------------------------------------------
>>> | XC6            | XC6               | XC4               | Configure failed |
>>> -----------------------------------------------------------------------------
>>> | XC6            | XC6               | XC6               | Configure failed |
>>> -----------------------------------------------------------------------------
>>>
>>> All the results are as expected. Please note that --with-xcode-path overrides DEVELOPER_DIR, since that could be set in the environment.
>>>
>>> (yeah, I went a little OCD on this...)
>>>
>>> -DrD-
>>>
>>
>


From david.holmes at oracle.com  Thu Jan 15 07:01:48 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 15 Jan 2015 17:01:48 +1000
Subject: RFR (XS) 8031064: build_vm_def.sh not working correctly for new
	build cross compile
In-Reply-To: <54B760DB.70200@oracle.com>
References: <54B6FA6C.40202@oracle.com> <54B75EB5.3020407@oracle.com>
	<54B760DB.70200@oracle.com>
Message-ID: <54B765DC.8050801@oracle.com>

On 15/01/2015 4:40 PM, Dean Long wrote:
> On 1/14/2015 10:31 PM, David Holmes wrote:
>> Hi Dean,
>>
>> Code reviews don't go to jdk9-dev. Build-infra is not relevant to this
>> either. You only need hotspot-dev for a hotspot build issue (though
>> build-dev might be useful for more complex changes).
>>
> OK.

That was also a hint to drop them from follow ups - which I now have but 
added build-dev. :)

>> On 15/01/2015 9:23 AM, Dean Long wrote:
>>> https://bugs.openjdk.java.net/browse/JDK-8031064
>>> http://cr.openjdk.java.net/~dlong/8031064/webrev/
>>>
>>> This change allows the build_vm_def.sh script to use the $NM chosen by
>>> configure rather than "nm",
>>> which makes things better if you're cross-compiling.
>>
>> I'm always wary of things that might be shell specific:
>>
>>   vm.def: $(Res_Files) $(Obj_Files)
>> !         NM=$(NM) sh $(GAMMADIR)/make/linux/makefiles/build_vm_def.sh
>> *.o > $@
>>
>> I use this style of shell script invocation a lot from bash, where it
>> works, but I was under the impression not all shells support it.
>>
> I thought we require bash, but maybe that's just for confignure. The
> above should work on all Bourne shell variants,
> but not csh variants.  Any time we use something like '2> /dev/null',
> it's Bourne-shell specific, so I don't think our
> linux makefiles will work with csh.  However, I can change it to any of
> the following:

If the build-dev guys confirm we already assume bash that is fine.

BTW the aix and bsd versions of this file have the same flawed logic, 
but probably don't expect to ever be cross-compiling.


> 1. env NM=$(NM) sh ...
> 2. NM=$(NM); export NM; sh ...
> 3.
> export NM
> vm.def: $(Res_Files) $(Obj_Files)
>            sh ...
>
> I have another version that moves the awk code from build_vm_def.sh up
> into vm.make, but I wanted to keep the changes to a minimum.

I must admit I have no idea why this nm invocation has been farmed out 
to a shell script - perhaps the $ escaping became problematic ??

Thanks,
David
>
> dl
>
>> David
>>
>>> dl
>


From dean.long at oracle.com  Thu Jan 15 08:05:51 2015
From: dean.long at oracle.com (Dean Long)
Date: Thu, 15 Jan 2015 00:05:51 -0800
Subject: RFR (XS) 8031064: build_vm_def.sh not working correctly for new
	build cross compile
In-Reply-To: <54B765DC.8050801@oracle.com>
References: <54B6FA6C.40202@oracle.com> <54B75EB5.3020407@oracle.com>
	<54B760DB.70200@oracle.com> <54B765DC.8050801@oracle.com>
Message-ID: <54B774DF.6090505@oracle.com>

On 1/14/2015 11:01 PM, David Holmes wrote:
> On 15/01/2015 4:40 PM, Dean Long wrote:
>> On 1/14/2015 10:31 PM, David Holmes wrote:
>>> Hi Dean,
>>>
>>> Code reviews don't go to jdk9-dev. Build-infra is not relevant to this
>>> either. You only need hotspot-dev for a hotspot build issue (though
>>> build-dev might be useful for more complex changes).
>>>
>> OK.
>
> That was also a hint to drop them from follow ups - which I now have 
> but added build-dev. :)
>
>>> On 15/01/2015 9:23 AM, Dean Long wrote:
>>>> https://bugs.openjdk.java.net/browse/JDK-8031064
>>>> http://cr.openjdk.java.net/~dlong/8031064/webrev/
>>>>
>>>> This change allows the build_vm_def.sh script to use the $NM chosen by
>>>> configure rather than "nm",
>>>> which makes things better if you're cross-compiling.
>>>
>>> I'm always wary of things that might be shell specific:
>>>
>>>   vm.def: $(Res_Files) $(Obj_Files)
>>> !         NM=$(NM) sh $(GAMMADIR)/make/linux/makefiles/build_vm_def.sh
>>> *.o > $@
>>>
>>> I use this style of shell script invocation a lot from bash, where it
>>> works, but I was under the impression not all shells support it.
>>>
>> I thought we require bash, but maybe that's just for confignure. The
>> above should work on all Bourne shell variants,
>> but not csh variants.  Any time we use something like '2> /dev/null',
>> it's Bourne-shell specific, so I don't think our
>> linux makefiles will work with csh.  However, I can change it to any of
>> the following:
>
> If the build-dev guys confirm we already assume bash that is fine.
>
> BTW the aix and bsd versions of this file have the same flawed logic, 
> but probably don't expect to ever be cross-compiling.
>
>
>> 1. env NM=$(NM) sh ...
>> 2. NM=$(NM); export NM; sh ...
>> 3.
>> export NM
>> vm.def: $(Res_Files) $(Obj_Files)
>>            sh ...
>>
>> I have another version that moves the awk code from build_vm_def.sh up
>> into vm.make, but I wanted to keep the changes to a minimum.
>
> I must admit I have no idea why this nm invocation has been farmed out 
> to a shell script - perhaps the $ escaping became problematic ??
>
That would be my guess.  A compromise solution would have been to do the 
"nm" in vm.make, and just do the "awk" part in
build_vm_def.sh (or perhaps build_vm_def.awk).


dl

> Thanks,
> David
>>
>> dl
>>
>>> David
>>>
>>>> dl
>>



From mbd at terma.com  Thu Jan 15 08:53:18 2015
From: mbd at terma.com (Mads Bondo Dydensborg)
Date: Thu, 15 Jan 2015 08:53:18 +0000
Subject: Problems building jdk8 in Windows - stalls at hotspot,
	surprisingly continues, refuses to link
In-Reply-To: <BCECF94448C3704799FDEB187695635BB61403@EXCH01.terma.com>
References: <BCECF94448C3704799FDEB187695635BB613B4@EXCH01.terma.com>
	<54B681F1.3010504@Oracle.com>
	<BCECF94448C3704799FDEB187695635BB61403@EXCH01.terma.com>
Message-ID: <BCECF94448C3704799FDEB187695635BB614F0@EXCH01.terma.com>

Thanks, Roger, updating Visual Studio Express to service pack 1 seems to allow the build to run to completion. 

Perhaps this could be suggested in the build guide?

The weird "stall" after:

Generating jvmtifiles/jvmtiEnvRecommended.cpp
Generating jvmtifiles/bytecodeInterpreterWithChecks.cpp
Generating jvmtifiles/jvmti.h
Generating OpenJDK tracefiles/traceEventClasses.hpp
Generating tracefiles/traceEventIds.hpp
Generating tracefiles/traceTypes.hpp

is somewhat confusing still - I wonder what it is doing? It is not using any CPU, and disk is < 1MB/sec, no noteworthy network activity, and lots of free ram.

AFAICT, it is running nmake, but nmake is not really doing anything... which makes no sense, I reckon.

Regards

Mads

Mads Bondo Dydensborg
Senior Software Architect
Development Programs
Terma A/S


-----Original Message-----
From: build-dev [mailto:build-dev-bounces at openjdk.java.net] On Behalf Of Mads Bondo Dydensborg
Sent: 14. januar 2015 16:21
To: Roger Riggs; build-dev at openjdk.java.net
Subject: RE: Problems building jdk8 in Windows - stalls at hotspot, surprisingly continues, refuses to link

Thanks, Roger, have installed, is testing.

It still stalls though, so I will have to return on the linker issues later.

Thanks,

Mads

Mads Bondo Dydensborg
Senior Software Architect
Development Programs
Terma A/S


-----Original Message-----
From: build-dev [mailto:build-dev-bounces at openjdk.java.net] On Behalf Of Roger Riggs
Sent: 14. januar 2015 15:49
To: build-dev at openjdk.java.net
Subject: Re: Problems building jdk8 in Windows - stalls at hotspot, surprisingly continues, refuses to link

Hi,

I saw that error message "COFF: file invalid or corrupt" using VS 2010 before I installed the Visual Studio 2010_x86_sp1.  Worked ok after.

$.02, Roger

On 1/14/2015 9:35 AM, Mads Bondo Dydensborg wrote:
> Hi there
>
> I am trying to build jdk8 on Windows 7 64 bit, using cygwin and MS Visual Studio Express. I am pretty experienced in building stuff in Unix/Linux, but Windows is new to me.
>
> Principally, I am using the guide at http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html, but for reasons I cannot fathom, I am unable to retrieve the sources using hg. So, I am using the source package that can be found on this page: http://download.java.net/openjdk/jdk8/ (132-03).
>
> I am using
>
> $ java -version
> java version "1.7.0_72"
> Java(TM) SE Runtime Environment (build 1.7.0_72-b14) Java HotSpot(TM) 
> 64-Bit Server VM (build 24.72-b04, mixed mode)
>
> As the boot Java, freetype is installed, a copy of the .dll.a file has been made.
>
> I believe I am past the configure step, with the following final output from it:
> ====================================================
> A new configuration has been successfully created in
> /cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_201
> 4/openjdk/build/windows-x86-normal-server-release
> using configure arguments '--with-target-bits=32'.
> Configuration summary:
> * Debug level:    release
> * JDK variant:    normal
> * JVM variants:   server
> * OpenJDK target: OS: windows, CPU architecture: x86, address length: 
> 32 Tools summary:
> * Environment:    cygwin version 1.7.17(0.262/5/3) (root at /cygdrive/c/apps/cygwin)
> * Boot JDK:       java version "1.7.0_72"  Java(TM) SE Runtime Environment (build 1.7.0_72-b14)  Java HotSpot(TM) 64-Bit Server VM (build 24.72-b04, mixed mode)   (at /cygdrive/c/progra~1/java/jdk17~1.0_7)
> * C Compiler:     Microsoft CL.EXE version 16.00.30319.01 (at /cygdrive/c/progra~2/micros~1.0/vc/bin/cl)
> * C++ Compiler:   Microsoft CL.EXE version 16.00.30319.01 (at /cygdrive/c/progra~2/micros~1.0/vc/bin/cl)
> Build performance summary:
> * Cores to use:   7
> * Memory limit:   15950 MB
> * ccache status:  not available for your system
>
> However, when I try to build, the results are not uplifting. I have tried a couple of different targets, but common for all I have tried, is that they stall/hang somewhere while building the hotspot target. Say, e.g, when trying the JDK:
>
> make LOG=trace JOBS=1 jdk
>
> it will stall here:
> + nmake -NOLOGO -f
> + C:/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openj
> + dk/hotspot/make/windows/build.make Variant=compiler2 
> + 'WorkSpace=C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar
> + _2014\openjdk\hotspot' 'BootStrapDir=C:\progra~1\java\jdk17~1.0_7' 
> + BuildUser=mbd ARCH=x86 BUILDARCH=i486 Platform_arch=x86
> + Platform_arch_model=x86_32 ENABLE_FULL_DEBUG_SYMBOLS=1
> + ZIP_DEBUGINFO_FILES=1 'RM=rm -f' ZIPEXE=zip JDK_MKTG_VERSION=8.0
> + JDK_MAJOR_VER=1 JDK_MINOR_VER=8 JDK_MICRO_VER=0 JDK_BUILD_NUMBER=0
> + BUILD_WIN_SA=1 'CXX=C:\progra~2\micros~1.0\vc\bin\cl.exe' 
> + 'LD=C:\progra~2\micros~1.0\vc\bin\link.exe' 
> + 'RC=C:\progra~2\micros~3\windows\v7.0a\bin\rc.exe' 
> + 'MT=C:\progra~2\micros~3\windows\v7.0a\bin\mt.exe' 
> + 'BOOTDIR=C:\progra~1\java\jdk17~1.0_7' 
> + 'OUTPUTDIR=C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar
> + _2014\openjdk\build\windows-x86-normal-server-release\hotspot' 
> + 'GAMMADIR=C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_
> + 2014\openjdk\hotspot' MAKE_VERBOSE=y
> + HOTSPOT_RELEASE_VERSION=25.0-b70
> + JRE_RELEASE_VERSION=1.8.0-internal-mbd_2015_01_14_13_33-b00
> + HOTSPOT_BUILD_VERSION= product
>          cd windows_i486_compiler2
>          nmake -nologo -f
> C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\hotspot\make\windows\makefiles\top.make BUILD_FLAVOR=product ARCH=x86 nmake in ./generated
>          cd generated && "C:\Program Files (x86)\Microsoft Visual 
> Studio 10.0\VC\BIN\nmake.EXE" -NOLOGO -f 
> C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk
> \hotspot\make\windows\makefiles\generated.make  DIR=.\generated 
> BUILD_FLAVOR=product
>
> Now, I thought it was hanging, but while I tried to figure out more on the web, this particular build suddenly - after a stall about 30-45 minutes - proceeded, and eventually, after a few minutes, produced:
>
> C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D 
> "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D 
> TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D
> TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D
> TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D 
> _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D 
> "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D 
> "HOTSPOT_RELEASE_VERSION=\"25.0-b70\"" /D 
> "JRE_RELEASE_VERSION=\"1.8.0-internal-mbd_2015_01_14_13_33-b00\"" /D 
> "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D 
> "HOTSPOT_BUILD_USER=\"mbd\"" /D "HOTSPOT_VM_DISTRO=\"OpenJDK\"" /I 
> "..\generated"  /I 
> "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjd
> k\hotspot\src\share\vm"  /I
> "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjd
> k\hotspot\src\share\vm\precompiled"  /I 
> "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjd
> k\hotspot\src\share\vm\prims"  /I
> "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjd
> k\hotspot\src\os\windows\vm"  /I
> "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjd
> k\hotspot\src\os_cpu\windows_x86\vm"  /I 
> "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjd
> k\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" 
> /Yu"precompiled.hpp" /c ..\generated\adfiles\ad_x86_32.cpp
> ..\generated\adfiles\ad_x86_32_clone.cpp
> ..\generated\adfiles\ad_x86_32_expand.cpp
> ..\generated\adfiles\ad_x86_32_format.cpp
> ..\generated\adfiles\ad_x86_32_gen.cpp
> ..\generated\adfiles\ad_x86_32_misc.cpp
> ..\generated\adfiles\ad_x86_32_peephole.cpp
> ..\generated\adfiles\ad_x86_32_pipeline.cpp
> ..\generated\adfiles\dfa_x86_32.cpp
> ad_x86_32.cpp
> ad_x86_32_clone.cpp
> ad_x86_32_expand.cpp
> ad_x86_32_format.cpp
> ad_x86_32_gen.cpp
> ad_x86_32_misc.cpp
> ad_x86_32_peephole.cpp
> ad_x86_32_pipeline.cpp
> dfa_x86_32.cpp
>          sh C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\hotspot/make/windows/build_vm_def.sh
>          C:\progra~2\micros~1.0\vc\bin\link.exe @C:\apps\cygwin\tmp\nm76D6.tmp
>     Creating library jvm.lib and object jvm.exp
>
> LINK : fatal error LNK1123: failure during conversion to COFF: file 
> invalid or corrupt NMAKE : fatal error U1077: 'C:\progra~2\micros~1.0\vc\bin\link.exe' : return code '0x463'
> Stop.
> NMAKE : fatal error U1077: 'cd' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\nmake.EXE"' : return code '0x2'
> Stop.
> Makefile:216: recipe for target `generic_build2' failed
> make[3]: *** [generic_build2] Error 2
> make[3]: Leaving directory `/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/hotspot/make'
> Makefile:167: recipe for target `product' failed
> make[2]: *** [product] Error 2
> make[2]: Leaving directory `/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/hotspot/make'
> HotspotWrapper.gmk:44: recipe for target
> `/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_20
> 14/openjdk/build/windows-x86-normal-server-release/hotspot/_hotspot.ti
> mestamp' failed
> make[1]: ***
> [/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_20
> 14/openjdk/build/windows-x86-normal-server-release/hotspot/_hotspot.ti
> mestamp] Error 2
> make[1]: Leaving directory `/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/make'
> /home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk//make/Main.gm
> k:108: recipe for target `hotspot-only' failed
> make: *** [hotspot-only] Error 2
>
> I am a bit stumped at this time, and would much appreciate a hand. I have the config.log and build.log preserved, but at this point, I did not want to spam the list more than necessary.
>
> Any help/ideas/suggestions much appreciated.
>
> Thanks
>
> Mads




From erik.joelsson at oracle.com  Thu Jan 15 09:21:23 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 15 Jan 2015 10:21:23 +0100
Subject: RFR: JDK-8069041: Bootcycle builds do not work with sjavac
Message-ID: <54B78693.8070608@oracle.com>

Hello,

Please review this small patch which fixes bootcycle-images builds when 
enabling sjavac. The problem was that the directory where the portfile 
should be created is never created in the bootcycle-build output 
directory. I think the best and simplest solution is to just always 
create it prior to running sjavac.

Bug: https://bugs.openjdk.java.net/browse/JDK-8069041
Patch inline:
diff -r 378fd58fe406 make/common/JavaCompilation.gmk
--- a/make/common/JavaCompilation.gmk
+++ b/make/common/JavaCompilation.gmk
@@ -538,7 +538,7 @@
$1_REMOTE:=--server:portfile=$$($1_SJAVAC_PORTFILE),id=$1,sjavac=$$(subst $$(SPACE),%20,$$(subst 
$$(COMMA),%2C,$$(strip $$($1_SERVER_JVM) $$($1_SJAVAC))))

      $$($1_BIN)/_the.$1_batch: $$($1_SRCS) $$($1_DEPENDS)
-    $(MKDIR) -p $$(@D)
+    $(MKDIR) -p $$(@D) $$(dir $$($1_SJAVAC_PORTFILE))
          # As a workaround for sjavac not tracking api changed from the 
classpath, force full
          # recompile if an external dependency, which is something 
other than a source
          # change, triggered this compilation.

/Erik


From volker.simonis at gmail.com  Thu Jan 15 10:17:40 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 15 Jan 2015 11:17:40 +0100
Subject: Problems building jdk8 in Windows - stalls at hotspot,
	surprisingly continues, refuses to link
In-Reply-To: <BCECF94448C3704799FDEB187695635BB614F0@EXCH01.terma.com>
References: <BCECF94448C3704799FDEB187695635BB613B4@EXCH01.terma.com>
	<54B681F1.3010504@Oracle.com>
	<BCECF94448C3704799FDEB187695635BB61403@EXCH01.terma.com>
	<BCECF94448C3704799FDEB187695635BB614F0@EXCH01.terma.com>
Message-ID: <CA+3eh13iCeZpviC0LL+ac45RREebfa9kcWXL+y2VAw1FBLy98g@mail.gmail.com>

Hi Mads,

The COFF isue is a known problem with VS2010 after installing VS2012
or .NET 4.5.1. There exist various workarounds - just google for "LINK
: fatal error LNK1123: failure during conversion to COFF: file
invalid".

The easiest and fastes solution is to remove the bad version of
"cvtres.exe" which is causing the problem as explained in the second
answer at the stackowerflow question
http://stackoverflow.com/questions/10888391/error-link-fatal-error-lnk1123-failure-during-conversion-to-coff-file-inval

Regarding the stall: do you have any Anti-Virus software running?
That'S known to cause problems. You could also try a newer/other
Cygwin version.

Regards,
Volker

On Thu, Jan 15, 2015 at 9:53 AM, Mads Bondo Dydensborg <mbd at terma.com> wrote:
> Thanks, Roger, updating Visual Studio Express to service pack 1 seems to allow the build to run to completion.
>
> Perhaps this could be suggested in the build guide?
>
> The weird "stall" after:
>
> Generating jvmtifiles/jvmtiEnvRecommended.cpp
> Generating jvmtifiles/bytecodeInterpreterWithChecks.cpp
> Generating jvmtifiles/jvmti.h
> Generating OpenJDK tracefiles/traceEventClasses.hpp
> Generating tracefiles/traceEventIds.hpp
> Generating tracefiles/traceTypes.hpp
>
> is somewhat confusing still - I wonder what it is doing? It is not using any CPU, and disk is < 1MB/sec, no noteworthy network activity, and lots of free ram.
>
> AFAICT, it is running nmake, but nmake is not really doing anything... which makes no sense, I reckon.
>
> Regards
>
> Mads
>
> Mads Bondo Dydensborg
> Senior Software Architect
> Development Programs
> Terma A/S
>
>
> -----Original Message-----
> From: build-dev [mailto:build-dev-bounces at openjdk.java.net] On Behalf Of Mads Bondo Dydensborg
> Sent: 14. januar 2015 16:21
> To: Roger Riggs; build-dev at openjdk.java.net
> Subject: RE: Problems building jdk8 in Windows - stalls at hotspot, surprisingly continues, refuses to link
>
> Thanks, Roger, have installed, is testing.
>
> It still stalls though, so I will have to return on the linker issues later.
>
> Thanks,
>
> Mads
>
> Mads Bondo Dydensborg
> Senior Software Architect
> Development Programs
> Terma A/S
>
>
> -----Original Message-----
> From: build-dev [mailto:build-dev-bounces at openjdk.java.net] On Behalf Of Roger Riggs
> Sent: 14. januar 2015 15:49
> To: build-dev at openjdk.java.net
> Subject: Re: Problems building jdk8 in Windows - stalls at hotspot, surprisingly continues, refuses to link
>
> Hi,
>
> I saw that error message "COFF: file invalid or corrupt" using VS 2010 before I installed the Visual Studio 2010_x86_sp1.  Worked ok after.
>
> $.02, Roger
>
> On 1/14/2015 9:35 AM, Mads Bondo Dydensborg wrote:
>> Hi there
>>
>> I am trying to build jdk8 on Windows 7 64 bit, using cygwin and MS Visual Studio Express. I am pretty experienced in building stuff in Unix/Linux, but Windows is new to me.
>>
>> Principally, I am using the guide at http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html, but for reasons I cannot fathom, I am unable to retrieve the sources using hg. So, I am using the source package that can be found on this page: http://download.java.net/openjdk/jdk8/ (132-03).
>>
>> I am using
>>
>> $ java -version
>> java version "1.7.0_72"
>> Java(TM) SE Runtime Environment (build 1.7.0_72-b14) Java HotSpot(TM)
>> 64-Bit Server VM (build 24.72-b04, mixed mode)
>>
>> As the boot Java, freetype is installed, a copy of the .dll.a file has been made.
>>
>> I believe I am past the configure step, with the following final output from it:
>> ====================================================
>> A new configuration has been successfully created in
>> /cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_201
>> 4/openjdk/build/windows-x86-normal-server-release
>> using configure arguments '--with-target-bits=32'.
>> Configuration summary:
>> * Debug level:    release
>> * JDK variant:    normal
>> * JVM variants:   server
>> * OpenJDK target: OS: windows, CPU architecture: x86, address length:
>> 32 Tools summary:
>> * Environment:    cygwin version 1.7.17(0.262/5/3) (root at /cygdrive/c/apps/cygwin)
>> * Boot JDK:       java version "1.7.0_72"  Java(TM) SE Runtime Environment (build 1.7.0_72-b14)  Java HotSpot(TM) 64-Bit Server VM (build 24.72-b04, mixed mode)   (at /cygdrive/c/progra~1/java/jdk17~1.0_7)
>> * C Compiler:     Microsoft CL.EXE version 16.00.30319.01 (at /cygdrive/c/progra~2/micros~1.0/vc/bin/cl)
>> * C++ Compiler:   Microsoft CL.EXE version 16.00.30319.01 (at /cygdrive/c/progra~2/micros~1.0/vc/bin/cl)
>> Build performance summary:
>> * Cores to use:   7
>> * Memory limit:   15950 MB
>> * ccache status:  not available for your system
>>
>> However, when I try to build, the results are not uplifting. I have tried a couple of different targets, but common for all I have tried, is that they stall/hang somewhere while building the hotspot target. Say, e.g, when trying the JDK:
>>
>> make LOG=trace JOBS=1 jdk
>>
>> it will stall here:
>> + nmake -NOLOGO -f
>> + C:/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openj
>> + dk/hotspot/make/windows/build.make Variant=compiler2
>> + 'WorkSpace=C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar
>> + _2014\openjdk\hotspot' 'BootStrapDir=C:\progra~1\java\jdk17~1.0_7'
>> + BuildUser=mbd ARCH=x86 BUILDARCH=i486 Platform_arch=x86
>> + Platform_arch_model=x86_32 ENABLE_FULL_DEBUG_SYMBOLS=1
>> + ZIP_DEBUGINFO_FILES=1 'RM=rm -f' ZIPEXE=zip JDK_MKTG_VERSION=8.0
>> + JDK_MAJOR_VER=1 JDK_MINOR_VER=8 JDK_MICRO_VER=0 JDK_BUILD_NUMBER=0
>> + BUILD_WIN_SA=1 'CXX=C:\progra~2\micros~1.0\vc\bin\cl.exe'
>> + 'LD=C:\progra~2\micros~1.0\vc\bin\link.exe'
>> + 'RC=C:\progra~2\micros~3\windows\v7.0a\bin\rc.exe'
>> + 'MT=C:\progra~2\micros~3\windows\v7.0a\bin\mt.exe'
>> + 'BOOTDIR=C:\progra~1\java\jdk17~1.0_7'
>> + 'OUTPUTDIR=C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar
>> + _2014\openjdk\build\windows-x86-normal-server-release\hotspot'
>> + 'GAMMADIR=C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_
>> + 2014\openjdk\hotspot' MAKE_VERBOSE=y
>> + HOTSPOT_RELEASE_VERSION=25.0-b70
>> + JRE_RELEASE_VERSION=1.8.0-internal-mbd_2015_01_14_13_33-b00
>> + HOTSPOT_BUILD_VERSION= product
>>          cd windows_i486_compiler2
>>          nmake -nologo -f
>> C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\hotspot\make\windows\makefiles\top.make BUILD_FLAVOR=product ARCH=x86 nmake in ./generated
>>          cd generated && "C:\Program Files (x86)\Microsoft Visual
>> Studio 10.0\VC\BIN\nmake.EXE" -NOLOGO -f
>> C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk
>> \hotspot\make\windows\makefiles\generated.make  DIR=.\generated
>> BUILD_FLAVOR=product
>>
>> Now, I thought it was hanging, but while I tried to figure out more on the web, this particular build suddenly - after a stall about 30-45 minutes - proceeded, and eventually, after a few minutes, produced:
>>
>> C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D
>> "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D
>> TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D
>> TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D
>> TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D
>> _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D
>> "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D
>> "HOTSPOT_RELEASE_VERSION=\"25.0-b70\"" /D
>> "JRE_RELEASE_VERSION=\"1.8.0-internal-mbd_2015_01_14_13_33-b00\"" /D
>> "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D
>> "HOTSPOT_BUILD_USER=\"mbd\"" /D "HOTSPOT_VM_DISTRO=\"OpenJDK\"" /I
>> "..\generated"  /I
>> "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjd
>> k\hotspot\src\share\vm"  /I
>> "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjd
>> k\hotspot\src\share\vm\precompiled"  /I
>> "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjd
>> k\hotspot\src\share\vm\prims"  /I
>> "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjd
>> k\hotspot\src\os\windows\vm"  /I
>> "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjd
>> k\hotspot\src\os_cpu\windows_x86\vm"  /I
>> "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjd
>> k\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch"
>> /Yu"precompiled.hpp" /c ..\generated\adfiles\ad_x86_32.cpp
>> ..\generated\adfiles\ad_x86_32_clone.cpp
>> ..\generated\adfiles\ad_x86_32_expand.cpp
>> ..\generated\adfiles\ad_x86_32_format.cpp
>> ..\generated\adfiles\ad_x86_32_gen.cpp
>> ..\generated\adfiles\ad_x86_32_misc.cpp
>> ..\generated\adfiles\ad_x86_32_peephole.cpp
>> ..\generated\adfiles\ad_x86_32_pipeline.cpp
>> ..\generated\adfiles\dfa_x86_32.cpp
>> ad_x86_32.cpp
>> ad_x86_32_clone.cpp
>> ad_x86_32_expand.cpp
>> ad_x86_32_format.cpp
>> ad_x86_32_gen.cpp
>> ad_x86_32_misc.cpp
>> ad_x86_32_peephole.cpp
>> ad_x86_32_pipeline.cpp
>> dfa_x86_32.cpp
>>          sh C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\hotspot/make/windows/build_vm_def.sh
>>          C:\progra~2\micros~1.0\vc\bin\link.exe @C:\apps\cygwin\tmp\nm76D6.tmp
>>     Creating library jvm.lib and object jvm.exp
>>
>> LINK : fatal error LNK1123: failure during conversion to COFF: file
>> invalid or corrupt NMAKE : fatal error U1077: 'C:\progra~2\micros~1.0\vc\bin\link.exe' : return code '0x463'
>> Stop.
>> NMAKE : fatal error U1077: 'cd' : return code '0x2'
>> Stop.
>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\nmake.EXE"' : return code '0x2'
>> Stop.
>> Makefile:216: recipe for target `generic_build2' failed
>> make[3]: *** [generic_build2] Error 2
>> make[3]: Leaving directory `/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/hotspot/make'
>> Makefile:167: recipe for target `product' failed
>> make[2]: *** [product] Error 2
>> make[2]: Leaving directory `/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/hotspot/make'
>> HotspotWrapper.gmk:44: recipe for target
>> `/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_20
>> 14/openjdk/build/windows-x86-normal-server-release/hotspot/_hotspot.ti
>> mestamp' failed
>> make[1]: ***
>> [/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_20
>> 14/openjdk/build/windows-x86-normal-server-release/hotspot/_hotspot.ti
>> mestamp] Error 2
>> make[1]: Leaving directory `/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/make'
>> /home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk//make/Main.gm
>> k:108: recipe for target `hotspot-only' failed
>> make: *** [hotspot-only] Error 2
>>
>> I am a bit stumped at this time, and would much appreciate a hand. I have the config.log and build.log preserved, but at this point, I did not want to spam the list more than necessary.
>>
>> Any help/ideas/suggestions much appreciated.
>>
>> Thanks
>>
>> Mads
>
>


From mbd at terma.com  Thu Jan 15 10:28:37 2015
From: mbd at terma.com (Mads Bondo Dydensborg)
Date: Thu, 15 Jan 2015 10:28:37 +0000
Subject: Problems building jdk8 in Windows - stalls at hotspot,
	surprisingly continues, refuses to link
In-Reply-To: <CA+3eh13iCeZpviC0LL+ac45RREebfa9kcWXL+y2VAw1FBLy98g@mail.gmail.com>
References: <BCECF94448C3704799FDEB187695635BB613B4@EXCH01.terma.com>
	<54B681F1.3010504@Oracle.com>
	<BCECF94448C3704799FDEB187695635BB61403@EXCH01.terma.com>
	<BCECF94448C3704799FDEB187695635BB614F0@EXCH01.terma.com>
	<CA+3eh13iCeZpviC0LL+ac45RREebfa9kcWXL+y2VAw1FBLy98g@mail.gmail.com>
Message-ID: <BCECF94448C3704799FDEB187695635BB6158E@EXCH01.terma.com>

Hi Volker

Thanks a lot for the info. I do not have VS2012, but I do have .NET 4.5.1. Installing the SP1 solved my problem, but your reference is very handy for other situations. (And, makes me long for the sane world of Linux).

RE the stall : Yes, I have anti-virus software running - this is company policy. Cygwin is 3.0.0-rc1 and I am not allowed to upgrade it. The builds eventually completes, so I guess I can live with it.

Thanks again.

Mads

Mads Bondo Dydensborg
Senior Software Architect
Development Programs
Terma A/S


-----Original Message-----
From: Volker Simonis [mailto:volker.simonis at gmail.com] 
Sent: 15. januar 2015 11:18
To: Mads Bondo Dydensborg
Cc: build-dev at openjdk.java.net
Subject: Re: Problems building jdk8 in Windows - stalls at hotspot, surprisingly continues, refuses to link

Hi Mads,

The COFF isue is a known problem with VS2010 after installing VS2012 or .NET 4.5.1. There exist various workarounds - just google for "LINK
: fatal error LNK1123: failure during conversion to COFF: file invalid".

The easiest and fastes solution is to remove the bad version of "cvtres.exe" which is causing the problem as explained in the second answer at the stackowerflow question http://stackoverflow.com/questions/10888391/error-link-fatal-error-lnk1123-failure-during-conversion-to-coff-file-inval

Regarding the stall: do you have any Anti-Virus software running?
That'S known to cause problems. You could also try a newer/other Cygwin version.

Regards,
Volker

On Thu, Jan 15, 2015 at 9:53 AM, Mads Bondo Dydensborg <mbd at terma.com> wrote:
> Thanks, Roger, updating Visual Studio Express to service pack 1 seems to allow the build to run to completion.
>
> Perhaps this could be suggested in the build guide?
>
> The weird "stall" after:
>
> Generating jvmtifiles/jvmtiEnvRecommended.cpp
> Generating jvmtifiles/bytecodeInterpreterWithChecks.cpp
> Generating jvmtifiles/jvmti.h
> Generating OpenJDK tracefiles/traceEventClasses.hpp Generating 
> tracefiles/traceEventIds.hpp Generating tracefiles/traceTypes.hpp
>
> is somewhat confusing still - I wonder what it is doing? It is not using any CPU, and disk is < 1MB/sec, no noteworthy network activity, and lots of free ram.
>
> AFAICT, it is running nmake, but nmake is not really doing anything... which makes no sense, I reckon.
>
> Regards
>
> Mads
>
> Mads Bondo Dydensborg
> Senior Software Architect
> Development Programs
> Terma A/S
>
>
> -----Original Message-----
> From: build-dev [mailto:build-dev-bounces at openjdk.java.net] On Behalf 
> Of Mads Bondo Dydensborg
> Sent: 14. januar 2015 16:21
> To: Roger Riggs; build-dev at openjdk.java.net
> Subject: RE: Problems building jdk8 in Windows - stalls at hotspot, 
> surprisingly continues, refuses to link
>
> Thanks, Roger, have installed, is testing.
>
> It still stalls though, so I will have to return on the linker issues later.
>
> Thanks,
>
> Mads
>
> Mads Bondo Dydensborg
> Senior Software Architect
> Development Programs
> Terma A/S
>
>
> -----Original Message-----
> From: build-dev [mailto:build-dev-bounces at openjdk.java.net] On Behalf 
> Of Roger Riggs
> Sent: 14. januar 2015 15:49
> To: build-dev at openjdk.java.net
> Subject: Re: Problems building jdk8 in Windows - stalls at hotspot, 
> surprisingly continues, refuses to link
>
> Hi,
>
> I saw that error message "COFF: file invalid or corrupt" using VS 2010 before I installed the Visual Studio 2010_x86_sp1.  Worked ok after.
>
> $.02, Roger
>
> On 1/14/2015 9:35 AM, Mads Bondo Dydensborg wrote:
>> Hi there
>>
>> I am trying to build jdk8 on Windows 7 64 bit, using cygwin and MS Visual Studio Express. I am pretty experienced in building stuff in Unix/Linux, but Windows is new to me.
>>
>> Principally, I am using the guide at http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html, but for reasons I cannot fathom, I am unable to retrieve the sources using hg. So, I am using the source package that can be found on this page: http://download.java.net/openjdk/jdk8/ (132-03).
>>
>> I am using
>>
>> $ java -version
>> java version "1.7.0_72"
>> Java(TM) SE Runtime Environment (build 1.7.0_72-b14) Java HotSpot(TM) 
>> 64-Bit Server VM (build 24.72-b04, mixed mode)
>>
>> As the boot Java, freetype is installed, a copy of the .dll.a file has been made.
>>
>> I believe I am past the configure step, with the following final output from it:
>> ====================================================
>> A new configuration has been successfully created in
>> /cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_20
>> 1 4/openjdk/build/windows-x86-normal-server-release
>> using configure arguments '--with-target-bits=32'.
>> Configuration summary:
>> * Debug level:    release
>> * JDK variant:    normal
>> * JVM variants:   server
>> * OpenJDK target: OS: windows, CPU architecture: x86, address length:
>> 32 Tools summary:
>> * Environment:    cygwin version 1.7.17(0.262/5/3) (root at /cygdrive/c/apps/cygwin)
>> * Boot JDK:       java version "1.7.0_72"  Java(TM) SE Runtime Environment (build 1.7.0_72-b14)  Java HotSpot(TM) 64-Bit Server VM (build 24.72-b04, mixed mode)   (at /cygdrive/c/progra~1/java/jdk17~1.0_7)
>> * C Compiler:     Microsoft CL.EXE version 16.00.30319.01 (at /cygdrive/c/progra~2/micros~1.0/vc/bin/cl)
>> * C++ Compiler:   Microsoft CL.EXE version 16.00.30319.01 (at /cygdrive/c/progra~2/micros~1.0/vc/bin/cl)
>> Build performance summary:
>> * Cores to use:   7
>> * Memory limit:   15950 MB
>> * ccache status:  not available for your system
>>
>> However, when I try to build, the results are not uplifting. I have tried a couple of different targets, but common for all I have tried, is that they stall/hang somewhere while building the hotspot target. Say, e.g, when trying the JDK:
>>
>> make LOG=trace JOBS=1 jdk
>>
>> it will stall here:
>> + nmake -NOLOGO -f
>> + C:/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/open
>> + j dk/hotspot/make/windows/build.make Variant=compiler2 
>> + 'WorkSpace=C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_ma
>> + r _2014\openjdk\hotspot' 
>> + 'BootStrapDir=C:\progra~1\java\jdk17~1.0_7'
>> + BuildUser=mbd ARCH=x86 BUILDARCH=i486 Platform_arch=x86
>> + Platform_arch_model=x86_32 ENABLE_FULL_DEBUG_SYMBOLS=1
>> + ZIP_DEBUGINFO_FILES=1 'RM=rm -f' ZIPEXE=zip JDK_MKTG_VERSION=8.0
>> + JDK_MAJOR_VER=1 JDK_MINOR_VER=8 JDK_MICRO_VER=0 JDK_BUILD_NUMBER=0
>> + BUILD_WIN_SA=1 'CXX=C:\progra~2\micros~1.0\vc\bin\cl.exe'
>> + 'LD=C:\progra~2\micros~1.0\vc\bin\link.exe'
>> + 'RC=C:\progra~2\micros~3\windows\v7.0a\bin\rc.exe'
>> + 'MT=C:\progra~2\micros~3\windows\v7.0a\bin\mt.exe'
>> + 'BOOTDIR=C:\progra~1\java\jdk17~1.0_7'
>> + 'OUTPUTDIR=C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_ma
>> + r _2014\openjdk\build\windows-x86-normal-server-release\hotspot'
>> + 'GAMMADIR=C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar
>> + _ 2014\openjdk\hotspot' MAKE_VERBOSE=y
>> + HOTSPOT_RELEASE_VERSION=25.0-b70
>> + JRE_RELEASE_VERSION=1.8.0-internal-mbd_2015_01_14_13_33-b00
>> + HOTSPOT_BUILD_VERSION= product
>>          cd windows_i486_compiler2
>>          nmake -nologo -f
>> C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\hotspot\make\windows\makefiles\top.make BUILD_FLAVOR=product ARCH=x86 nmake in ./generated
>>          cd generated && "C:\Program Files (x86)\Microsoft Visual 
>> Studio 10.0\VC\BIN\nmake.EXE" -NOLOGO -f 
>> C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjd
>> k \hotspot\make\windows\makefiles\generated.make  DIR=.\generated 
>> BUILD_FLAVOR=product
>>
>> Now, I thought it was hanging, but while I tried to figure out more on the web, this particular build suddenly - after a stall about 30-45 minutes - proceeded, and eventually, after a few minutes, produced:
>>
>> C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" 
>> /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D 
>> TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D
>> TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D
>> TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D 
>> _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D 
>> "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D 
>> "HOTSPOT_RELEASE_VERSION=\"25.0-b70\"" /D 
>> "JRE_RELEASE_VERSION=\"1.8.0-internal-mbd_2015_01_14_13_33-b00\"" /D 
>> "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D 
>> "HOTSPOT_BUILD_USER=\"mbd\"" /D "HOTSPOT_VM_DISTRO=\"OpenJDK\"" /I 
>> "..\generated"  /I 
>> "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openj
>> d
>> k\hotspot\src\share\vm"  /I
>> "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openj
>> d k\hotspot\src\share\vm\precompiled"  /I 
>> "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openj
>> d
>> k\hotspot\src\share\vm\prims"  /I
>> "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openj
>> d
>> k\hotspot\src\os\windows\vm"  /I
>> "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openj
>> d k\hotspot\src\os_cpu\windows_x86\vm"  /I 
>> "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openj
>> d k\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch"
>> /Yu"precompiled.hpp" /c ..\generated\adfiles\ad_x86_32.cpp
>> ..\generated\adfiles\ad_x86_32_clone.cpp
>> ..\generated\adfiles\ad_x86_32_expand.cpp
>> ..\generated\adfiles\ad_x86_32_format.cpp
>> ..\generated\adfiles\ad_x86_32_gen.cpp
>> ..\generated\adfiles\ad_x86_32_misc.cpp
>> ..\generated\adfiles\ad_x86_32_peephole.cpp
>> ..\generated\adfiles\ad_x86_32_pipeline.cpp
>> ..\generated\adfiles\dfa_x86_32.cpp
>> ad_x86_32.cpp
>> ad_x86_32_clone.cpp
>> ad_x86_32_expand.cpp
>> ad_x86_32_format.cpp
>> ad_x86_32_gen.cpp
>> ad_x86_32_misc.cpp
>> ad_x86_32_peephole.cpp
>> ad_x86_32_pipeline.cpp
>> dfa_x86_32.cpp
>>          sh C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\hotspot/make/windows/build_vm_def.sh
>>          C:\progra~2\micros~1.0\vc\bin\link.exe @C:\apps\cygwin\tmp\nm76D6.tmp
>>     Creating library jvm.lib and object jvm.exp
>>
>> LINK : fatal error LNK1123: failure during conversion to COFF: file 
>> invalid or corrupt NMAKE : fatal error U1077: 'C:\progra~2\micros~1.0\vc\bin\link.exe' : return code '0x463'
>> Stop.
>> NMAKE : fatal error U1077: 'cd' : return code '0x2'
>> Stop.
>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\nmake.EXE"' : return code '0x2'
>> Stop.
>> Makefile:216: recipe for target `generic_build2' failed
>> make[3]: *** [generic_build2] Error 2
>> make[3]: Leaving directory `/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/hotspot/make'
>> Makefile:167: recipe for target `product' failed
>> make[2]: *** [product] Error 2
>> make[2]: Leaving directory `/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/hotspot/make'
>> HotspotWrapper.gmk:44: recipe for target
>> `/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2
>> 0 
>> 14/openjdk/build/windows-x86-normal-server-release/hotspot/_hotspot.t
>> i
>> mestamp' failed
>> make[1]: ***
>> [/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2
>> 0 
>> 14/openjdk/build/windows-x86-normal-server-release/hotspot/_hotspot.t
>> i
>> mestamp] Error 2
>> make[1]: Leaving directory `/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/make'
>> /home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk//make/Main.g
>> m
>> k:108: recipe for target `hotspot-only' failed
>> make: *** [hotspot-only] Error 2
>>
>> I am a bit stumped at this time, and would much appreciate a hand. I have the config.log and build.log preserved, but at this point, I did not want to spam the list more than necessary.
>>
>> Any help/ideas/suggestions much appreciated.
>>
>> Thanks
>>
>> Mads
>
>

From erik.joelsson at oracle.com  Thu Jan 15 11:05:34 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 15 Jan 2015 12:05:34 +0100
Subject: RFR: JDK-8068748: missing US_export_policy.jar in jdk9-b44 is causing
	compilation errors building jdk9 source code
Message-ID: <54B79EFE.7050202@oracle.com>

Hello,

Please review the open part of this patch, which changes the building of 
policy jars to happen even if BUILD_CRYPTO is false. Previously these 
weren't built as there were signed versions of these jars, but since we 
no longer sign them, there is no need to not build them.

Bug: https://bugs.openjdk.java.net/browse/JDK-8068748
Webrev: http://cr.openjdk.java.net/~erikj/8068748/webrev.jdk.01/

The webrev diffs look a bit weird. The only thing I did was to remove 
the "ifneq ($(BUILD_CRYPTO), no)" and adjust the indentation.

/Erik


From volker.simonis at gmail.com  Thu Jan 15 11:22:47 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 15 Jan 2015 12:22:47 +0100
Subject: Problems building jdk8 in Windows - stalls at hotspot,
	surprisingly continues, refuses to link
In-Reply-To: <BCECF94448C3704799FDEB187695635BB6158E@EXCH01.terma.com>
References: <BCECF94448C3704799FDEB187695635BB613B4@EXCH01.terma.com>
	<54B681F1.3010504@Oracle.com>
	<BCECF94448C3704799FDEB187695635BB61403@EXCH01.terma.com>
	<BCECF94448C3704799FDEB187695635BB614F0@EXCH01.terma.com>
	<CA+3eh13iCeZpviC0LL+ac45RREebfa9kcWXL+y2VAw1FBLy98g@mail.gmail.com>
	<BCECF94448C3704799FDEB187695635BB6158E@EXCH01.terma.com>
Message-ID: <CA+3eh10F9oXOg3nbyOn-B9DwSsV2cdtA7LgbZtC=YAheW99_uA@mail.gmail.com>

On Thu, Jan 15, 2015 at 11:28 AM, Mads Bondo Dydensborg <mbd at terma.com> wrote:
> Hi Volker
>
> Thanks a lot for the info. I do not have VS2012, but I do have .NET 4.5.1. Installing the SP1 solved my problem, but your reference is very handy for other situations. (And, makes me long for the sane world of Linux).
>
> RE the stall : Yes, I have anti-virus software running - this is company policy. Cygwin is 3.0.0-rc1 and I am not allowed to upgrade it. The builds eventually completes, so I guess I can live with it.

That's probably the root cause of the problem. We've the same problem
here. If for some reason the anti-virus isn't running :) you can
observe build performance improvements up to a factor of 2 or 3. You
may also be able to exclude your build directory from beeing scanned
by the anti-virus software, but this again depends on your local
policy. Or you can install another Windows in a VirtualBox/VmWare
without anti-virus software which should still be a lot faster.

Regards,
Volker

>
> Thanks again.
>
> Mads
>
> Mads Bondo Dydensborg
> Senior Software Architect
> Development Programs
> Terma A/S
>
>
> -----Original Message-----
> From: Volker Simonis [mailto:volker.simonis at gmail.com]
> Sent: 15. januar 2015 11:18
> To: Mads Bondo Dydensborg
> Cc: build-dev at openjdk.java.net
> Subject: Re: Problems building jdk8 in Windows - stalls at hotspot, surprisingly continues, refuses to link
>
> Hi Mads,
>
> The COFF isue is a known problem with VS2010 after installing VS2012 or .NET 4.5.1. There exist various workarounds - just google for "LINK
> : fatal error LNK1123: failure during conversion to COFF: file invalid".
>
> The easiest and fastes solution is to remove the bad version of "cvtres.exe" which is causing the problem as explained in the second answer at the stackowerflow question http://stackoverflow.com/questions/10888391/error-link-fatal-error-lnk1123-failure-during-conversion-to-coff-file-inval
>
> Regarding the stall: do you have any Anti-Virus software running?
> That'S known to cause problems. You could also try a newer/other Cygwin version.
>
> Regards,
> Volker
>
> On Thu, Jan 15, 2015 at 9:53 AM, Mads Bondo Dydensborg <mbd at terma.com> wrote:
>> Thanks, Roger, updating Visual Studio Express to service pack 1 seems to allow the build to run to completion.
>>
>> Perhaps this could be suggested in the build guide?
>>
>> The weird "stall" after:
>>
>> Generating jvmtifiles/jvmtiEnvRecommended.cpp
>> Generating jvmtifiles/bytecodeInterpreterWithChecks.cpp
>> Generating jvmtifiles/jvmti.h
>> Generating OpenJDK tracefiles/traceEventClasses.hpp Generating
>> tracefiles/traceEventIds.hpp Generating tracefiles/traceTypes.hpp
>>
>> is somewhat confusing still - I wonder what it is doing? It is not using any CPU, and disk is < 1MB/sec, no noteworthy network activity, and lots of free ram.
>>
>> AFAICT, it is running nmake, but nmake is not really doing anything... which makes no sense, I reckon.
>>
>> Regards
>>
>> Mads
>>
>> Mads Bondo Dydensborg
>> Senior Software Architect
>> Development Programs
>> Terma A/S
>>
>>
>> -----Original Message-----
>> From: build-dev [mailto:build-dev-bounces at openjdk.java.net] On Behalf
>> Of Mads Bondo Dydensborg
>> Sent: 14. januar 2015 16:21
>> To: Roger Riggs; build-dev at openjdk.java.net
>> Subject: RE: Problems building jdk8 in Windows - stalls at hotspot,
>> surprisingly continues, refuses to link
>>
>> Thanks, Roger, have installed, is testing.
>>
>> It still stalls though, so I will have to return on the linker issues later.
>>
>> Thanks,
>>
>> Mads
>>
>> Mads Bondo Dydensborg
>> Senior Software Architect
>> Development Programs
>> Terma A/S
>>
>>
>> -----Original Message-----
>> From: build-dev [mailto:build-dev-bounces at openjdk.java.net] On Behalf
>> Of Roger Riggs
>> Sent: 14. januar 2015 15:49
>> To: build-dev at openjdk.java.net
>> Subject: Re: Problems building jdk8 in Windows - stalls at hotspot,
>> surprisingly continues, refuses to link
>>
>> Hi,
>>
>> I saw that error message "COFF: file invalid or corrupt" using VS 2010 before I installed the Visual Studio 2010_x86_sp1.  Worked ok after.
>>
>> $.02, Roger
>>
>> On 1/14/2015 9:35 AM, Mads Bondo Dydensborg wrote:
>>> Hi there
>>>
>>> I am trying to build jdk8 on Windows 7 64 bit, using cygwin and MS Visual Studio Express. I am pretty experienced in building stuff in Unix/Linux, but Windows is new to me.
>>>
>>> Principally, I am using the guide at http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html, but for reasons I cannot fathom, I am unable to retrieve the sources using hg. So, I am using the source package that can be found on this page: http://download.java.net/openjdk/jdk8/ (132-03).
>>>
>>> I am using
>>>
>>> $ java -version
>>> java version "1.7.0_72"
>>> Java(TM) SE Runtime Environment (build 1.7.0_72-b14) Java HotSpot(TM)
>>> 64-Bit Server VM (build 24.72-b04, mixed mode)
>>>
>>> As the boot Java, freetype is installed, a copy of the .dll.a file has been made.
>>>
>>> I believe I am past the configure step, with the following final output from it:
>>> ====================================================
>>> A new configuration has been successfully created in
>>> /cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_20
>>> 1 4/openjdk/build/windows-x86-normal-server-release
>>> using configure arguments '--with-target-bits=32'.
>>> Configuration summary:
>>> * Debug level:    release
>>> * JDK variant:    normal
>>> * JVM variants:   server
>>> * OpenJDK target: OS: windows, CPU architecture: x86, address length:
>>> 32 Tools summary:
>>> * Environment:    cygwin version 1.7.17(0.262/5/3) (root at /cygdrive/c/apps/cygwin)
>>> * Boot JDK:       java version "1.7.0_72"  Java(TM) SE Runtime Environment (build 1.7.0_72-b14)  Java HotSpot(TM) 64-Bit Server VM (build 24.72-b04, mixed mode)   (at /cygdrive/c/progra~1/java/jdk17~1.0_7)
>>> * C Compiler:     Microsoft CL.EXE version 16.00.30319.01 (at /cygdrive/c/progra~2/micros~1.0/vc/bin/cl)
>>> * C++ Compiler:   Microsoft CL.EXE version 16.00.30319.01 (at /cygdrive/c/progra~2/micros~1.0/vc/bin/cl)
>>> Build performance summary:
>>> * Cores to use:   7
>>> * Memory limit:   15950 MB
>>> * ccache status:  not available for your system
>>>
>>> However, when I try to build, the results are not uplifting. I have tried a couple of different targets, but common for all I have tried, is that they stall/hang somewhere while building the hotspot target. Say, e.g, when trying the JDK:
>>>
>>> make LOG=trace JOBS=1 jdk
>>>
>>> it will stall here:
>>> + nmake -NOLOGO -f
>>> + C:/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/open
>>> + j dk/hotspot/make/windows/build.make Variant=compiler2
>>> + 'WorkSpace=C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_ma
>>> + r _2014\openjdk\hotspot'
>>> + 'BootStrapDir=C:\progra~1\java\jdk17~1.0_7'
>>> + BuildUser=mbd ARCH=x86 BUILDARCH=i486 Platform_arch=x86
>>> + Platform_arch_model=x86_32 ENABLE_FULL_DEBUG_SYMBOLS=1
>>> + ZIP_DEBUGINFO_FILES=1 'RM=rm -f' ZIPEXE=zip JDK_MKTG_VERSION=8.0
>>> + JDK_MAJOR_VER=1 JDK_MINOR_VER=8 JDK_MICRO_VER=0 JDK_BUILD_NUMBER=0
>>> + BUILD_WIN_SA=1 'CXX=C:\progra~2\micros~1.0\vc\bin\cl.exe'
>>> + 'LD=C:\progra~2\micros~1.0\vc\bin\link.exe'
>>> + 'RC=C:\progra~2\micros~3\windows\v7.0a\bin\rc.exe'
>>> + 'MT=C:\progra~2\micros~3\windows\v7.0a\bin\mt.exe'
>>> + 'BOOTDIR=C:\progra~1\java\jdk17~1.0_7'
>>> + 'OUTPUTDIR=C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_ma
>>> + r _2014\openjdk\build\windows-x86-normal-server-release\hotspot'
>>> + 'GAMMADIR=C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar
>>> + _ 2014\openjdk\hotspot' MAKE_VERBOSE=y
>>> + HOTSPOT_RELEASE_VERSION=25.0-b70
>>> + JRE_RELEASE_VERSION=1.8.0-internal-mbd_2015_01_14_13_33-b00
>>> + HOTSPOT_BUILD_VERSION= product
>>>          cd windows_i486_compiler2
>>>          nmake -nologo -f
>>> C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\hotspot\make\windows\makefiles\top.make BUILD_FLAVOR=product ARCH=x86 nmake in ./generated
>>>          cd generated && "C:\Program Files (x86)\Microsoft Visual
>>> Studio 10.0\VC\BIN\nmake.EXE" -NOLOGO -f
>>> C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjd
>>> k \hotspot\make\windows\makefiles\generated.make  DIR=.\generated
>>> BUILD_FLAVOR=product
>>>
>>> Now, I thought it was hanging, but while I tried to figure out more on the web, this particular build suddenly - after a stall about 30-45 minutes - proceeded, and eventually, after a few minutes, produced:
>>>
>>> C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32"
>>> /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D
>>> TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D
>>> TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D
>>> TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D
>>> _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D
>>> "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D
>>> "HOTSPOT_RELEASE_VERSION=\"25.0-b70\"" /D
>>> "JRE_RELEASE_VERSION=\"1.8.0-internal-mbd_2015_01_14_13_33-b00\"" /D
>>> "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D
>>> "HOTSPOT_BUILD_USER=\"mbd\"" /D "HOTSPOT_VM_DISTRO=\"OpenJDK\"" /I
>>> "..\generated"  /I
>>> "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openj
>>> d
>>> k\hotspot\src\share\vm"  /I
>>> "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openj
>>> d k\hotspot\src\share\vm\precompiled"  /I
>>> "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openj
>>> d
>>> k\hotspot\src\share\vm\prims"  /I
>>> "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openj
>>> d
>>> k\hotspot\src\os\windows\vm"  /I
>>> "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openj
>>> d k\hotspot\src\os_cpu\windows_x86\vm"  /I
>>> "C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openj
>>> d k\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch"
>>> /Yu"precompiled.hpp" /c ..\generated\adfiles\ad_x86_32.cpp
>>> ..\generated\adfiles\ad_x86_32_clone.cpp
>>> ..\generated\adfiles\ad_x86_32_expand.cpp
>>> ..\generated\adfiles\ad_x86_32_format.cpp
>>> ..\generated\adfiles\ad_x86_32_gen.cpp
>>> ..\generated\adfiles\ad_x86_32_misc.cpp
>>> ..\generated\adfiles\ad_x86_32_peephole.cpp
>>> ..\generated\adfiles\ad_x86_32_pipeline.cpp
>>> ..\generated\adfiles\dfa_x86_32.cpp
>>> ad_x86_32.cpp
>>> ad_x86_32_clone.cpp
>>> ad_x86_32_expand.cpp
>>> ad_x86_32_format.cpp
>>> ad_x86_32_gen.cpp
>>> ad_x86_32_misc.cpp
>>> ad_x86_32_peephole.cpp
>>> ad_x86_32_pipeline.cpp
>>> dfa_x86_32.cpp
>>>          sh C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\hotspot/make/windows/build_vm_def.sh
>>>          C:\progra~2\micros~1.0\vc\bin\link.exe @C:\apps\cygwin\tmp\nm76D6.tmp
>>>     Creating library jvm.lib and object jvm.exp
>>>
>>> LINK : fatal error LNK1123: failure during conversion to COFF: file
>>> invalid or corrupt NMAKE : fatal error U1077: 'C:\progra~2\micros~1.0\vc\bin\link.exe' : return code '0x463'
>>> Stop.
>>> NMAKE : fatal error U1077: 'cd' : return code '0x2'
>>> Stop.
>>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\nmake.EXE"' : return code '0x2'
>>> Stop.
>>> Makefile:216: recipe for target `generic_build2' failed
>>> make[3]: *** [generic_build2] Error 2
>>> make[3]: Leaving directory `/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/hotspot/make'
>>> Makefile:167: recipe for target `product' failed
>>> make[2]: *** [product] Error 2
>>> make[2]: Leaving directory `/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/hotspot/make'
>>> HotspotWrapper.gmk:44: recipe for target
>>> `/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2
>>> 0
>>> 14/openjdk/build/windows-x86-normal-server-release/hotspot/_hotspot.t
>>> i
>>> mestamp' failed
>>> make[1]: ***
>>> [/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2
>>> 0
>>> 14/openjdk/build/windows-x86-normal-server-release/hotspot/_hotspot.t
>>> i
>>> mestamp] Error 2
>>> make[1]: Leaving directory `/cygdrive/c/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/make'
>>> /home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk//make/Main.g
>>> m
>>> k:108: recipe for target `hotspot-only' failed
>>> make: *** [hotspot-only] Error 2
>>>
>>> I am a bit stumped at this time, and would much appreciate a hand. I have the config.log and build.log preserved, but at this point, I did not want to spam the list more than necessary.
>>>
>>> Any help/ideas/suggestions much appreciated.
>>>
>>> Thanks
>>>
>>> Mads
>>
>>


From magnus.ihse.bursie at oracle.com  Thu Jan 15 13:41:46 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 15 Jan 2015 14:41:46 +0100
Subject: [aarch64-port-dev ] AARCH64: RFR (XS) 8068927: AARCH64: better
	handling of aarch64- triples (was RFR: AARCH64: Top-level JDK changes)
In-Reply-To: <54B6FCF7.1010202@oracle.com>
References: <545CFFA9.4070107@redhat.com>	<545D0290.5080307@oracle.com>	<CA+3eh13Byz2VWW6GA_X00np7DU=-xp7nmA-t1iCygU4EU7FOjA@mail.gmail.com>	<54B34E20.5030506@oracle.com>	<54B3A108.9070203@redhat.com>	<54B4DAD4.5060904@oracle.com>	<54B4E083.9040502@redhat.com>
	<54B56A55.3020803@oracle.com> <54B6FCF7.1010202@oracle.com>
Message-ID: <54B7C39A.1050000@oracle.com>

On 2015-01-15 00:34, Dean Long wrote:
> Can I get a review for this?
>
> https://bugs.openjdk.java.net/browse/JDK-8068927
> http://cr.openjdk.java.net/~dlong/8068927/webrev/

Looks good to me. (However, I'm not a formal reviewer for the 
aarch64-port project)

/Magnus



From magnus.ihse.bursie at oracle.com  Thu Jan 15 13:44:32 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 15 Jan 2015 14:44:32 +0100
Subject: RFR: AARCH64: Top-level JDK changes
In-Reply-To: <54B6E782.3040405@oracle.com>
References: <545CFFA9.4070107@redhat.com>	<545D0290.5080307@oracle.com>	<CA+3eh13Byz2VWW6GA_X00np7DU=-xp7nmA-t1iCygU4EU7FOjA@mail.gmail.com>
	<54B34E20.5030506@oracle.com> <54B3B4CE.8060804@oracle.com>
	<54B4D82B.3050608@oracle.com> <54B66EB3.3020601@oracle.com>
	<54B6E782.3040405@oracle.com>
Message-ID: <54B7C440.7070807@oracle.com>

On 2015-01-14 23:02, Dean Long wrote:
> On 1/14/2015 5:27 AM, Magnus Ihse Bursie wrote:
>> On 2015-01-13 09:32, Dean Long wrote:
>>> On 1/12/2015 3:49 AM, Magnus Ihse Bursie wrote:
>>>> On 2015-01-12 05:31, Dean Long wrote:
>>>>> I found a small problem with the new config.sub wrapper.  It works 
>>>>> with the bash shell but not with the dash shell.
>>>>> The problem seems to be with this line:
>>>>>
>>>>>     result=`. $DIR/autoconf-config.sub $sub_args "$@"`
>>>>>
>>>>> "dash" doesn't seem to support args passed with ".", so $sub_args 
>>>>> "$@" are ignored.
>>>>
>>>> bash is the required shell for running configure. We do not support 
>>>> non-bash shells. In fact, we go to lengths to try to ensure that we 
>>>> are indeed running under bash.
>>>>
>>>> /Magnus
>>> I was thinking 'bash configure' was enough, but it turns out 
>>> 'CONFIG_SHELL=bash bash configure' gives better results.
>>
>> Hm, that's interesting. We were attempting to automatically use bash 
>> in the real configure script, regardless of what shell the user had 
>> to start the top-level configure wrapper.
>>
>> If you try the patch below, does it work better when you run "dash 
>> configure"?
>>
>> diff --git a/common/autoconf/configure b/common/autoconf/configure
>> --- a/common/autoconf/configure
>> +++ b/common/autoconf/configure
>> @@ -36,6 +36,13 @@
>>    shift
>>  fi
>>
>> +if test "x$BASH" = x; then
>> +  echo "Error: This script must be run using bash." 1>&2
>> +  exit 1
>> +fi
>> +# Force autoconf to use bash
>> +export CONFIG_SHELL=$BASH
>> +
>>  conf_script_dir="$TOPDIR/common/autoconf"
>>
>>  if [ "$CUSTOM_CONFIG_DIR" = "" ]; then
>>
>> /Magnus
>>
>
> Yes, that patch solves the problem.

Thank you for testing it! I have opened 
https://bugs.openjdk.java.net/browse/JDK-8069057 and will integrate the 
fix to jdk9-dev.

/Magnus


From magnus.ihse.bursie at oracle.com  Thu Jan 15 13:46:44 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 15 Jan 2015 14:46:44 +0100
Subject: RFR: JDK-8069057 Make sure configure is run by bash
Message-ID: <54B7C4C4.8010001@oracle.com>

It turns out that our effort to make sure the configure script is run by 
bash is not fool-proof.

The fix is to set CONFIG_SHELL ahead of calling the autoconf script.

Thanks to Dean Long for finding out the issue and testing the patch with 
dash.

Bug: https://bugs.openjdk.java.net/browse/JDK-8069057
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8069057-enforce-bash-in-configure/webrev.01

/Magnus


From magnus.ihse.bursie at oracle.com  Thu Jan 15 14:34:14 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 15 Jan 2015 15:34:14 +0100
Subject: RFR: JDK-8069063 More merge errors following JDK-8049367 (Modular
	Run-Time Images)
Message-ID: <54B7CFE6.6070704@oracle.com>

JDK-8066769 fixed most, but unfortunately not all, of the merge errors 
following Jigsaw M2.

This is a trivial logging failure in Native Compilation.

Bug: https://bugs.openjdk.java.net/browse/JDK-8069063
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8069063-more-jigsaw-merge-errors/webrev.01

/Magnus


From erik.joelsson at oracle.com  Thu Jan 15 14:34:45 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 15 Jan 2015 15:34:45 +0100
Subject: RFR: JDK-8069063 More merge errors following JDK-8049367 (Modular
	Run-Time Images)
In-Reply-To: <54B7CFE6.6070704@oracle.com>
References: <54B7CFE6.6070704@oracle.com>
Message-ID: <54B7D005.3070405@oracle.com>

Looks good to me.

/Erik

On 2015-01-15 15:34, Magnus Ihse Bursie wrote:
> JDK-8066769 fixed most, but unfortunately not all, of the merge errors 
> following Jigsaw M2.
>
> This is a trivial logging failure in Native Compilation.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8069063
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8069063-more-jigsaw-merge-errors/webrev.01
>
> /Magnus



From erik.joelsson at oracle.com  Thu Jan 15 14:35:16 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 15 Jan 2015 15:35:16 +0100
Subject: RFR: JDK-8069057 Make sure configure is run by bash
In-Reply-To: <54B7C4C4.8010001@oracle.com>
References: <54B7C4C4.8010001@oracle.com>
Message-ID: <54B7D024.8000500@oracle.com>

Looks good to me.

/Erik

On 2015-01-15 14:46, Magnus Ihse Bursie wrote:
> It turns out that our effort to make sure the configure script is run 
> by bash is not fool-proof.
>
> The fix is to set CONFIG_SHELL ahead of calling the autoconf script.
>
> Thanks to Dean Long for finding out the issue and testing the patch 
> with dash.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8069057
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8069057-enforce-bash-in-configure/webrev.01
>
> /Magnus



From magnus.ihse.bursie at oracle.com  Thu Jan 15 15:23:05 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 15 Jan 2015 16:23:05 +0100
Subject: RFR: JDK-8069064 Various improvements and fixes in build system
Message-ID: <54B7DB59.9040102@oracle.com>

  This fix is the result of preparatory work in the build-infra project. 
It includes:
* Remove duplicate detection of comm on Windows
* compare.sh enhancements and bug fixes
* Do not fail in SetupFoo macros on empty arguments
* Minor JavaCompilation enhancements
* Makefile warns for unknown control variables
* Improved "make help"

Bug: https://bugs.openjdk.java.net/browse/JDK-8069064
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8069064-fixes-from-build-infra/webrev.01

/Magnus


From erik.joelsson at oracle.com  Thu Jan 15 15:32:22 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 15 Jan 2015 16:32:22 +0100
Subject: RFR: JDK-8069064 Various improvements and fixes in build system
In-Reply-To: <54B7DB59.9040102@oracle.com>
References: <54B7DB59.9040102@oracle.com>
Message-ID: <54B7DD86.50508@oracle.com>

Looks good to me.

/Erik

On 2015-01-15 16:23, Magnus Ihse Bursie wrote:
>  This fix is the result of preparatory work in the build-infra 
> project. It includes:
> * Remove duplicate detection of comm on Windows
> * compare.sh enhancements and bug fixes
> * Do not fail in SetupFoo macros on empty arguments
> * Minor JavaCompilation enhancements
> * Makefile warns for unknown control variables
> * Improved "make help"
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8069064
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8069064-fixes-from-build-infra/webrev.01
>
> /Magnus



From volker.simonis at gmail.com  Thu Jan 15 17:33:48 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 15 Jan 2015 18:33:48 +0100
Subject: RFR: JDK-8069064 Various improvements and fixes in build system
In-Reply-To: <54B7DB59.9040102@oracle.com>
References: <54B7DB59.9040102@oracle.com>
Message-ID: <CA+3eh11q_k=8OXgm-Q=baHzxwaRjX_n2H8g+VmYCvjdyAOTU8g@mail.gmail.com>

Hi Magnus,

I've only had a quick look at your changes but I have a question.

When looking at the "make help" I think the relationship between
"repo", "target" and "module" is a little unclear.

As far as I understand a "target" is an artefact which can be named
and build by "make".
A "repo" is a collection of sources which is defined by our version
control system.
A "module" is a logical part of the resulting build output.

All these three are orthogonal (i.e. a "target" can build many
"modules" or just a part of a module, a "repo" can contain several
modules or just the part of a module, etc.)

I think that the division of the OpenJDK source into different repos
is unfortunate and somehow arbitrary. So maybe we should try to avoid
this term when speaking about make targets and modules.

I would also wish there was a dynamically created list of buildable
modules so we could do something like "make modules" to get this list.
I don't know if this is easily possible, it's just an idea.

Also the line "make [default]         # Compile all modules in
langtools, hotspot, jdk, jaxws,.." seems a little confusing to me. It
speaks about modules but lists the current repos. So what are the
available moduls? What does "[default]" stands for?

I like the two "clean" targets:

make clean-<module>
make clean-<module>-<phase>

they are clear and concise (besides the fact that there's no module list).

I'd wish to have the same syntax for the build targets (instead of
make [default]). Something like:

make <module>
make <module>-<phase>
make jdk-image                      Creates a jre image containing
these modules (...) and docs
make jre-image                       Creates a jre image containing
these modules (...) and docs
make images                          Creates both, the jre and the jdk image

I'm aware that this mail degenerated more into a wish-list than a
review :) Maybe you find it useful nevertheless.

Regards,
Volker


On Thu, Jan 15, 2015 at 4:23 PM, Magnus Ihse Bursie
<magnus.ihse.bursie at oracle.com> wrote:
>  This fix is the result of preparatory work in the build-infra project. It
> includes:
> * Remove duplicate detection of comm on Windows
> * compare.sh enhancements and bug fixes
> * Do not fail in SetupFoo macros on empty arguments
> * Minor JavaCompilation enhancements
> * Makefile warns for unknown control variables
> * Improved "make help"
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8069064
> WebRev:
> http://cr.openjdk.java.net/~ihse/JDK-8069064-fixes-from-build-infra/webrev.01
>
> /Magnus


From dean.long at oracle.com  Thu Jan 15 20:04:51 2015
From: dean.long at oracle.com (Dean Long)
Date: Thu, 15 Jan 2015 12:04:51 -0800
Subject: [aarch64-port-dev ] AARCH64: RFR (XS) 8068927: AARCH64: better
	handling of aarch64- triples (was RFR: AARCH64: Top-level JDK changes)
In-Reply-To: <54B7C39A.1050000@oracle.com>
References: <545CFFA9.4070107@redhat.com>	<545D0290.5080307@oracle.com>	<CA+3eh13Byz2VWW6GA_X00np7DU=-xp7nmA-t1iCygU4EU7FOjA@mail.gmail.com>	<54B34E20.5030506@oracle.com>	<54B3A108.9070203@redhat.com>	<54B4DAD4.5060904@oracle.com>	<54B4E083.9040502@redhat.com>
	<54B56A55.3020803@oracle.com> <54B6FCF7.1010202@oracle.com>
	<54B7C39A.1050000@oracle.com>
Message-ID: <54B81D63.3050207@oracle.com>

On 1/15/2015 5:41 AM, Magnus Ihse Bursie wrote:
> On 2015-01-15 00:34, Dean Long wrote:
>> Can I get a review for this?
>>
>> https://bugs.openjdk.java.net/browse/JDK-8068927
>> http://cr.openjdk.java.net/~dlong/8068927/webrev/
>
> Looks good to me. (However, I'm not a formal reviewer for the 
> aarch64-port project)
>
> /Magnus
>
You're a Reviewer for jdk9, and this change will be going into 9 after 
it does its time in aarch64 staging,
so I hope that's good enough.

dl


From magnus.ihse.bursie at oracle.com  Thu Jan 15 21:00:21 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 15 Jan 2015 22:00:21 +0100
Subject: RFR: JDK-8069041: Bootcycle builds do not work with sjavac
In-Reply-To: <54B78693.8070608@oracle.com>
References: <54B78693.8070608@oracle.com>
Message-ID: <54B82A65.3040304@oracle.com>

On 2015-01-15 10:21, Erik Joelsson wrote:
> Hello,
>
> Please review this small patch which fixes bootcycle-images builds 
> when enabling sjavac. The problem was that the directory where the 
> portfile should be created is never created in the bootcycle-build 
> output directory. I think the best and simplest solution is to just 
> always create it prior to running sjavac.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8069041
> Patch inline:
> diff -r 378fd58fe406 make/common/JavaCompilation.gmk
> --- a/make/common/JavaCompilation.gmk
> +++ b/make/common/JavaCompilation.gmk
> @@ -538,7 +538,7 @@
> $1_REMOTE:=--server:portfile=$$($1_SJAVAC_PORTFILE),id=$1,sjavac=$$(subst 
> $$(SPACE),%20,$$(subst $$(COMMA),%2C,$$(strip $$($1_SERVER_JVM) 
> $$($1_SJAVAC))))
>
>      $$($1_BIN)/_the.$1_batch: $$($1_SRCS) $$($1_DEPENDS)
> -    $(MKDIR) -p $$(@D)
> +    $(MKDIR) -p $$(@D) $$(dir $$($1_SJAVAC_PORTFILE))
>          # As a workaround for sjavac not tracking api changed from 
> the classpath, force full
>          # recompile if an external dependency, which is something 
> other than a source
>          # change, triggered this compilation.
>
> /Erik

Looks good to me.

/Magnus



From magnus.ihse.bursie at oracle.com  Thu Jan 15 22:57:39 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 15 Jan 2015 23:57:39 +0100
Subject: RFR (XS) 8031064: build_vm_def.sh not working correctly for new
	build cross compile
In-Reply-To: <54B765DC.8050801@oracle.com>
References: <54B6FA6C.40202@oracle.com>
	<54B75EB5.3020407@oracle.com>	<54B760DB.70200@oracle.com>
	<54B765DC.8050801@oracle.com>
Message-ID: <54B845E3.7060000@oracle.com>

On 2015-01-15 08:01, David Holmes wrote:
>
> If the build-dev guys confirm we already assume bash that is fine.

For the rest of the world, we only use bash. For hotspot, we will use 
bash if called from the top-level Makefile. I can't say anything about 
what the convention have been for calling the hotspot makefiles 
directly, though.

/Magnus


From bradford.wetmore at oracle.com  Fri Jan 16 01:56:48 2015
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Thu, 15 Jan 2015 17:56:48 -0800
Subject: RFR: JDK-8068748: missing US_export_policy.jar in jdk9-b44 is
	causing compilation errors building jdk9 source code
In-Reply-To: <54B79EFE.7050202@oracle.com>
References: <54B79EFE.7050202@oracle.com>
Message-ID: <54B86FE0.3000908@oracle.com>


Looks good, thanks for fixing this!

Brad



On 1/15/2015 3:05 AM, Erik Joelsson wrote:
> Hello,
>
> Please review the open part of this patch, which changes the building of
> policy jars to happen even if BUILD_CRYPTO is false. Previously these
> weren't built as there were signed versions of these jars, but since we
> no longer sign them, there is no need to not build them.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8068748
> Webrev: http://cr.openjdk.java.net/~erikj/8068748/webrev.jdk.01/
>
> The webrev diffs look a bit weird. The only thing I did was to remove
> the "ifneq ($(BUILD_CRYPTO), no)" and adjust the indentation.
>
> /Erik


From erik.joelsson at oracle.com  Fri Jan 16 08:31:10 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 16 Jan 2015 09:31:10 +0100
Subject: RFR: JDK-8069064 Various improvements and fixes in build system
In-Reply-To: <CA+3eh11q_k=8OXgm-Q=baHzxwaRjX_n2H8g+VmYCvjdyAOTU8g@mail.gmail.com>
References: <54B7DB59.9040102@oracle.com>
	<CA+3eh11q_k=8OXgm-Q=baHzxwaRjX_n2H8g+VmYCvjdyAOTU8g@mail.gmail.com>
Message-ID: <54B8CC4E.7030606@oracle.com>

Hello Volker,

I think I'm mostly to blame for the current state of the make help text 
and I certainly value feedback on it. I agree that talk of repos in the 
help text is just confusing at this point. The pre modules build was 
organized around repos and I got stuck in that thinking when I tried to 
describe the new targets.

Listing available modules is a good idea and implementing it is pretty 
easy. The make targets themselves are dynamically generated from the 
dynamic list of modules. Perhaps a new line of targets named 
list-modules, list-phases etc, or perhaps build on the existing help 
target, help-modules, help-phases, help-clean etc, which would give more 
detailed lists of available targets for those areas?

What you can do right now, if you use bash, is activating advanced bash 
completion. Then you can type "make " and tab your way through the 
targets, which is what I usually do. A warning though that without 
typing a few letters, you get several hundreds targets listed.

/Erik

On 2015-01-15 18:33, Volker Simonis wrote:
> Hi Magnus,
>
> I've only had a quick look at your changes but I have a question.
>
> When looking at the "make help" I think the relationship between
> "repo", "target" and "module" is a little unclear.
>
> As far as I understand a "target" is an artefact which can be named
> and build by "make".
> A "repo" is a collection of sources which is defined by our version
> control system.
> A "module" is a logical part of the resulting build output.
>
> All these three are orthogonal (i.e. a "target" can build many
> "modules" or just a part of a module, a "repo" can contain several
> modules or just the part of a module, etc.)
>
> I think that the division of the OpenJDK source into different repos
> is unfortunate and somehow arbitrary. So maybe we should try to avoid
> this term when speaking about make targets and modules.
>
> I would also wish there was a dynamically created list of buildable
> modules so we could do something like "make modules" to get this list.
> I don't know if this is easily possible, it's just an idea.
>
> Also the line "make [default]         # Compile all modules in
> langtools, hotspot, jdk, jaxws,.." seems a little confusing to me. It
> speaks about modules but lists the current repos. So what are the
> available moduls? What does "[default]" stands for?
>
> I like the two "clean" targets:
>
> make clean-<module>
> make clean-<module>-<phase>
>
> they are clear and concise (besides the fact that there's no module list).
>
> I'd wish to have the same syntax for the build targets (instead of
> make [default]). Something like:
>
> make <module>
> make <module>-<phase>
> make jdk-image                      Creates a jre image containing
> these modules (...) and docs
> make jre-image                       Creates a jre image containing
> these modules (...) and docs
> make images                          Creates both, the jre and the jdk image
>
> I'm aware that this mail degenerated more into a wish-list than a
> review :) Maybe you find it useful nevertheless.
>
> Regards,
> Volker
>
>
> On Thu, Jan 15, 2015 at 4:23 PM, Magnus Ihse Bursie
> <magnus.ihse.bursie at oracle.com> wrote:
>>   This fix is the result of preparatory work in the build-infra project. It
>> includes:
>> * Remove duplicate detection of comm on Windows
>> * compare.sh enhancements and bug fixes
>> * Do not fail in SetupFoo macros on empty arguments
>> * Minor JavaCompilation enhancements
>> * Makefile warns for unknown control variables
>> * Improved "make help"
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8069064
>> WebRev:
>> http://cr.openjdk.java.net/~ihse/JDK-8069064-fixes-from-build-infra/webrev.01
>>
>> /Magnus



From volker.simonis at gmail.com  Fri Jan 16 09:34:08 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 16 Jan 2015 10:34:08 +0100
Subject: RFR: JDK-8069064 Various improvements and fixes in build system
In-Reply-To: <54B8CC4E.7030606@oracle.com>
References: <54B7DB59.9040102@oracle.com>
	<CA+3eh11q_k=8OXgm-Q=baHzxwaRjX_n2H8g+VmYCvjdyAOTU8g@mail.gmail.com>
	<54B8CC4E.7030606@oracle.com>
Message-ID: <CA+3eh13Effd_ZaJOxNG05ZE3W+-Vo0EQSgsK3DH3kwRYwR6UrQ@mail.gmail.com>

On Fri, Jan 16, 2015 at 9:31 AM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> Hello Volker,
>
> I think I'm mostly to blame for the current state of the make help text and
> I certainly value feedback on it. I agree that talk of repos in the help
> text is just confusing at this point. The pre modules build was organized
> around repos and I got stuck in that thinking when I tried to describe the
> new targets.
>
> Listing available modules is a good idea and implementing it is pretty easy.
> The make targets themselves are dynamically generated from the dynamic list
> of modules. Perhaps a new line of targets named list-modules, list-phases
> etc, or perhaps build on the existing help target, help-modules,
> help-phases, help-clean etc, which would give more detailed lists of
> available targets for those areas?
>

Sounds good!

> What you can do right now, if you use bash, is activating advanced bash
> completion. Then you can type "make " and tab your way through the targets,
> which is what I usually do. A warning though that without typing a few
> letters, you get several hundreds targets listed.
>

Aadvanced bash completion is a cool feature I wasn't aware of until
now - thanks for mentioning it.

Unfortunately it doesn't seem to work out of the box on my Ubuntu
12.04. I only get:

$ make [TAB][TAB]
default   Error     help      Makefile

Do you use a special completion script?

Thanks you and best regards,
Volker

> /Erik
>
>
> On 2015-01-15 18:33, Volker Simonis wrote:
>>
>> Hi Magnus,
>>
>> I've only had a quick look at your changes but I have a question.
>>
>> When looking at the "make help" I think the relationship between
>> "repo", "target" and "module" is a little unclear.
>>
>> As far as I understand a "target" is an artefact which can be named
>> and build by "make".
>> A "repo" is a collection of sources which is defined by our version
>> control system.
>> A "module" is a logical part of the resulting build output.
>>
>> All these three are orthogonal (i.e. a "target" can build many
>> "modules" or just a part of a module, a "repo" can contain several
>> modules or just the part of a module, etc.)
>>
>> I think that the division of the OpenJDK source into different repos
>> is unfortunate and somehow arbitrary. So maybe we should try to avoid
>> this term when speaking about make targets and modules.
>>
>> I would also wish there was a dynamically created list of buildable
>> modules so we could do something like "make modules" to get this list.
>> I don't know if this is easily possible, it's just an idea.
>>
>> Also the line "make [default]         # Compile all modules in
>> langtools, hotspot, jdk, jaxws,.." seems a little confusing to me. It
>> speaks about modules but lists the current repos. So what are the
>> available moduls? What does "[default]" stands for?
>>
>> I like the two "clean" targets:
>>
>> make clean-<module>
>> make clean-<module>-<phase>
>>
>> they are clear and concise (besides the fact that there's no module list).
>>
>> I'd wish to have the same syntax for the build targets (instead of
>> make [default]). Something like:
>>
>> make <module>
>> make <module>-<phase>
>> make jdk-image                      Creates a jre image containing
>> these modules (...) and docs
>> make jre-image                       Creates a jre image containing
>> these modules (...) and docs
>> make images                          Creates both, the jre and the jdk
>> image
>>
>> I'm aware that this mail degenerated more into a wish-list than a
>> review :) Maybe you find it useful nevertheless.
>>
>> Regards,
>> Volker
>>
>>
>> On Thu, Jan 15, 2015 at 4:23 PM, Magnus Ihse Bursie
>> <magnus.ihse.bursie at oracle.com> wrote:
>>>
>>>   This fix is the result of preparatory work in the build-infra project.
>>> It
>>> includes:
>>> * Remove duplicate detection of comm on Windows
>>> * compare.sh enhancements and bug fixes
>>> * Do not fail in SetupFoo macros on empty arguments
>>> * Minor JavaCompilation enhancements
>>> * Makefile warns for unknown control variables
>>> * Improved "make help"
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8069064
>>> WebRev:
>>>
>>> http://cr.openjdk.java.net/~ihse/JDK-8069064-fixes-from-build-infra/webrev.01
>>>
>>> /Magnus
>
>


From erik.joelsson at oracle.com  Fri Jan 16 10:22:24 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 16 Jan 2015 11:22:24 +0100
Subject: RFR: JDK-8069064 Various improvements and fixes in build system
In-Reply-To: <CA+3eh13Effd_ZaJOxNG05ZE3W+-Vo0EQSgsK3DH3kwRYwR6UrQ@mail.gmail.com>
References: <54B7DB59.9040102@oracle.com>	<CA+3eh11q_k=8OXgm-Q=baHzxwaRjX_n2H8g+VmYCvjdyAOTU8g@mail.gmail.com>	<54B8CC4E.7030606@oracle.com>
	<CA+3eh13Effd_ZaJOxNG05ZE3W+-Vo0EQSgsK3DH3kwRYwR6UrQ@mail.gmail.com>
Message-ID: <54B8E660.2090601@oracle.com>


On 2015-01-16 10:34, Volker Simonis wrote:
> Aadvanced bash completion is a cool feature I wasn't aware of until
> now - thanks for mentioning it.
>
> Unfortunately it doesn't seem to work out of the box on my Ubuntu
> 12.04. I only get:
>
> $ make [TAB][TAB]
> default   Error     help      Makefile
>
> Do you use a special completion script?
No, I just use the default in Ubuntu (after having enabled it in 
/etc/bash.bashrc since it's default off). I run 14.04, but have been 
using bash completion since before 12.04 so I would expect it to work.

/Erik
> Thanks you and best regards,
> Volker
>
>> /Erik
>>
>>
>> On 2015-01-15 18:33, Volker Simonis wrote:
>>> Hi Magnus,
>>>
>>> I've only had a quick look at your changes but I have a question.
>>>
>>> When looking at the "make help" I think the relationship between
>>> "repo", "target" and "module" is a little unclear.
>>>
>>> As far as I understand a "target" is an artefact which can be named
>>> and build by "make".
>>> A "repo" is a collection of sources which is defined by our version
>>> control system.
>>> A "module" is a logical part of the resulting build output.
>>>
>>> All these three are orthogonal (i.e. a "target" can build many
>>> "modules" or just a part of a module, a "repo" can contain several
>>> modules or just the part of a module, etc.)
>>>
>>> I think that the division of the OpenJDK source into different repos
>>> is unfortunate and somehow arbitrary. So maybe we should try to avoid
>>> this term when speaking about make targets and modules.
>>>
>>> I would also wish there was a dynamically created list of buildable
>>> modules so we could do something like "make modules" to get this list.
>>> I don't know if this is easily possible, it's just an idea.
>>>
>>> Also the line "make [default]         # Compile all modules in
>>> langtools, hotspot, jdk, jaxws,.." seems a little confusing to me. It
>>> speaks about modules but lists the current repos. So what are the
>>> available moduls? What does "[default]" stands for?
>>>
>>> I like the two "clean" targets:
>>>
>>> make clean-<module>
>>> make clean-<module>-<phase>
>>>
>>> they are clear and concise (besides the fact that there's no module list).
>>>
>>> I'd wish to have the same syntax for the build targets (instead of
>>> make [default]). Something like:
>>>
>>> make <module>
>>> make <module>-<phase>
>>> make jdk-image                      Creates a jre image containing
>>> these modules (...) and docs
>>> make jre-image                       Creates a jre image containing
>>> these modules (...) and docs
>>> make images                          Creates both, the jre and the jdk
>>> image
>>>
>>> I'm aware that this mail degenerated more into a wish-list than a
>>> review :) Maybe you find it useful nevertheless.
>>>
>>> Regards,
>>> Volker
>>>
>>>
>>> On Thu, Jan 15, 2015 at 4:23 PM, Magnus Ihse Bursie
>>> <magnus.ihse.bursie at oracle.com> wrote:
>>>>    This fix is the result of preparatory work in the build-infra project.
>>>> It
>>>> includes:
>>>> * Remove duplicate detection of comm on Windows
>>>> * compare.sh enhancements and bug fixes
>>>> * Do not fail in SetupFoo macros on empty arguments
>>>> * Minor JavaCompilation enhancements
>>>> * Makefile warns for unknown control variables
>>>> * Improved "make help"
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8069064
>>>> WebRev:
>>>>
>>>> http://cr.openjdk.java.net/~ihse/JDK-8069064-fixes-from-build-infra/webrev.01
>>>>
>>>> /Magnus
>>



From dean.long at oracle.com  Fri Jan 16 10:47:27 2015
From: dean.long at oracle.com (Dean Long)
Date: Fri, 16 Jan 2015 02:47:27 -0800
Subject: RFR (XS) 8031064: build_vm_def.sh not working correctly for new
	build cross compile
In-Reply-To: <54B845E3.7060000@oracle.com>
References: <54B6FA6C.40202@oracle.com>
	<54B75EB5.3020407@oracle.com>	<54B760DB.70200@oracle.com>
	<54B765DC.8050801@oracle.com> <54B845E3.7060000@oracle.com>
Message-ID: <54B8EC3F.5030408@oracle.com>

On 1/15/2015 2:57 PM, Magnus Ihse Bursie wrote:
> On 2015-01-15 08:01, David Holmes wrote:
>>
>> If the build-dev guys confirm we already assume bash that is fine.
>
> For the rest of the world, we only use bash. For hotspot, we will use 
> bash if called from the top-level Makefile. I can't say anything about 
> what the convention have been for calling the hotspot makefiles 
> directly, though.
>
> /Magnus

"sh" or "bash", it shouldn't matter.  Our makefiles are already using 
Bourne shell syntax,
so if someone tries to use "make SHELL=csh", it will fail almost 
immediately.  Therefore,
I think "NM=$(NM) sh ..." should be safe.

dl

https://www.gnu.org/software/make/manual/make.html#Choosing-the-Shell


From magnus.ihse.bursie at oracle.com  Fri Jan 16 13:38:32 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 16 Jan 2015 14:38:32 +0100
Subject: RFR: JDK-8069064 Various improvements and fixes in build system
In-Reply-To: <CA+3eh13Effd_ZaJOxNG05ZE3W+-Vo0EQSgsK3DH3kwRYwR6UrQ@mail.gmail.com>
References: <54B7DB59.9040102@oracle.com>	<CA+3eh11q_k=8OXgm-Q=baHzxwaRjX_n2H8g+VmYCvjdyAOTU8g@mail.gmail.com>	<54B8CC4E.7030606@oracle.com>
	<CA+3eh13Effd_ZaJOxNG05ZE3W+-Vo0EQSgsK3DH3kwRYwR6UrQ@mail.gmail.com>
Message-ID: <54B91458.70102@oracle.com>

On 2015-01-16 10:34, Volker Simonis wrote:
>> What you can do right now, if you use bash, is activating advanced bash
>> completion. Then you can type "make " and tab your way through the targets,
>> which is what I usually do. A warning though that without typing a few
>> letters, you get several hundreds targets listed.
>>
> Aadvanced bash completion is a cool feature I wasn't aware of until
> now - thanks for mentioning it.
>
> Unfortunately it doesn't seem to work out of the box on my Ubuntu
> 12.04. I only get:
>
> $ make [TAB][TAB]
> default   Error     help      Makefile
>
> Do you use a special completion script?

I believe you might be trying this is a non-bleeding-edge repo. :-)

The problem is not in the bash completion, but in the makefile. This is 
what happens if you do not have exactly one configuration, and are 
standing in the source root directory. :-( This was very recently fixed 
in jdk9, so that it should work even with multiple configurations, or 
when standing in the build output directory. Without any configuration 
at all, this is all you'll ever get, though (because without a 
configuration, make cannot figure out which targets should be available, 
and in a way, "no" targets are available unless you have a configuration).

/Magnus


From magnus.ihse.bursie at oracle.com  Fri Jan 16 13:41:56 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 16 Jan 2015 14:41:56 +0100
Subject: RFR: JDK-8069064 Various improvements and fixes in build system
In-Reply-To: <CA+3eh13Effd_ZaJOxNG05ZE3W+-Vo0EQSgsK3DH3kwRYwR6UrQ@mail.gmail.com>
References: <54B7DB59.9040102@oracle.com>	<CA+3eh11q_k=8OXgm-Q=baHzxwaRjX_n2H8g+VmYCvjdyAOTU8g@mail.gmail.com>	<54B8CC4E.7030606@oracle.com>
	<CA+3eh13Effd_ZaJOxNG05ZE3W+-Vo0EQSgsK3DH3kwRYwR6UrQ@mail.gmail.com>
Message-ID: <54B91524.20808@oracle.com>

On 2015-01-16 10:34, Volker Simonis wrote:

> Aadvanced bash completion is a cool feature I wasn't aware of until
> now - thanks for mentioning it.
Also, it could be worth mentioning that bash completion works with 
configure as well, but with a twist. The "bash configure" call pattern 
does not work. :-(

So either you need to chmod your configure to executable (but this means 
you must make sure not to check in that change), or you can add a helper 
binary like the one below in your path (that's my choice).

Then you can do "configure --with-<TAB>" and get help with options.

Helper script:
ihse:~/bin$ cat configure
#!/bin/bash
if [ $(pwd) = $(cd $(dirname $0); pwd) ] ; then
   echo >&2 "Abort: Trying to call configure helper recursively"
   exit 1
fi

bash $PWD/configure "$@"

/Magnus


>
> Unfortunately it doesn't seem to work out of the box on my Ubuntu
> 12.04. I only get:
>
> $ make [TAB][TAB]
> default   Error     help      Makefile
>
> Do you use a special completion script?
>
> Thanks you and best regards,
> Volker
>
>> /Erik
>>
>>
>> On 2015-01-15 18:33, Volker Simonis wrote:
>>> Hi Magnus,
>>>
>>> I've only had a quick look at your changes but I have a question.
>>>
>>> When looking at the "make help" I think the relationship between
>>> "repo", "target" and "module" is a little unclear.
>>>
>>> As far as I understand a "target" is an artefact which can be named
>>> and build by "make".
>>> A "repo" is a collection of sources which is defined by our version
>>> control system.
>>> A "module" is a logical part of the resulting build output.
>>>
>>> All these three are orthogonal (i.e. a "target" can build many
>>> "modules" or just a part of a module, a "repo" can contain several
>>> modules or just the part of a module, etc.)
>>>
>>> I think that the division of the OpenJDK source into different repos
>>> is unfortunate and somehow arbitrary. So maybe we should try to avoid
>>> this term when speaking about make targets and modules.
>>>
>>> I would also wish there was a dynamically created list of buildable
>>> modules so we could do something like "make modules" to get this list.
>>> I don't know if this is easily possible, it's just an idea.
>>>
>>> Also the line "make [default]         # Compile all modules in
>>> langtools, hotspot, jdk, jaxws,.." seems a little confusing to me. It
>>> speaks about modules but lists the current repos. So what are the
>>> available moduls? What does "[default]" stands for?
>>>
>>> I like the two "clean" targets:
>>>
>>> make clean-<module>
>>> make clean-<module>-<phase>
>>>
>>> they are clear and concise (besides the fact that there's no module list).
>>>
>>> I'd wish to have the same syntax for the build targets (instead of
>>> make [default]). Something like:
>>>
>>> make <module>
>>> make <module>-<phase>
>>> make jdk-image                      Creates a jre image containing
>>> these modules (...) and docs
>>> make jre-image                       Creates a jre image containing
>>> these modules (...) and docs
>>> make images                          Creates both, the jre and the jdk
>>> image
>>>
>>> I'm aware that this mail degenerated more into a wish-list than a
>>> review :) Maybe you find it useful nevertheless.
>>>
>>> Regards,
>>> Volker
>>>
>>>
>>> On Thu, Jan 15, 2015 at 4:23 PM, Magnus Ihse Bursie
>>> <magnus.ihse.bursie at oracle.com> wrote:
>>>>    This fix is the result of preparatory work in the build-infra project.
>>>> It
>>>> includes:
>>>> * Remove duplicate detection of comm on Windows
>>>> * compare.sh enhancements and bug fixes
>>>> * Do not fail in SetupFoo macros on empty arguments
>>>> * Minor JavaCompilation enhancements
>>>> * Makefile warns for unknown control variables
>>>> * Improved "make help"
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8069064
>>>> WebRev:
>>>>
>>>> http://cr.openjdk.java.net/~ihse/JDK-8069064-fixes-from-build-infra/webrev.01
>>>>
>>>> /Magnus
>>



From magnus.ihse.bursie at oracle.com  Fri Jan 16 14:47:44 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 16 Jan 2015 15:47:44 +0100
Subject: RFR: JDK-8069064 Various improvements and fixes in build system
In-Reply-To: <CA+3eh11q_k=8OXgm-Q=baHzxwaRjX_n2H8g+VmYCvjdyAOTU8g@mail.gmail.com>
References: <54B7DB59.9040102@oracle.com>
	<CA+3eh11q_k=8OXgm-Q=baHzxwaRjX_n2H8g+VmYCvjdyAOTU8g@mail.gmail.com>
Message-ID: <54B92490.9020400@oracle.com>

On 2015-01-15 18:33, Volker Simonis wrote:
> I'm aware that this mail degenerated more into a wish-list than a
> review:)  Maybe you find it useful nevertheless.

It's full of good suggestions! I'll definitely try to improve the 
makefile usability based on your suggestions. But, as you say, it's a 
bit too much for this fix :)

/Magnus


From magnus.ihse.bursie at oracle.com  Fri Jan 16 15:05:52 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 16 Jan 2015 16:05:52 +0100
Subject: RFR: JDK-8069064 Various improvements and fixes in build system
In-Reply-To: <54B7DD86.50508@oracle.com>
References: <54B7DB59.9040102@oracle.com> <54B7DD86.50508@oracle.com>
Message-ID: <54B928D0.3030200@oracle.com>

On 2015-01-15 16:32, Erik Joelsson wrote:
> Looks good to me.

Thanks. It turned out that I needed to integrate this via jdk9-client 
instead of jdk9-dev, as usual, to support the upcoming build-infra work, 
and to avoid an unneccessary merge clash with the changes of Visual 
Studio 2012 in jdk9-client. That in turn means I had to drop the fixes 
to compare.sh, since they depended on the resolved merge conflicts that 
I pushed the other day to jdk9-dev (but which are not as of yet in 
jdk9-client). Phew. I'll return to the compare.sh fixes in a follow-up 
bug when everything that's relevant has been integrated everywhere. :)

/Magnus

> /Erik
>
> On 2015-01-15 16:23, Magnus Ihse Bursie wrote:
>>  This fix is the result of preparatory work in the build-infra 
>> project. It includes:
>> * Remove duplicate detection of comm on Windows
>> * compare.sh enhancements and bug fixes
>> * Do not fail in SetupFoo macros on empty arguments
>> * Minor JavaCompilation enhancements
>> * Makefile warns for unknown control variables
>> * Improved "make help"
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8069064
>> WebRev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8069064-fixes-from-build-infra/webrev.01
>>
>> /Magnus
>



From alexandr.scherbatiy at oracle.com  Fri Jan 16 15:14:59 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 16 Jan 2015 18:14:59 +0300
Subject: [9] Review Request: 8056298 Separate java.awt.datatransfer from
	the desktop module
In-Reply-To: <54B5755E.5010104@oracle.com>
References: <54B42E9C.8010905@oracle.com> <54B431A8.5020904@oracle.com>
	<54B50432.5060300@oracle.com> <54B51A5D.2090708@oracle.com>
	<54B5231C.4090809@oracle.com> <54B52623.5010700@oracle.com>
	<54B528DF.8020507@oracle.com> <54B52A47.8030501@oracle.com>
	<54B53DAD.80407@oracle.com> <54B5692C.2000507@oracle.com>
	<54B57265.3060307@oracle.com> <54B5755E.5010104@oracle.com>
Message-ID: <54B92AF3.10503@oracle.com>


   The jdk part of the fix looks good.

  Thanks,
  Alexandr.

On 1/13/2015 10:43 PM, Mandy Chung wrote:
>
> On 1/13/2015 11:30 AM, Sergey Bylokhov wrote:
>> On 13.01.2015 21:51, Alan Bateman wrote:
>>> I think this looks okay. I see Mandy's comment about dropping the 
>>> dependency on sun.security.util and that would be good to do (but 
>>> can be another patch if you want).
>> ok. The new versions:
>> http://cr.openjdk.java.net/~serb/8056298/webrev.05/jdk
>> http://cr.openjdk.java.net/~serb/8056298/webrev.05/root
>> GET_CLASSLOADER_PERMISSION was removed.
>>
>
> Looks good.  Thanks for removing that dependency.
>
> Mandy



From volker.simonis at gmail.com  Fri Jan 16 15:25:54 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 16 Jan 2015 16:25:54 +0100
Subject: RFR: JDK-8069064 Various improvements and fixes in build system
In-Reply-To: <54B92490.9020400@oracle.com>
References: <54B7DB59.9040102@oracle.com>
	<CA+3eh11q_k=8OXgm-Q=baHzxwaRjX_n2H8g+VmYCvjdyAOTU8g@mail.gmail.com>
	<54B92490.9020400@oracle.com>
Message-ID: <CA+3eh128DcRw4pHLmoFsUe7dfnXD3MUZ2U2Dtg+BTBPRS9HuAA@mail.gmail.com>

On Fri, Jan 16, 2015 at 3:47 PM, Magnus Ihse Bursie
<magnus.ihse.bursie at oracle.com> wrote:
> On 2015-01-15 18:33, Volker Simonis wrote:
>>
>> I'm aware that this mail degenerated more into a wish-list than a
>> review:)  Maybe you find it useful nevertheless.
>
>
> It's full of good suggestions! I'll definitely try to improve the makefile
> usability based on your suggestions.

Great, thanks!
And thanks for the bunch of other tips regarding autocompletion. It's
working like a charm now!

> But, as you say, it's a bit too much for this fix :)

Sure. I just thought the beginning of the year is a perfect time for
starting a wish-list:)

>
> /Magnus


From magnus.ihse.bursie at oracle.com  Fri Jan 16 19:35:32 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 16 Jan 2015 20:35:32 +0100
Subject: RFR: JDK-8068748: missing US_export_policy.jar in jdk9-b44 is
	causing compilation errors building jdk9 source code
In-Reply-To: <54B79EFE.7050202@oracle.com>
References: <54B79EFE.7050202@oracle.com>
Message-ID: <54B96804.1030101@oracle.com>

On 2015-01-15 12:05, Erik Joelsson wrote:
> Hello,
>
> Please review the open part of this patch, which changes the building 
> of policy jars to happen even if BUILD_CRYPTO is false. Previously 
> these weren't built as there were signed versions of these jars, but 
> since we no longer sign them, there is no need to not build them.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8068748
> Webrev: http://cr.openjdk.java.net/~erikj/8068748/webrev.jdk.01/
>
> The webrev diffs look a bit weird. The only thing I did was to remove 
> the "ifneq ($(BUILD_CRYPTO), no)" and adjust the indentation.
>
Looks good to me.

/Magnus



From joe.darcy at oracle.com  Sat Jan 17 00:44:03 2015
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Fri, 16 Jan 2015 16:44:03 -0800
Subject: Question on how to change javac options when building corba, jaxp,
	and jaxws repos
Message-ID: <54B9B053.1060700@oracle.com>

Hello build gurus,

As a follow-up to clearing the jdk repo of warnings, I'd like to see how 
many warnings are left in other repos.

To do this, I'd like to run the build of the other repos with

     -Xlint:all -Xmaxwarns 10000

I've poked around the build system a bit, but haven't found an effective 
way to do this for the jaxp, jaxws, and corba corba.

How can this change to accomplished?

Thanks,

-Joe


From Alan.Bateman at oracle.com  Sat Jan 17 08:42:14 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 17 Jan 2015 08:42:14 +0000
Subject: Question on how to change javac options when building corba,
	jaxp, and jaxws repos
In-Reply-To: <54B9B053.1060700@oracle.com>
References: <54B9B053.1060700@oracle.com>
Message-ID: <54BA2066.3000703@oracle.com>

On 17/01/2015 00:44, Joseph D. Darcy wrote:
> Hello build gurus,
>
> As a follow-up to clearing the jdk repo of warnings, I'd like to see 
> how many warnings are left in other repos.
>
> To do this, I'd like to run the build of the other repos with
>
>     -Xlint:all -Xmaxwarns 10000
>
> I've poked around the build system a bit, but haven't found an 
> effective way to do this for the jaxp, jaxws, and corba corba.
>
> How can this change to accomplished?
One thing to say is that the build doesn't compile by repo now. Instead 
the compilations are by module. In this case then modules that you are 
looking for are java.activiation, java.corba, jdk.rmic, java.xml, 
java.xml.bind, java.xml.ws and jdk.xml.ws.

Erik can correct me but I think the make file that you want to edit is 
<top>/make/CompileJavaModules.gmk. Comment out the lines <module>_SETUP 
:= GENERATE_JDKBYTECODE_WARNINGS to find what lies beneath.

-Alan




From jsonlee.ft at gmail.com  Sun Jan 18 03:47:26 2015
From: jsonlee.ft at gmail.com (lee json)
Date: Sun, 18 Jan 2015 11:47:26 +0800
Subject: Building open jdk 8 from source fails
In-Reply-To: <CA+3eh11xjb2wR0sOYuUhXxM9NrfsXyfZQ6DhX=Whd1CYh8ucqg@mail.gmail.com>
References: <CAG6=6-TO7FU4diVNjT5CUUvMZEbMbfhNQx1wdAwpRL-WS5sA7w@mail.gmail.com>
	<CA+3eh11xjb2wR0sOYuUhXxM9NrfsXyfZQ6DhX=Whd1CYh8ucqg@mail.gmail.com>
Message-ID: <CAG6=6-QP0UkDkCPV+wkJVf3FXwm5Eryeioth8tMw8RCANbC1Ew@mail.gmail.com>

I switch to cloning repository at
http://hg.openjdk.java.net/jdk8u/jdk8u-dev/ by command `hg clone
http://hg.openjdk.java.net/jdk8u/jdk8u-dev`

Then build with command line `bash ./configure
--with-boot-jdk=/home/jason/jdk1.7.0_6` or `bash ./configure`. And
then execute `make` or `make all` command.

The first step i.e. configure successfully completes. Its output looks
as the section configure. But failing compile source as the section of
make, when calling make/ make all. With or wihtout make clean before
make/ make all doesn't make any differences.

How to fix such errors? Thanks


== start configure ==
...
Configuration summary:
* Debug level:    release
* JDK variant:    normal
* JVM variants:   server
* OpenJDK target: OS: linux, CPU architecture: x86, address length: 32

Tools summary:
* Boot JDK:       java version "1.7.0_60" Java(TM) SE Runtime
Environment (build 1.7.0_60-b19) Java HotSpot(TM) Server VM (build
24.60-b09, mixed mode)  (at /home/jason/jdk1.7.0_60)
* C Compiler:     gcc-4.9 (Debian 4.9.1-19) version 4.9.1 (at /usr/bin/gcc-4.9)
* C++ Compiler:   g++-4.9 (Debian 4.9.1-19) version 4.9.1 (at /usr/bin/g++-4.9)

Build performance summary:
* Cores to use:   4
* Memory limit:   7998 MB
* ccache status:  installed, but disabled (version older than 3.1.4)

WARNING: The result of this configuration has overridden an older
configuration. You *should* run 'make clean' to make sure you get a
proper build. Failure to do so might result in strange build problems.
== end configure ==

== make begin result ==
Building OpenJDK for target 'all' in configuration
'linux-x86-normal-server-release'

## Starting langtools
Compiling 2 files for BUILD_TOOLS
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:310:
error: cannot find symbol
        return tk.accepts(S.token(lookahead + 1).kind);
                                                ^
  symbol:   variable kind
  location: class Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:318:
error: cannot find symbol
        return tk1.accepts(S.token(lookahead + 1).kind) &&
                                                 ^
  symbol:   variable kind
  location: class Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:319:
error: cannot find symbol
                tk2.accepts(S.token(lookahead + 2).kind);
                                                  ^
  symbol:   variable kind
  location: class Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:327:
error: cannot find symbol
        return tk1.accepts(S.token(lookahead + 1).kind) &&
                                                 ^
  symbol:   variable kind
  location: class Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:328:
error: cannot find symbol
                tk2.accepts(S.token(lookahead + 2).kind) &&
                                                  ^
  symbol:   variable kind
  location: class Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:329:
error: cannot find symbol
                tk3.accepts(S.token(lookahead + 3).kind);
                                                  ^
  symbol:   variable kind
  location: class Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:340:
error: cannot find symbol
            if (!kinds[lookahead].accepts(S.token(lookahead + 1).kind)) {
                                                                ^
  symbol:   variable kind
  location: class Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:355:
error: cannot find symbol
             switch (token.kind) {
                          ^
  symbol:   variable kind
  location: variable token of type Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:356:
error: constant string expression required
                case SEMI:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:359:
error: constant string expression required
                case PUBLIC:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:360:
error: constant string expression required
                case FINAL:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:361:
error: constant string expression required
                case ABSTRACT:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:362:
error: constant string expression required
                case MONKEYS_AT:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:363:
error: constant string expression required
                case EOF:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:364:
error: constant string expression required
                case CLASS:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:365:
error: constant string expression required
                case INTERFACE:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:366:
error: constant string expression required
                case ENUM:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:368:
error: constant string expression required
                case IMPORT:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:372:
error: constant string expression required
                case LBRACE:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:373:
error: constant string expression required
                case RBRACE:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:374:
error: constant string expression required
                case PRIVATE:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:375:
error: constant string expression required
                case PROTECTED:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:376:
error: constant string expression required
                case STATIC:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:377:
error: constant string expression required
                case TRANSIENT:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:378:
error: constant string expression required
                case NATIVE:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:379:
error: constant string expression required
                case VOLATILE:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:380:
error: reference to SYNCHRONIZED is ambiguous, both variable
SYNCHRONIZED in TokenKind and variable SYNCHRONIZED in Tag match
                case SYNCHRONIZED:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:381:
error: constant string expression required
                case STRICTFP:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:382:
error: constant string expression required
                case LT:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:383:
error: constant string expression required
                case BYTE:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:384:
error: constant string expression required
                case SHORT:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:385:
error: constant string expression required
                case CHAR:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:386:
error: constant string expression required
                case INT:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:387:
error: constant string expression required
                case LONG:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:388:
error: constant string expression required
                case FLOAT:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:389:
error: constant string expression required
                case DOUBLE:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:390:
error: constant string expression required
                case BOOLEAN:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:391:
error: constant string expression required
                case VOID:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:395:
error: constant string expression required
                case UNDERSCORE:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:396:
error: constant string expression required
                case IDENTIFIER:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:400:
error: constant string expression required
                case CASE:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:401:
error: constant string expression required
                case DEFAULT:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:402:
error: reference to IF is ambiguous, both variable IF in TokenKind and
variable IF in Tag match
                case IF:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:403:
error: constant string expression required
                case FOR:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:404:
error: constant string expression required
                case WHILE:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:405:
error: constant string expression required
                case DO:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:406:
error: reference to TRY is ambiguous, both variable TRY in TokenKind
and variable TRY in Tag match
                case TRY:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:407:
error: reference to SWITCH is ambiguous, both variable SWITCH in
TokenKind and variable SWITCH in Tag match
                case SWITCH:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:408:
error: reference to RETURN is ambiguous, both variable RETURN in
TokenKind and variable RETURN in Tag match
                case RETURN:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:409:
error: reference to THROW is ambiguous, both variable THROW in
TokenKind and variable THROW in Tag match
                case THROW:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:410:
error: reference to BREAK is ambiguous, both variable BREAK in
TokenKind and variable BREAK in Tag match
                case BREAK:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:411:
error: reference to CONTINUE is ambiguous, both variable CONTINUE in
TokenKind and variable CONTINUE in Tag match
                case CONTINUE:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:412:
error: constant string expression required
                case ELSE:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:413:
error: constant string expression required
                case FINALLY:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:414:
error: constant string expression required
                case CATCH:
                     ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:457:
error: cannot find symbol
            if (token.kind == EOF) {
                     ^
  symbol:   variable kind
  location: variable token of type Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:464:
error: cannot find symbol
        if (token.pos == errorPos)
                 ^
  symbol:   variable pos
  location: variable token of type Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:466:
error: cannot find symbol
        errorPos = token.pos;
                        ^
  symbol:   variable pos
  location: variable token of type Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:474:
error: cannot find symbol
        return syntaxError(token.pos, key);
                                ^
  symbol:   variable pos
  location: variable token of type Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:481:
error: cannot find symbol
        return syntaxError(token.pos, key, arg);
                                ^
  symbol:   variable pos
  location: variable token of type Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:488:
error: cannot find symbol
        if (token.kind == tk) {
                 ^
  symbol:   variable kind
  location: variable token of type Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:491:
error: cannot find symbol
            setErrorEndPos(token.pos);
                                ^
  symbol:   variable pos
  location: variable token of type Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:492:
error: cannot find symbol
            reportSyntaxError(S.prevToken().endPos, "expected", tk);
                                           ^
  symbol:   variable endPos
  location: class Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:510:
error: cannot find symbol
        return illegal(token.pos);
                            ^
  symbol:   variable pos
  location: variable token of type Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:517:
error: cannot find symbol
            error(token.pos, "mod.not.allowed.here",
                       ^
  symbol:   variable pos
  location: variable token of type Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:589:
error: cannot find symbol
        if (token.kind == IDENTIFIER) {
                 ^
  symbol:   variable kind
  location: variable token of type Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:590:
error: incompatible types
            Name name = token.name();
                                  ^
  required: Name
  found:    String
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:593:
error: cannot find symbol
        } else if (token.kind == ASSERT) {
                        ^
  symbol:   variable kind
  location: variable token of type Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:595:
error: cannot find symbol
                error(token.pos, "assert.as.identifier");
                           ^
  symbol:   variable pos
  location: variable token of type Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:599:
error: cannot find symbol
                warning(token.pos, "assert.as.identifier");
                             ^
  symbol:   variable pos
  location: variable token of type Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:600:
error: incompatible types
                Name name = token.name();
                                      ^
  required: Name
  found:    String
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:604:
error: cannot find symbol
        } else if (token.kind == ENUM) {
                        ^
  symbol:   variable kind
  location: variable token of type Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:606:
error: cannot find symbol
                error(token.pos, "enum.as.identifier");
                           ^
  symbol:   variable pos
  location: variable token of type Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:610:
error: cannot find symbol
                warning(token.pos, "enum.as.identifier");
                             ^
  symbol:   variable pos
  location: variable token of type Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:611:
error: incompatible types
                Name name = token.name();
                                      ^
  required: Name
  found:    String
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:615:
error: cannot find symbol
        } else if (token.kind == THIS) {
                        ^
  symbol:   variable kind
  location: variable token of type Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:619:
error: incompatible types
                Name name = token.name();
                                      ^
  required: Name
  found:    String
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:623:
error: cannot find symbol
                error(token.pos, "this.as.identifier");
                           ^
  symbol:   variable pos
  location: variable token of type Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:627:
error: cannot find symbol
        } else if (token.kind == UNDERSCORE) {
                        ^
  symbol:   variable kind
  location: variable token of type Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:628:
error: cannot find symbol
            warning(token.pos, "underscore.as.identifier");
                         ^
  symbol:   variable pos
  location: variable token of type Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:629:
error: incompatible types
            Name name = token.name();
                                  ^
  required: Name
  found:    String
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:642:
error: cannot find symbol
        JCExpression t = toP(F.at(token.pos).Ident(ident()));
                                       ^
  symbol:   variable pos
  location: variable token of type Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:643:
error: cannot find symbol
        while (token.kind == DOT) {
                    ^
  symbol:   variable kind
  location: variable token of type Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:644:
error: cannot find symbol
            int pos = token.pos;
                           ^
  symbol:   variable pos
  location: variable token of type Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:659:
error: cannot find symbol
        return literal(prefix, token.pos);
                                    ^
  symbol:   variable pos
  location: variable token of type Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:676:
error: cannot find symbol
        switch (token.kind) {
                     ^
  symbol:   variable kind
  location: variable token of type Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:677:
error: constant string expression required
        case INTLITERAL:
             ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:681:
error: cannot find symbol
                    Convert.string2int(strval(prefix), token.radix()));
                                                            ^
  symbol:   method radix()
  location: variable token of type Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:683:
error: cannot find symbol
                error(token.pos, "int.number.too.large", strval(prefix));
                           ^
  symbol:   variable pos
  location: variable token of type Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:686:
error: constant string expression required
        case LONGLITERAL:
             ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:690:
error: cannot find symbol
                    new Long(Convert.string2long(strval(prefix),
token.radix())));
                                                                      ^
  symbol:   method radix()
  location: variable token of type Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:692:
error: cannot find symbol
                error(token.pos, "int.number.too.large", strval(prefix));
                           ^
  symbol:   variable pos
  location: variable token of type Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:695:
error: constant string expression required
        case FLOATLITERAL: {
             ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:696:
error: cannot find symbol
            String proper = token.radix() == 16 ?
                                 ^
  symbol:   method radix()
  location: variable token of type Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:697:
error: cannot find symbol
                    ("0x"+ token.stringVal()) :
                                ^
  symbol:   method stringVal()
  location: variable token of type Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:698:
error: cannot find symbol
                    token.stringVal();
                         ^
  symbol:   method stringVal()
  location: variable token of type Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:707:
error: cannot find symbol
                error(token.pos, "fp.number.too.small");
                           ^
  symbol:   variable pos
  location: variable token of type Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:709:
error: cannot find symbol
                error(token.pos, "fp.number.too.large");
                           ^
  symbol:   variable pos
  location: variable token of type Token
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:714:
error: constant string expression required
        case DOUBLELITERAL: {
             ^
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:715:
error: cannot find symbol
            String proper = token.radix() == 16 ?
                                 ^
  symbol:   method radix()
  location: variable token of type Token
100 errors
make[1]: *** No rule to make target 'all', needed by 'default'.  Stop.
/home/jason/projects/jdk8u-dev//make/Main.gmk:83: recipe for target
'langtools-only' failed
make: *** [langtools-only] Error 2

== make end result ==

On 2 January 2015 at 17:34, Volker Simonis <volker.simonis at gmail.com> wrote:
> What boot-jdk did you use?
> - You could try with a different one.
>
> What is the exact configure command line?
>
> Which repository did you build from?
> - The latest jdk8 development code line is at:
> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/
>
>
> On Fri, Jan 2, 2015 at 10:24 AM, lee json <jsonlee.ft at gmail.com> wrote:
>> I following the instruction at openjdk.java.net/projects/build-infra/guide.html
>>
>> with commands `configure` and `make (all)`
>>
>> `configure` goes well, but `make` or `make all` fails with error like
>> paste.debian.net/138889/
>>
>> And there is no differences with JAVA_HOME set or unset.
>>
>> How to fix this problem?
>>
>> Environment: debian 8.0, hg 3.1, the latest changeset is
>> 941:1773f1fd0fac with date on Tue Mar 04 11:50:40 2014 -0800
>>
>> Thanks


From erik.joelsson at oracle.com  Mon Jan 19 07:30:03 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 19 Jan 2015 08:30:03 +0100
Subject: Question on how to change javac options when building corba,
	jaxp, and jaxws repos
In-Reply-To: <54BA2066.3000703@oracle.com>
References: <54B9B053.1060700@oracle.com> <54BA2066.3000703@oracle.com>
Message-ID: <54BCB27B.9010908@oracle.com>


On 2015-01-17 09:42, Alan Bateman wrote:
> On 17/01/2015 00:44, Joseph D. Darcy wrote:
>> Hello build gurus,
>>
>> As a follow-up to clearing the jdk repo of warnings, I'd like to see 
>> how many warnings are left in other repos.
>>
>> To do this, I'd like to run the build of the other repos with
>>
>>     -Xlint:all -Xmaxwarns 10000
>>
>> I've poked around the build system a bit, but haven't found an 
>> effective way to do this for the jaxp, jaxws, and corba corba.
>>
>> How can this change to accomplished?
> One thing to say is that the build doesn't compile by repo now. 
> Instead the compilations are by module. In this case then modules that 
> you are looking for are java.activiation, java.corba, jdk.rmic, 
> java.xml, java.xml.bind, java.xml.ws and jdk.xml.ws.
>
> Erik can correct me but I think the make file that you want to edit is 
> <top>/make/CompileJavaModules.gmk. Comment out the lines 
> <module>_SETUP := GENERATE_JDKBYTECODE_WARNINGS to find what lies 
> beneath.
>
That's one way of doing it, which will activate warnings per module. If 
you just want to enable for all of those modules, you can go into 
<top>/make/common/SetupJavaCompilers.gmk and change the javac parameters 
for the setup GENERATE_JDKBYTECODE_NOWARNINGS. (replace 
$(DISABLE_WARNINGS) with what you want).

It could also work to just run "make DISABLE_WARNINGS='-Xlint:all 
-Xmaxwarns 10000'". But that will also enable warnings for build tools 
java code and demos.

/Erik


From erik.joelsson at oracle.com  Mon Jan 19 08:29:57 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 19 Jan 2015 09:29:57 +0100
Subject: RFR: JDK-8067479: verify-modules fails in bootcycle build
In-Reply-To: <54B33555.8030206@oracle.com>
References: <54AFE70C.3070208@oracle.com> <54B33555.8030206@oracle.com>
Message-ID: <54BCC085.50406@oracle.com>

Hello,

Any chance someone from serviceability could take a look at this?

/Erik

On 2015-01-12 03:45, David Holmes wrote:
> Hi Erik,
>
> On 10/01/2015 12:34 AM, Erik Joelsson wrote:
>> Hello,
>>
>> Please review this patch which fixes the verify-modules target when
>> running bootcycle build, and also reenables verify-modules when running
>> "make images".
>>
>> There were two problems:
>>
>> * The bootcycle build configuration was broken so that both the normal
>> and the bootcycle build used the same HOTSPOT_DIST directory. The
>> consequence of this was that verify-modules worked when run on its own,
>> but not if bootcycle-images had been run before. This is fixed in
>> bootcycle-spec.gmk.in.
>>
>> * Since javac in JDK 9 no longer emits classes for implicitly compiled
>> sources, certain classes in sa-jdi.jar were not compiled during the
>> bootcycle build. I fixed this by adding the missing classes to sa.files.
>> Not having the classes there might have been intentional (in at least
>> some cases), but since they were compiled anyway, I felt it safer to
>> just add them to the list to fix this issue. If these classes shouldn't
>> be included, then they need to be properly removed in a followup fix.
>
> SA is owned by serviceability - cc'd. Changes seem okay as a solution 
> to immediate problem, but I don't think anyone expects the IA64 stuff 
> to still be needed. It is on the todo list to eradicate IA64 IIRC.
>
> Looks like there is limited awareness of the need to keep sa.files up 
> to date. :(
>
> Thanks,
> David
>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8067479
>> Webrev: http://cr.openjdk.java.net/~erikj/8067479/webrev.01/
>>
>> Since this is changing hotspot, I assume it will need to go in through a
>> hotspot forest. Which one?
>>
>> /Erik



From mbd at terma.com  Mon Jan 19 08:39:12 2015
From: mbd at terma.com (Mads Bondo Dydensborg)
Date: Mon, 19 Jan 2015 08:39:12 +0000
Subject: Problem with Windows build - freetype.dll: %1 is not a valid Win32
	application
Message-ID: <BCECF94448C3704799FDEB187695635BB82CD1@EXCH01.terma.com>

Hi there

As written about earlier, I have compiled OpenJDK on Windows 7 64 bit, using Visual Studio 2010 Express SP 1, under Cygwin. (eventually: make clean images). AFAIK, VS Express will only build a 32 bit image, and has done. A simple HelloWorld test seems to work. However, if I try to run anything graphical, I get a linker error regarding Freetype:

mbd at LT01666 ~/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/build/windows-x86-normal-server-release/images/j2sdk-image/demo/jfc/FileChooserDemo
$ ../../../bin/java.exe -jar FileChooserDemo.jar
jan. 19, 2015 8:39:41 AM FileChooserDemo main
SEVERE: null
java.lang.reflect.InvocationTargetException
        at java.awt.EventQueue.invokeAndWait(EventQueue.java:1300)
        at java.awt.EventQueue.invokeAndWait(EventQueue.java:1275)
        at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1348)
        at FileChooserDemo.main(FileChooserDemo.java:796)
Caused by: java.lang.UnsatisfiedLinkError: C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\build\windows-x86-normal-server-release\images\j2sdk-image\jre\bin\freetype.dll: %1 is not a valid Win32 application
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
....(lots of FontManager => ClassLoader$NativeLibrary stuff).

I am a bit new to Windows, but checking the lib in question: 

mbd at LT01666 ~/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/build/windows-x86-normal-server-release/images/j2sdk-image/jre/bin
$ file freetype.dll
freetype.dll: current ar archive

mbd at LT01666 ~/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/build/windows-x86-normal-server-release/images/j2sdk-image/jre/bin
$ ldd freetype.dll
        ntdll.dll => /cygdrive/c/windows/SysWOW64/ntdll.dll (0x77e70000)
        kernel32.dll => /cygdrive/c/windows/syswow64/kernel32.dll (0x75900000)
        KERNELBASE.dll => /cygdrive/c/windows/syswow64/KERNELBASE.dll (0x75a10000)

I am not sure if it is 32 or 64 bit, really...

As part of the build process, I had to create a copy of freetype.dll.a - this was installed in the X86 part of the Windows Program Files directory - I assumed that it was 32 bit.

Any help/hints much appreciated.

Thanks,

Mads Bondo Dydensborg



From staffan.larsen at oracle.com  Mon Jan 19 09:05:26 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 19 Jan 2015 10:05:26 +0100
Subject: RFR: JDK-8067479: verify-modules fails in bootcycle build
In-Reply-To: <54BCC085.50406@oracle.com>
References: <54AFE70C.3070208@oracle.com> <54B33555.8030206@oracle.com>
	<54BCC085.50406@oracle.com>
Message-ID: <3A3C541D-E976-44EC-A2DC-B663D0049A4F@oracle.com>

SA changes look ok - the IA64 stuff isn?t needed as we don?t support it and will remove it.

/Staffan

> On 19 jan 2015, at 09:29, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> Hello,
> 
> Any chance someone from serviceability could take a look at this?
> 
> /Erik
> 
> On 2015-01-12 03:45, David Holmes wrote:
>> Hi Erik,
>> 
>> On 10/01/2015 12:34 AM, Erik Joelsson wrote:
>>> Hello,
>>> 
>>> Please review this patch which fixes the verify-modules target when
>>> running bootcycle build, and also reenables verify-modules when running
>>> "make images".
>>> 
>>> There were two problems:
>>> 
>>> * The bootcycle build configuration was broken so that both the normal
>>> and the bootcycle build used the same HOTSPOT_DIST directory. The
>>> consequence of this was that verify-modules worked when run on its own,
>>> but not if bootcycle-images had been run before. This is fixed in
>>> bootcycle-spec.gmk.in.
>>> 
>>> * Since javac in JDK 9 no longer emits classes for implicitly compiled
>>> sources, certain classes in sa-jdi.jar were not compiled during the
>>> bootcycle build. I fixed this by adding the missing classes to sa.files.
>>> Not having the classes there might have been intentional (in at least
>>> some cases), but since they were compiled anyway, I felt it safer to
>>> just add them to the list to fix this issue. If these classes shouldn't
>>> be included, then they need to be properly removed in a followup fix.
>> 
>> SA is owned by serviceability - cc'd. Changes seem okay as a solution to immediate problem, but I don't think anyone expects the IA64 stuff to still be needed. It is on the todo list to eradicate IA64 IIRC.
>> 
>> Looks like there is limited awareness of the need to keep sa.files up to date. :(
>> 
>> Thanks,
>> David
>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8067479
>>> Webrev: http://cr.openjdk.java.net/~erikj/8067479/webrev.01/
>>> 
>>> Since this is changing hotspot, I assume it will need to go in through a
>>> hotspot forest. Which one?
>>> 
>>> /Erik
> 



From pointo1d at gmail.com  Mon Jan 19 11:00:11 2015
From: pointo1d at gmail.com (Dave Pointon)
Date: Mon, 19 Jan 2015 11:00:11 +0000
Subject: RFR (XS) 8031064: build_vm_def.sh not working correctly for new
	build cross compile
In-Reply-To: <54B8EC3F.5030408@oracle.com>
References: <54B6FA6C.40202@oracle.com> <54B75EB5.3020407@oracle.com>
	<54B760DB.70200@oracle.com> <54B765DC.8050801@oracle.com>
	<54B845E3.7060000@oracle.com> <54B8EC3F.5030408@oracle.com>
Message-ID: <CACONdhLFYadG=xNx8YRkPT8BGqwWn=0u24Lo149gKvj245c=1A@mail.gmail.com>

Hi all ,

IMO, we should be fine as long as we continue to restrict ourselves to the
use of Bourne syntax i.e. avoid wandering into the realms of the quirks
provided by bash, in both make recipes and the utility & tool scripts - I
say this only because shell shock affected  certain platforms such that
bash is not available on those platform(s) e.g. AIX.

Just my 10c FWIW ....

--
Dave Pointon FIAP MBCS -
? Contractor engaged by IBM

??

Now I saw, tho' too late, the folly of beginning a work before we count the
cost
and before we we judge rightly of our strength to go thro' with it -
Robinson Crusoe

On 16 January 2015 at 10:47, Dean Long <dean.long at oracle.com> wrote:

> On 1/15/2015 2:57 PM, Magnus Ihse Bursie wrote:
>
>> On 2015-01-15 08:01, David Holmes wrote:
>>
>>>
>>> If the build-dev guys confirm we already assume bash that is fine.
>>>
>>
>> For the rest of the world, we only use bash. For hotspot, we will use
>> bash if called from the top-level Makefile. I can't say anything about what
>> the convention have been for calling the hotspot makefiles directly, though.
>>
>> /Magnus
>>
>
> "sh" or "bash", it shouldn't matter.  Our makefiles are already using
> Bourne shell syntax,
> so if someone tries to use "make SHELL=csh", it will fail almost
> immediately.  Therefore,
> I think "NM=$(NM) sh ..." should be safe.
>
> dl
>
> https://www.gnu.org/software/make/manual/make.html#Choosing-the-Shell
>


From erik.joelsson at oracle.com  Mon Jan 19 13:33:10 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 19 Jan 2015 14:33:10 +0100
Subject: RFR: JDK-8069261: Create make dependencies on make variable values
Message-ID: <54BD0796.3080404@oracle.com>

Hello,

Please review this enhancement to the incremental build correctness. I 
have implemented a way to track make dependencies to make variable 
values, so that relevant changes to makefiles or configure will properly 
trigger rebuilds of affected targets. See bug description for more details.

Note that I've included new tests for these makefile features in the 
file test/make/TestMakeBase.gmk. These can be run with the target 
"test-make".

The macro MakeDir has been changed so that it no longer needs to be 
called with $(eval ).

I have chosen to define the new macros with = assignment instead of 
using "define", because they are meant to be called without $(eval ), 
which means they can only be one logical line. Since "define" is used to 
define multi line variables, it makes no sense to use it for these macros.

Bug: https://bugs.openjdk.java.net/browse/JDK-8069261
Webrev: http://cr.openjdk.java.net/~erikj/8069261/webrev.01/

/Erik


From pointo1d at gmail.com  Mon Jan 19 15:01:34 2015
From: pointo1d at gmail.com (Dave Pointon)
Date: Mon, 19 Jan 2015 15:01:34 +0000
Subject: Building on RHEL
Message-ID: <CACONdhJrdN9vDuTef5VqRB4uYrE-T=r1owDBbzKqYb_YFjJUCQ@mail.gmail.com>

Hi all ,

Having just taken an RHEL 6.5 update on my laptop, I'm no longe able to run
the build - I see the following error ...

Autoconf found: /usr/bin/autoconf
Generating generated-configure.sh with /usr/bin/autoconf
stdin:35: error: m4_defn: undefined macro: _m4_divert_diversion
stdin:35: the top level
autom4te: /usr/bin/m4 failed with exit status: 1

>From some Googling results, I notice that similar errors have been
encountered elsewhere (none of which are OpenJDK related) and appears to be
symptomatic of a version mis-match between autoconf and m4 - however, given
I'm running the autoconf/m4 combination of v2.63/v1.4.13, which had
previously worked, I wondered if there are any wise souls out there who
might be able to point me in the right direction for a solution WRT OpenJDK.


Many TIA ,
--
Dave Pointon FIAP MBCS

Now I saw, tho' too late, the folly of beginning a work before we count the
cost and before we we judge rightly of our strength to go thro' with it -
Robinson Crusoe


From pointo1d at gmail.com  Mon Jan 19 16:45:36 2015
From: pointo1d at gmail.com (Dave Pointon)
Date: Mon, 19 Jan 2015 16:45:36 +0000
Subject: Building on RHEL
In-Reply-To: <CACONdhJrdN9vDuTef5VqRB4uYrE-T=r1owDBbzKqYb_YFjJUCQ@mail.gmail.com>
References: <CACONdhJrdN9vDuTef5VqRB4uYrE-T=r1owDBbzKqYb_YFjJUCQ@mail.gmail.com>
Message-ID: <CACONdhKeETvj4oW5yFnYq2KD=hcx0Fxx_hWVh25SuD7v41y=VQ@mail.gmail.com>

?Hi again all ,

JIC it's of any interest, I've downloaded, built ?and subsequently used
up-levelled versions of autoconf & m4 (to 2.69 & 1.4.16) - at which point
the aforementioned problem disappears. It should be noted that no such
problem was observed on Ubuntu.

--
Dave Pointon FIAP MBCS

Now I saw, tho' too late, the folly of beginning a work before we count the
cost and before we we judge rightly of our strength to go thro' with it -
Robinson Crusoe

On 19 January 2015 at 15:01, Dave Pointon <pointo1d at gmail.com> wrote:

> Hi all ,
>
> Having just taken an RHEL 6.5 update on my laptop, I'm no longe able to
> run the build - I see the following error ...
>
> Autoconf found: /usr/bin/autoconf
> Generating generated-configure.sh with /usr/bin/autoconf
> stdin:35: error: m4_defn: undefined macro: _m4_divert_diversion
> stdin:35: the top level
> autom4te: /usr/bin/m4 failed with exit status: 1
>
> From some Googling results, I notice that similar errors have been
> encountered elsewhere (none of which are OpenJDK related) and appears to be
> symptomatic of a version mis-match between autoconf and m4 - however, given
> I'm running the autoconf/m4 combination of v2.63/v1.4.13, which had
> previously worked, I wondered if there are any wise souls out there who
> might be able to point me in the right direction for a solution WRT OpenJDK.
>
>
> Many TIA ,
> --
> Dave Pointon FIAP MBCS
>
> Now I saw, tho' too late, the folly of beginning a work before we count
> the cost and before we we judge rightly of our strength to go thro' with it
> - Robinson Crusoe
>


From david.holmes at oracle.com  Tue Jan 20 01:42:27 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 20 Jan 2015 11:42:27 +1000
Subject: Building on RHEL
In-Reply-To: <CACONdhKeETvj4oW5yFnYq2KD=hcx0Fxx_hWVh25SuD7v41y=VQ@mail.gmail.com>
References: <CACONdhJrdN9vDuTef5VqRB4uYrE-T=r1owDBbzKqYb_YFjJUCQ@mail.gmail.com>
	<CACONdhKeETvj4oW5yFnYq2KD=hcx0Fxx_hWVh25SuD7v41y=VQ@mail.gmail.com>
Message-ID: <54BDB283.6040607@oracle.com>

Hi Dave,

autoconf 2.69 is supposed to be minimal supported version for OpenJDK build.

David

On 20/01/2015 2:45 AM, Dave Pointon wrote:
> ?Hi again all ,
>
> JIC it's of any interest, I've downloaded, built ?and subsequently used
> up-levelled versions of autoconf & m4 (to 2.69 & 1.4.16) - at which point
> the aforementioned problem disappears. It should be noted that no such
> problem was observed on Ubuntu.
>
> --
> Dave Pointon FIAP MBCS
>
> Now I saw, tho' too late, the folly of beginning a work before we count the
> cost and before we we judge rightly of our strength to go thro' with it -
> Robinson Crusoe
>
> On 19 January 2015 at 15:01, Dave Pointon <pointo1d at gmail.com> wrote:
>
>> Hi all ,
>>
>> Having just taken an RHEL 6.5 update on my laptop, I'm no longe able to
>> run the build - I see the following error ...
>>
>> Autoconf found: /usr/bin/autoconf
>> Generating generated-configure.sh with /usr/bin/autoconf
>> stdin:35: error: m4_defn: undefined macro: _m4_divert_diversion
>> stdin:35: the top level
>> autom4te: /usr/bin/m4 failed with exit status: 1
>>
>>  From some Googling results, I notice that similar errors have been
>> encountered elsewhere (none of which are OpenJDK related) and appears to be
>> symptomatic of a version mis-match between autoconf and m4 - however, given
>> I'm running the autoconf/m4 combination of v2.63/v1.4.13, which had
>> previously worked, I wondered if there are any wise souls out there who
>> might be able to point me in the right direction for a solution WRT OpenJDK.
>>
>>
>> Many TIA ,
>> --
>> Dave Pointon FIAP MBCS
>>
>> Now I saw, tho' too late, the folly of beginning a work before we count
>> the cost and before we we judge rightly of our strength to go thro' with it
>> - Robinson Crusoe
>>


From mbd at terma.com  Tue Jan 20 08:01:21 2015
From: mbd at terma.com (Mads Bondo Dydensborg)
Date: Tue, 20 Jan 2015 08:01:21 +0000
Subject: FW: Windows 7: Running the tests
Message-ID: <BCECF94448C3704799FDEB187695635B0151C6FE@Exch03.terma.com>

It seems the message below did not get through - sorry if duplicates eventually arrive.

Regards

Mads
? 
From: Mads Bondo Dydensborg 
Sent: 19. januar 2015 16:21
To: 'build-dev at openjdk.java.net'
Subject: Windows 7: Running the tests

Hi all

I am trying to get to run the tests for my recent Windows 7 / 32 bit build (the one that probably has a broken Freetype inclusion).

First: Is there a Windows binary build of the jtreg tool? I have not been able to find one? (The build instructions seems daunting, and I still can not access the hg server. Broken company network/proxy/firewall I suspect).

Secondly: I managed to lift a number of jars from debian packages and fiddle enough to get the associated jtreg script running (had to change the classpath separator).

But, when I try to run the tests, it fails, stating that it can not find a file called ..:jdk_default. I added some debug statements to the jtreg script, and got the following:

(this is in ?~/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/jdk/test):

MBD: About to run jtreg:
MBD: "C:\Program Files\Java\jdk1.7.0_72/bin/java"
-Xmx512m???? -Dprogram=`basename "C:/apps/cygwin/home/mbd/opt/jtreg/usr/bin/jtreg"`???? -cp "C:\apps\cygwin\home\mbd\opt\jtreg\usr\share\java/jtreg.jar;C:\apps\cygwin\home\mbd\opt\jtreg\lib/javatest.jar;C:\apps\cygwin\home\mbd\opt\jtreg\lib/jh.jar;C:\apps\cygwin\home\mbd\opt\jtreg\lib/junit.jar"???? com.sun.javatest.regtest.Main
-agentvm
-a
-ea
-esa
-v:fail,error,time
-retain:fail,error
-ignore:quiet
-timeoutFactor:4
-r:C:/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/jdk/testoutput/jdk_default/JTreport
-w:C:/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/jdk/testoutput/jdk_default/JTwork
-jdk:C:/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/jdk
-exclude:ProblemList.txt
-vmoption:-Xmx512m
:jdk_default
Error: Cannot find file: C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\jdk\test\:jdk_default
MBD: jtreg done, exitcode 4
Missing file: C:/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/jdk/testoutput/jdk_default/JTreport/text/summary.txt
EXIT CODE: 4
EXIT CODE: 4
Makefile:303: recipe for target `jtreg_tests' failed
make[1]: *** [jtreg_tests] Error 4
make[1]: Leaving directory `/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/jdk/test'
Makefile:254: recipe for target `jdk_default' failed
make: *** [jdk_default] Error 2

It seems like it wants to concat CWD and :jdk_default - whats up with that? 

And, also, jdk_default should/could be the name of a group - but I can not find that group anywhere?

Could it be that my version of jtreg is too old? (4.1) 

Regards

Mads

Mads Bondo Dydensborg
Senior Software Architect
Development Programs
Defense & Security

Terma A/S
Vasek?r 12
2730 Herlev
Denmark

T +45 8743 6000
F +45 8743 6001
E mbd at terma.com 
W www.terma.com 

Follow Terma on the social media and in our Newsletter
?? ?? 
________________________________________
Attention:
This e-mail (and attachment(s), if any) - intended for the addressee(s) only - may contain confidential, copyright, or legally privileged information or material, and no one else is authorized to read, print, store, copy, forward, or otherwise use or disclose any part of its contents or attachment(s) in any form. If you have received this e-mail in error, please notify me by telephone or return e-mail, and delete this e-mail and attachment(s). Thank you.


From pointo1d at gmail.com  Tue Jan 20 11:02:47 2015
From: pointo1d at gmail.com (Dave Pointon)
Date: Tue, 20 Jan 2015 11:02:47 +0000
Subject: Building on RHEL
In-Reply-To: <54BDB283.6040607@oracle.com>
References: <CACONdhJrdN9vDuTef5VqRB4uYrE-T=r1owDBbzKqYb_YFjJUCQ@mail.gmail.com>
	<CACONdhKeETvj4oW5yFnYq2KD=hcx0Fxx_hWVh25SuD7v41y=VQ@mail.gmail.com>
	<54BDB283.6040607@oracle.com>
Message-ID: <CACONdhJAUsp_c+3OD8yst88YpUZzv8bOK=WM7XgBOZUPTDN6Qw@mail.gmail.com>

Hiya David ,

I was aware of that, but due to circumstances beyond our control, the use
of down-level autotools is (currently) enforced - but at least I now have a
handle on at least one of the reasons for the minmum autoconf level - FWIW,
I did find this (
http://lists.gnu.org/archive/html/bug-gnulib/2014-01/msg00034.html) which
provides both a problem description and a posited work-around.

Many tThanx again ,?

--
Dave Pointon FIAP MBCS

Now I saw, tho' too late, the folly of beginning a work before we count the
cost and before we we judge rightly of our strength to go thro' with it -
Robinson Crusoe

On 20 January 2015 at 01:42, David Holmes <david.holmes at oracle.com> wrote:

> Hi Dave,
>
> autoconf 2.69 is supposed to be minimal supported version for OpenJDK
> build.
>
> David
>
>
> On 20/01/2015 2:45 AM, Dave Pointon wrote:
>
>> ?Hi again all ,
>>
>> JIC it's of any interest, I've downloaded, built ?and subsequently used
>> up-levelled versions of autoconf & m4 (to 2.69 & 1.4.16) - at which point
>> the aforementioned problem disappears. It should be noted that no such
>> problem was observed on Ubuntu.
>>
>> --
>> Dave Pointon FIAP MBCS
>>
>> Now I saw, tho' too late, the folly of beginning a work before we count
>> the
>> cost and before we we judge rightly of our strength to go thro' with it -
>> Robinson Crusoe
>>
>> On 19 January 2015 at 15:01, Dave Pointon <pointo1d at gmail.com> wrote:
>>
>>  Hi all ,
>>>
>>> Having just taken an RHEL 6.5 update on my laptop, I'm no longe able to
>>> run the build - I see the following error ...
>>>
>>> Autoconf found: /usr/bin/autoconf
>>> Generating generated-configure.sh with /usr/bin/autoconf
>>> stdin:35: error: m4_defn: undefined macro: _m4_divert_diversion
>>> stdin:35: the top level
>>> autom4te: /usr/bin/m4 failed with exit status: 1
>>>
>>>  From some Googling results, I notice that similar errors have been
>>> encountered elsewhere (none of which are OpenJDK related) and appears to
>>> be
>>> symptomatic of a version mis-match between autoconf and m4 - however,
>>> given
>>> I'm running the autoconf/m4 combination of v2.63/v1.4.13, which had
>>> previously worked, I wondered if there are any wise souls out there who
>>> might be able to point me in the right direction for a solution WRT
>>> OpenJDK.
>>>
>>>
>>> Many TIA ,
>>> --
>>> Dave Pointon FIAP MBCS
>>>
>>> Now I saw, tho' too late, the folly of beginning a work before we count
>>> the cost and before we we judge rightly of our strength to go thro' with
>>> it
>>> - Robinson Crusoe
>>>
>>>


From Roger.Riggs at Oracle.com  Tue Jan 20 14:35:10 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 20 Jan 2015 09:35:10 -0500
Subject: FW: Windows 7: Running the tests
In-Reply-To: <BCECF94448C3704799FDEB187695635B0151C6FE@Exch03.terma.com>
References: <BCECF94448C3704799FDEB187695635B0151C6FE@Exch03.terma.com>
Message-ID: <54BE679E.4060904@Oracle.com>

Hi Mads,

The test groups are defined in the TEST.groups files at the top 
level/test in each repository.
The jtreg -dir parameter is the top of a test directory hierarchy.
Omitting the argument to jtreg will run all the tests.

There is a group :jdk_core that may be a starting point.

Roger


On 1/20/2015 3:01 AM, Mads Bondo Dydensborg wrote:
> It seems the message below did not get through - sorry if duplicates eventually arrive.
>
> Regards
>
> Mads
>    
> From: Mads Bondo Dydensborg
> Sent: 19. januar 2015 16:21
> To: 'build-dev at openjdk.java.net'
> Subject: Windows 7: Running the tests
>
> Hi all
>
> I am trying to get to run the tests for my recent Windows 7 / 32 bit build (the one that probably has a broken Freetype inclusion).
>
> First: Is there a Windows binary build of the jtreg tool? I have not been able to find one? (The build instructions seems daunting, and I still can not access the hg server. Broken company network/proxy/firewall I suspect).
>
> Secondly: I managed to lift a number of jars from debian packages and fiddle enough to get the associated jtreg script running (had to change the classpath separator).
>
> But, when I try to run the tests, it fails, stating that it can not find a file called ..:jdk_default. I added some debug statements to the jtreg script, and got the following:
>
> (this is in  ~/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/jdk/test):
>
> MBD: About to run jtreg:
> MBD: "C:\Program Files\Java\jdk1.7.0_72/bin/java"
> -Xmx512m     -Dprogram=`basename "C:/apps/cygwin/home/mbd/opt/jtreg/usr/bin/jtreg"`     -cp "C:\apps\cygwin\home\mbd\opt\jtreg\usr\share\java/jtreg.jar;C:\apps\cygwin\home\mbd\opt\jtreg\lib/javatest.jar;C:\apps\cygwin\home\mbd\opt\jtreg\lib/jh.jar;C:\apps\cygwin\home\mbd\opt\jtreg\lib/junit.jar"     com.sun.javatest.regtest.Main
> -agentvm
> -a
> -ea
> -esa
> -v:fail,error,time
> -retain:fail,error
> -ignore:quiet
> -timeoutFactor:4
> -r:C:/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/jdk/testoutput/jdk_default/JTreport
> -w:C:/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/jdk/testoutput/jdk_default/JTwork
> -jdk:C:/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/jdk
> -exclude:ProblemList.txt
> -vmoption:-Xmx512m
> :jdk_default
> Error: Cannot find file: C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\jdk\test\:jdk_default
> MBD: jtreg done, exitcode 4
> Missing file: C:/apps/cygwin/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/jdk/testoutput/jdk_default/JTreport/text/summary.txt
> EXIT CODE: 4
> EXIT CODE: 4
> Makefile:303: recipe for target `jtreg_tests' failed
> make[1]: *** [jtreg_tests] Error 4
> make[1]: Leaving directory `/home/mbd/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/jdk/test'
> Makefile:254: recipe for target `jdk_default' failed
> make: *** [jdk_default] Error 2
>
> It seems like it wants to concat CWD and :jdk_default - whats up with that?
>
> And, also, jdk_default should/could be the name of a group - but I can not find that group anywhere?
>
> Could it be that my version of jtreg is too old? (4.1)
>
> Regards
>
> Mads
>
> Mads Bondo Dydensborg
> Senior Software Architect
> Development Programs
> Defense & Security
>
> Terma A/S
> Vasek?r 12
> 2730 Herlev
> Denmark
>
> T +45 8743 6000
> F +45 8743 6001
> E mbd at terma.com
> W www.terma.com
>
> Follow Terma on the social media and in our Newsletter
>        
> ________________________________________
> Attention:
> This e-mail (and attachment(s), if any) - intended for the addressee(s) only - may contain confidential, copyright, or legally privileged information or material, and no one else is authorized to read, print, store, copy, forward, or otherwise use or disclose any part of its contents or attachment(s) in any form. If you have received this e-mail in error, please notify me by telephone or return e-mail, and delete this e-mail and attachment(s). Thank you.



From mark.reinhold at oracle.com  Tue Jan 20 17:32:42 2015
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 20 Jan 2015 09:32:42 -0800
Subject: jdk7u Maintainership
In-Reply-To: <54BE8FC2.4050004@oracle.com>
References: <54BE33CE.3040401@redhat.com>, <54BE812A.7090601@oracle.com>,
	<54BE82BE.6030308@redhat.com>, <54BE8B24.30703@oracle.com>,
	<54BE8D4F.4090101@oracle.com>, <54BE8E0E.2040506@redhat.com>,
	<54BE8FC2.4050004@oracle.com>
Message-ID: <20150120093242.458085@eggemoggin.niobe.net>

2015/1/20 9:26 -0800, dalibor.topic at oracle.com:
> On 20.01.2015 18:19, Andrew Haley wrote:
>> Okay, so does that mean I have to petition the GB to get this done,
>> or could Kelly do this retroactively?
> 
> The nomination of a new Project Lead would have to take place sometime
> in April. I'd assume that the Build Group would have found a new Group 
> Lead at that point in time.

In fact Tim Bell was nominated and voted in as the new Lead of the
Build Group [1] after Kelly first resigned back in April 2014 [2],
but I dropped the ball (sorry) in asking the GB to ratify it.

I've now made that request [3]; we should have a result in at most
a week, or sooner if a majority of GB members vote promptly.

- Mark


[1] http://mail.openjdk.java.net/pipermail/build-dev/2014-April/012267.html
[2] http://mail.openjdk.java.net/pipermail/build-dev/2014-April/012451.html
[3] http://mail.openjdk.java.net/pipermail/gb-discuss/2015-January/000277.html


From dean.long at oracle.com  Wed Jan 21 04:59:00 2015
From: dean.long at oracle.com (Dean Long)
Date: Tue, 20 Jan 2015 20:59:00 -0800
Subject: RFR (XS) 8031064: build_vm_def.sh not working correctly for new
	build cross compile
In-Reply-To: <CACONdhLFYadG=xNx8YRkPT8BGqwWn=0u24Lo149gKvj245c=1A@mail.gmail.com>
References: <54B6FA6C.40202@oracle.com>	<54B75EB5.3020407@oracle.com>	<54B760DB.70200@oracle.com>	<54B765DC.8050801@oracle.com>	<54B845E3.7060000@oracle.com>	<54B8EC3F.5030408@oracle.com>
	<CACONdhLFYadG=xNx8YRkPT8BGqwWn=0u24Lo149gKvj245c=1A@mail.gmail.com>
Message-ID: <54BF3214.2090903@oracle.com>

Here's version 2, which does everything in vm.make and doesn't do 
anything that is shell-specific:

http://cr.openjdk.java.net/~dlong/8031064//webrev.2/

thanks,

dl


From dmitry.samersoff at oracle.com  Wed Jan 21 08:11:24 2015
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Wed, 21 Jan 2015 11:11:24 +0300
Subject: RFR (XS) 8031064: build_vm_def.sh not working correctly for new
	build cross compile
In-Reply-To: <54BF3214.2090903@oracle.com>
References: <54B6FA6C.40202@oracle.com>	<54B75EB5.3020407@oracle.com>	<54B760DB.70200@oracle.com>	<54B765DC.8050801@oracle.com>	<54B845E3.7060000@oracle.com>	<54B8EC3F.5030408@oracle.com>	<CACONdhLFYadG=xNx8YRkPT8BGqwWn=0u24Lo149gKvj245c=1A@mail.gmail.com>
	<54BF3214.2090903@oracle.com>
Message-ID: <54BF5F2C.2020203@oracle.com>

Dean,

vm.make  ll. 247

1. *.o should be  $(Obj_Files)

2.

$(NM) --defined-only *.o | sort -k3 -u |
 awk '/$(VMDEF_PAT)/{ print "\t" $$3 ";" }'

should give you the same result with less efforts

-Dmitry

On 2015-01-21 07:59, Dean Long wrote:
> Here's version 2, which does everything in vm.make and doesn't do
> anything that is shell-specific:
> 
> http://cr.openjdk.java.net/~dlong/8031064//webrev.2/
> 
> thanks,
> 
> dl


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.


From magnus.ihse.bursie at oracle.com  Wed Jan 21 14:42:29 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 21 Jan 2015 15:42:29 +0100
Subject: RFR: JDK-8069261: Create make dependencies on make variable values
In-Reply-To: <54BD0796.3080404@oracle.com>
References: <54BD0796.3080404@oracle.com>
Message-ID: <54BFBAD5.3020908@oracle.com>

On 2015-01-19 14:33, Erik Joelsson wrote:
> Hello,
>
> Please review this enhancement to the incremental build correctness. I 
> have implemented a way to track make dependencies to make variable 
> values, so that relevant changes to makefiles or configure will 
> properly trigger rebuilds of affected targets. See bug description for 
> more details.
>
> Note that I've included new tests for these makefile features in the 
> file test/make/TestMakeBase.gmk. These can be run with the target 
> "test-make".
>
> The macro MakeDir has been changed so that it no longer needs to be 
> called with $(eval ).
>
> I have chosen to define the new macros with = assignment instead of 
> using "define", because they are meant to be called without $(eval ), 
> which means they can only be one logical line. Since "define" is used 
> to define multi line variables, it makes no sense to use it for these 
> macros.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8069261
> Webrev: http://cr.openjdk.java.net/~erikj/8069261/webrev.01/

Erik,

Thanks for addressing this!

The patch looks overall good. Lots of karma for using the test framework! :)

Some minor comments.
The name standard of the new vardeps files seems a bit vague. :) I 
suggest the following:

* In JavaCompilation:
   $1_VARDEPS_FILE := $$(call DependOnVariable, $1_VARDEPS, $$(dir 
$$($1_JAR))_the.$$($1_JARNAME)_vardeps)
Use .vardeps instead

* In MakeBase:
DependOnVariableFileName = \
     $(strip $(if $(strip $2), $2, \
$(MAKESUPPORT_OUTPUTDIR)/vardeps/$(DependOnVariableDirName)/$(strip 
$1).value))
Use .vardeps instead

* Also, in Tools.gmk the additions:
     CFLAGS_windows := -nologo, \
seems to have crept in by mistake.

* In NativeCompilation, the line:
  $$($1_RES): $$($1_VERSIONINFO_RESOURCE) $$($1_RES_VARDEPS_FILE)
is mis-indented

* Perhaps you can add some comment clarifying that $1_COMPILE_VARDEPS 
contains exactly the variables that add_native_source depend on,
and that $1_COMPILE_VARDEPS_FILE is used by add_native_source?

Otherwise, it looks all very good!

/Magnus


From dean.long at oracle.com  Wed Jan 21 22:39:31 2015
From: dean.long at oracle.com (Dean Long)
Date: Wed, 21 Jan 2015 14:39:31 -0800
Subject: RFR (XS) 8031064: build_vm_def.sh not working correctly for new
	build cross compile
In-Reply-To: <54BF5F2C.2020203@oracle.com>
References: <54B6FA6C.40202@oracle.com>	<54B75EB5.3020407@oracle.com>	<54B760DB.70200@oracle.com>	<54B765DC.8050801@oracle.com>	<54B845E3.7060000@oracle.com>	<54B8EC3F.5030408@oracle.com>	<CACONdhLFYadG=xNx8YRkPT8BGqwWn=0u24Lo149gKvj245c=1A@mail.gmail.com>
	<54BF3214.2090903@oracle.com> <54BF5F2C.2020203@oracle.com>
Message-ID: <54C02AA3.6020503@oracle.com>

Thanks Dmitry.  The updated webrev is here:

     http://cr.openjdk.java.net/~dlong/8031064/webrev.3/

dl

On 1/21/2015 12:11 AM, Dmitry Samersoff wrote:
> Dean,
>
> vm.make  ll. 247
>
> 1. *.o should be  $(Obj_Files)
>
> 2.
>
> $(NM) --defined-only *.o | sort -k3 -u |
>   awk '/$(VMDEF_PAT)/{ print "\t" $$3 ";" }'
>
> should give you the same result with less efforts
>
> -Dmitry
>
> On 2015-01-21 07:59, Dean Long wrote:
>> Here's version 2, which does everything in vm.make and doesn't do
>> anything that is shell-specific:
>>
>> http://cr.openjdk.java.net/~dlong/8031064//webrev.2/
>>
>> thanks,
>>
>> dl
>



From dmitry.samersoff at oracle.com  Thu Jan 22 08:32:06 2015
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Thu, 22 Jan 2015 11:32:06 +0300
Subject: RFR (XS) 8031064: build_vm_def.sh not working correctly for new
	build cross compile
In-Reply-To: <54C02AA3.6020503@oracle.com>
References: <54B6FA6C.40202@oracle.com>	<54B75EB5.3020407@oracle.com>	<54B760DB.70200@oracle.com>	<54B765DC.8050801@oracle.com>	<54B845E3.7060000@oracle.com>	<54B8EC3F.5030408@oracle.com>	<CACONdhLFYadG=xNx8YRkPT8BGqwWn=0u24Lo149gKvj245c=1A@mail.gmail.com>
	<54BF3214.2090903@oracle.com> <54BF5F2C.2020203@oracle.com>
	<54C02AA3.6020503@oracle.com>
Message-ID: <54C0B586.3040004@oracle.com>

Dean,

Looks good for me. (not a reviewer)

Thank you for fixing it.

-Dmitry

On 2015-01-22 01:39, Dean Long wrote:
> Thanks Dmitry.  The updated webrev is here:
> 
>     http://cr.openjdk.java.net/~dlong/8031064/webrev.3/
> 
> dl
> 
> On 1/21/2015 12:11 AM, Dmitry Samersoff wrote:
>> Dean,
>>
>> vm.make  ll. 247
>>
>> 1. *.o should be  $(Obj_Files)
>>
>> 2.
>>
>> $(NM) --defined-only *.o | sort -k3 -u |
>>   awk '/$(VMDEF_PAT)/{ print "\t" $$3 ";" }'
>>
>> should give you the same result with less efforts
>>
>> -Dmitry
>>
>> On 2015-01-21 07:59, Dean Long wrote:
>>> Here's version 2, which does everything in vm.make and doesn't do
>>> anything that is shell-specific:
>>>
>>> http://cr.openjdk.java.net/~dlong/8031064//webrev.2/
>>>
>>> thanks,
>>>
>>> dl
>>
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.


From david.holmes at oracle.com  Thu Jan 22 10:19:40 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 22 Jan 2015 20:19:40 +1000
Subject: RFR (XS) 8031064: build_vm_def.sh not working correctly for new
	build cross compile
In-Reply-To: <54C02AA3.6020503@oracle.com>
References: <54B6FA6C.40202@oracle.com>	<54B75EB5.3020407@oracle.com>	<54B760DB.70200@oracle.com>	<54B765DC.8050801@oracle.com>	<54B845E3.7060000@oracle.com>	<54B8EC3F.5030408@oracle.com>	<CACONdhLFYadG=xNx8YRkPT8BGqwWn=0u24Lo149gKvj245c=1A@mail.gmail.com>	<54BF3214.2090903@oracle.com>
	<54BF5F2C.2020203@oracle.com> <54C02AA3.6020503@oracle.com>
Message-ID: <54C0CEBC.4030807@oracle.com>

On 22/01/2015 8:39 AM, Dean Long wrote:
> Thanks Dmitry.  The updated webrev is here:
>
>      http://cr.openjdk.java.net/~dlong/8031064/webrev.3/

This looks weird:

+ VMDEF_PAT  = ^_ZTV
+ VMDEF_PAT := ^gHotSpotVM|$(VMDEF_PAT)
+ VMDEF_PAT := ^UseSharedSpaces$$|$(VMDEF_PAT)
+ VMDEF_PAT := ^_ZN9Arguments17SharedArchivePathE$$|$(VMDEF_PAT)

but I can sort of see why you wanted to do it that way.

I assume you have verified the results are identical?

I would be good to see this applied uniformly across all platforms as 
well (except windows).

Thanks,
David

> dl
>
> On 1/21/2015 12:11 AM, Dmitry Samersoff wrote:
>> Dean,
>>
>> vm.make  ll. 247
>>
>> 1. *.o should be  $(Obj_Files)
>>
>> 2.
>>
>> $(NM) --defined-only *.o | sort -k3 -u |
>>   awk '/$(VMDEF_PAT)/{ print "\t" $$3 ";" }'
>>
>> should give you the same result with less efforts
>>
>> -Dmitry
>>
>> On 2015-01-21 07:59, Dean Long wrote:
>>> Here's version 2, which does everything in vm.make and doesn't do
>>> anything that is shell-specific:
>>>
>>> http://cr.openjdk.java.net/~dlong/8031064//webrev.2/
>>>
>>> thanks,
>>>
>>> dl
>>
>


From erik.joelsson at oracle.com  Thu Jan 22 14:40:08 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 22 Jan 2015 15:40:08 +0100
Subject: RFR: JDK-8071329: Stop exporting INCLUDE and LIB when building on
	windows
Message-ID: <54C10BC8.50805@oracle.com>

Hello,

Please review this patch, which makes it possible to take a compile 
command line from the make debug log on Windows, and rerun it in a 
normal cygwin environment, without the need for running vsvars*.bat first.

When building native code on windows, using Visual Studio, configure 
extracts the build environment from the setup .bat file provided by VS 
and sets 3 variables in spec.gmk: PATH, INCLUDE and LIB. These 3 
variables are also exported into the environment in spec.gmk, so that 
every tool run by the build will see them. While this is convenient, it 
makes the command lines used by the build unusable outside of the build, 
unless you also export these variables with the correct values.

I have removed the need for INCLUDE and LIB to be exported, by 
converting their contents into compiler and linker flags. These flags 
conceptually fit well in the recent SYSROOT_CFLAGS and SYSROOT_LDFLAGS 
variables.

The PATH variable would be nice to not have to set, and while not 
setting it seems to work most of the time, I suspect that there are 
cases when it won't work. More specifically, in certain environments, 
some dll needed by the compiler program might not be on the path without 
it. So I left it being set for now.

The new LDFLAGS requires unpack200.exe to stop being linked differently 
to all other executables. There is no reason for this discrepancy that I 
can find, it just seems like someone did a bit of a quick hack getting 
it to build long ago in the old build, and we wanted to keep it 
equivalent in build-infra.

The hotspot build still requires the variables to be exported, so they 
are still being defined in hotspot-spec.gmk.

While working on this, I stumbled on a problem when running "make 
reconfigure". The PATH variable value, since exported in make, would get 
longer and longer for each time you run reconfigure. I fixed this by 
saving the original path and resetting it before running configure from 
make.

Bug: https://bugs.openjdk.java.net/browse/JDK-8071329
Webrevs:
http://cr.openjdk.java.net/~erikj/8071329/webrev.root.01/
http://cr.openjdk.java.net/~erikj/8071329/webrev.jdk.01/

/Erik


From pointo1d at gmail.com  Thu Jan 22 16:37:47 2015
From: pointo1d at gmail.com (Dave Pointon)
Date: Thu, 22 Jan 2015 16:37:47 +0000
Subject: RFR: JDK-8071329: Stop exporting INCLUDE and LIB when building on
	windows
In-Reply-To: <54C10BC8.50805@oracle.com>
References: <54C10BC8.50805@oracle.com>
Message-ID: <CACONdhKxAuG2kxZgTs7hxFum56iF_mQwGMWp0ajCz-=0atW3+A@mail.gmail.com>

Hiya Erik ,

?FWIW, this looks not unreasonable to this ?non-reviewer.

By way of an aside, I have nearly completed a set of changes to the make
files (in our repos) that, IMO, considerably improves the readability of
makefiles in which there are calls to macros using extended argument lists
- by judicious use of alignment of the ':=' together with continuation
lines. Presumably, I'd have to raise a bug to cover such changes ?

?TIA & best rgds ,?

--
Dave Pointon FIAP MBCS

Now I saw, tho' too late, the folly of beginning a work before we count the
cost and before we we judge rightly of our strength to go thro' with it -
Robinson Crusoe

On 22 January 2015 at 14:40, Erik Joelsson <erik.joelsson at oracle.com> wrote:

> Hello,
>
> Please review this patch, which makes it possible to take a compile
> command line from the make debug log on Windows, and rerun it in a normal
> cygwin environment, without the need for running vsvars*.bat first.
>
> When building native code on windows, using Visual Studio, configure
> extracts the build environment from the setup .bat file provided by VS and
> sets 3 variables in spec.gmk: PATH, INCLUDE and LIB. These 3 variables are
> also exported into the environment in spec.gmk, so that every tool run by
> the build will see them. While this is convenient, it makes the command
> lines used by the build unusable outside of the build, unless you also
> export these variables with the correct values.
>
> I have removed the need for INCLUDE and LIB to be exported, by converting
> their contents into compiler and linker flags. These flags conceptually fit
> well in the recent SYSROOT_CFLAGS and SYSROOT_LDFLAGS variables.
>
> The PATH variable would be nice to not have to set, and while not setting
> it seems to work most of the time, I suspect that there are cases when it
> won't work. More specifically, in certain environments, some dll needed by
> the compiler program might not be on the path without it. So I left it
> being set for now.
>
> The new LDFLAGS requires unpack200.exe to stop being linked differently to
> all other executables. There is no reason for this discrepancy that I can
> find, it just seems like someone did a bit of a quick hack getting it to
> build long ago in the old build, and we wanted to keep it equivalent in
> build-infra.
>
> The hotspot build still requires the variables to be exported, so they are
> still being defined in hotspot-spec.gmk.
>
> While working on this, I stumbled on a problem when running "make
> reconfigure". The PATH variable value, since exported in make, would get
> longer and longer for each time you run reconfigure. I fixed this by saving
> the original path and resetting it before running configure from make.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8071329
> Webrevs:
> http://cr.openjdk.java.net/~erikj/8071329/webrev.root.01/
> http://cr.openjdk.java.net/~erikj/8071329/webrev.jdk.01/
>
> /Erik
>


From dean.long at oracle.com  Thu Jan 22 18:01:07 2015
From: dean.long at oracle.com (Dean Long)
Date: Thu, 22 Jan 2015 10:01:07 -0800
Subject: RFR (XS) 8031064: build_vm_def.sh not working correctly for new
	build cross compile
In-Reply-To: <54C0CEBC.4030807@oracle.com>
References: <54B6FA6C.40202@oracle.com>	<54B75EB5.3020407@oracle.com>	<54B760DB.70200@oracle.com>	<54B765DC.8050801@oracle.com>	<54B845E3.7060000@oracle.com>	<54B8EC3F.5030408@oracle.com>	<CACONdhLFYadG=xNx8YRkPT8BGqwWn=0u24Lo149gKvj245c=1A@mail.gmail.com>	<54BF3214.2090903@oracle.com>
	<54BF5F2C.2020203@oracle.com> <54C02AA3.6020503@oracle.com>
	<54C0CEBC.4030807@oracle.com>
Message-ID: <54C13AE3.1020506@oracle.com>

On 1/22/2015 2:19 AM, David Holmes wrote:
> On 22/01/2015 8:39 AM, Dean Long wrote:
>> Thanks Dmitry.  The updated webrev is here:
>>
>>      http://cr.openjdk.java.net/~dlong/8031064/webrev.3/
>
> This looks weird:
>
> + VMDEF_PAT  = ^_ZTV
> + VMDEF_PAT := ^gHotSpotVM|$(VMDEF_PAT)
> + VMDEF_PAT := ^UseSharedSpaces$$|$(VMDEF_PAT)
> + VMDEF_PAT := ^_ZN9Arguments17SharedArchivePathE$$|$(VMDEF_PAT)
>
> but I can sort of see why you wanted to do it that way.
>

Do you have a suggestion for a less-weird-looking way to do it?

> I assume you have verified the results are identical?
>

Yes.

> I would be good to see this applied uniformly across all platforms as 
> well (except windows).
>

I suppose, but isn't linux the only platform where we might be 
cross-compiling?  I'm not setup to
build for aix, bsd, or solaris, and if I build in JPRT, I'm not sure it 
will save the vm.def or mapfile to
make a comparison against.  Can we make cleaning up the other platforms 
a separate RFE?

dl

> Thanks,
> David
>
>> dl
>>
>> On 1/21/2015 12:11 AM, Dmitry Samersoff wrote:
>>> Dean,
>>>
>>> vm.make  ll. 247
>>>
>>> 1. *.o should be  $(Obj_Files)
>>>
>>> 2.
>>>
>>> $(NM) --defined-only *.o | sort -k3 -u |
>>>   awk '/$(VMDEF_PAT)/{ print "\t" $$3 ";" }'
>>>
>>> should give you the same result with less efforts
>>>
>>> -Dmitry
>>>
>>> On 2015-01-21 07:59, Dean Long wrote:
>>>> Here's version 2, which does everything in vm.make and doesn't do
>>>> anything that is shell-specific:
>>>>
>>>> http://cr.openjdk.java.net/~dlong/8031064//webrev.2/
>>>>
>>>> thanks,
>>>>
>>>> dl
>>>
>>



From anthony.scarpino at oracle.com  Fri Jan 23 00:33:51 2015
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Thu, 22 Jan 2015 16:33:51 -0800
Subject: build failure in perfMemory_solaris.cpp?
Message-ID: <54C196EF.3090504@oracle.com>

Hi,

I just pulled the jdk9/dev gate today and hit a build failure on SPARC 
Solaris 11.1 when compiling perfMemory_solaris.cpp in hotspot.  I'm 
using SS12u3 compilers.  Anyone else see a similar error or know what 
might be going wrong?

...hotspot/src/os/solaris/vm/perfMemory_solaris.cpp", line 337: Error: 
dd_fd is not a member of DIR.
...hotspot/src/os/solaris/vm/perfMemory_solaris.cpp", line 369: Error: 
dd_fd is not a member of DIR."
gmake[8]: *** [perfMemory_solaris.o] Error 2

thanks

Tony


From david.holmes at oracle.com  Fri Jan 23 04:19:45 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 23 Jan 2015 14:19:45 +1000
Subject: build failure in perfMemory_solaris.cpp?
In-Reply-To: <54C196EF.3090504@oracle.com>
References: <54C196EF.3090504@oracle.com>
Message-ID: <54C1CBE1.7070505@oracle.com>

Hi Anthony,

On 23/01/2015 10:33 AM, Anthony Scarpino wrote:
> Hi,
>
> I just pulled the jdk9/dev gate today and hit a build failure on SPARC
> Solaris 11.1 when compiling perfMemory_solaris.cpp in hotspot.  I'm
> using SS12u3 compilers.  Anyone else see a similar error or know what
> might be going wrong?
>
> ...hotspot/src/os/solaris/vm/perfMemory_solaris.cpp", line 337: Error:
> dd_fd is not a member of DIR.
> ...hotspot/src/os/solaris/vm/perfMemory_solaris.cpp", line 369: Error:
> dd_fd is not a member of DIR."
> gmake[8]: *** [perfMemory_solaris.o] Error 2

This code was brought in via the recent CPU integration of bug 8050807. 
(Hi Jerry! - cc'd)

It looks like Solaris has two potential definitions of DIR:

#if defined(__USE_LEGACY_PROTOTYPES__)
/* traditional SVR4 definition */
typedef struct {
         int     dd_fd;          /* file descriptor */
         int     dd_loc;         /* offset in block */
         int     dd_size;        /* amount of valid data */
         char    *dd_buf;        /* directory block */
} DIR;                          /* stream data from opendir() */
#else
/* default definition (POSIX conformant) */
typedef struct {
         int     d_fd;           /* file descriptor */
         int     d_loc;          /* offset in block */
         int     d_size;         /* amount of valid data */
         char    *d_buf;         /* directory block */
} DIR;                          /* stream data from opendir() */
#endif  /* __USE_LEGACY_PROTOTYPES__ */

I can't see what controls __USE_LEGACY_PROTOTYPES__ but presumably 
either something in Solaris 11.1, or something in SS12u3 is causing this 
difference.

David

> thanks
>
> Tony


From dmitry.samersoff at oracle.com  Fri Jan 23 06:45:27 2015
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Fri, 23 Jan 2015 09:45:27 +0300
Subject: RFR (XS) 8031064: build_vm_def.sh not working correctly for new
	build cross compile
In-Reply-To: <54C13AE3.1020506@oracle.com>
References: <54B6FA6C.40202@oracle.com>	<54B75EB5.3020407@oracle.com>	<54B760DB.70200@oracle.com>	<54B765DC.8050801@oracle.com>	<54B845E3.7060000@oracle.com>	<54B8EC3F.5030408@oracle.com>	<CACONdhLFYadG=xNx8YRkPT8BGqwWn=0u24Lo149gKvj245c=1A@mail.gmail.com>	<54BF3214.2090903@oracle.com>
	<54BF5F2C.2020203@oracle.com> <54C02AA3.6020503@oracle.com>
	<54C0CEBC.4030807@oracle.com> <54C13AE3.1020506@oracle.com>
Message-ID: <54C1EE07.6040308@oracle.com>

Dean,

> Can we make cleaning up the other platforms
> a separate RFE?

I think yes. So please file the RFE.

-Dmitry


On 2015-01-22 21:01, Dean Long wrote:
> On 1/22/2015 2:19 AM, David Holmes wrote:
>> On 22/01/2015 8:39 AM, Dean Long wrote:
>>> Thanks Dmitry.  The updated webrev is here:
>>>
>>>      http://cr.openjdk.java.net/~dlong/8031064/webrev.3/
>>
>> This looks weird:
>>
>> + VMDEF_PAT  = ^_ZTV
>> + VMDEF_PAT := ^gHotSpotVM|$(VMDEF_PAT)
>> + VMDEF_PAT := ^UseSharedSpaces$$|$(VMDEF_PAT)
>> + VMDEF_PAT := ^_ZN9Arguments17SharedArchivePathE$$|$(VMDEF_PAT)
>>
>> but I can sort of see why you wanted to do it that way.
>>
> 
> Do you have a suggestion for a less-weird-looking way to do it?
> 
>> I assume you have verified the results are identical?
>>
> 
> Yes.
> 
>> I would be good to see this applied uniformly across all platforms as
>> well (except windows).
>>
> 
> I suppose, but isn't linux the only platform where we might be
> cross-compiling?  I'm not setup to
> build for aix, bsd, or solaris, and if I build in JPRT, I'm not sure it
> will save the vm.def or mapfile to
> make a comparison against.  Can we make cleaning up the other platforms
> a separate RFE?
> 
> dl
> 
>> Thanks,
>> David
>>
>>> dl
>>>
>>> On 1/21/2015 12:11 AM, Dmitry Samersoff wrote:
>>>> Dean,
>>>>
>>>> vm.make  ll. 247
>>>>
>>>> 1. *.o should be  $(Obj_Files)
>>>>
>>>> 2.
>>>>
>>>> $(NM) --defined-only *.o | sort -k3 -u |
>>>>   awk '/$(VMDEF_PAT)/{ print "\t" $$3 ";" }'
>>>>
>>>> should give you the same result with less efforts
>>>>
>>>> -Dmitry
>>>>
>>>> On 2015-01-21 07:59, Dean Long wrote:
>>>>> Here's version 2, which does everything in vm.make and doesn't do
>>>>> anything that is shell-specific:
>>>>>
>>>>> http://cr.openjdk.java.net/~dlong/8031064//webrev.2/
>>>>>
>>>>> thanks,
>>>>>
>>>>> dl
>>>>
>>>
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.


From david.holmes at oracle.com  Fri Jan 23 07:01:59 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 23 Jan 2015 17:01:59 +1000
Subject: RFR (XS) 8031064: build_vm_def.sh not working correctly for new
	build cross compile
In-Reply-To: <54C13AE3.1020506@oracle.com>
References: <54B6FA6C.40202@oracle.com>	<54B75EB5.3020407@oracle.com>	<54B760DB.70200@oracle.com>	<54B765DC.8050801@oracle.com>	<54B845E3.7060000@oracle.com>	<54B8EC3F.5030408@oracle.com>	<CACONdhLFYadG=xNx8YRkPT8BGqwWn=0u24Lo149gKvj245c=1A@mail.gmail.com>	<54BF3214.2090903@oracle.com>
	<54BF5F2C.2020203@oracle.com> <54C02AA3.6020503@oracle.com>
	<54C0CEBC.4030807@oracle.com> <54C13AE3.1020506@oracle.com>
Message-ID: <54C1F1E7.80201@oracle.com>



On 23/01/2015 4:01 AM, Dean Long wrote:
> On 1/22/2015 2:19 AM, David Holmes wrote:
>> On 22/01/2015 8:39 AM, Dean Long wrote:
>>> Thanks Dmitry.  The updated webrev is here:
>>>
>>>      http://cr.openjdk.java.net/~dlong/8031064/webrev.3/
>>
>> This looks weird:
>>
>> + VMDEF_PAT  = ^_ZTV
>> + VMDEF_PAT := ^gHotSpotVM|$(VMDEF_PAT)
>> + VMDEF_PAT := ^UseSharedSpaces$$|$(VMDEF_PAT)
>> + VMDEF_PAT := ^_ZN9Arguments17SharedArchivePathE$$|$(VMDEF_PAT)
>>
>> but I can sort of see why you wanted to do it that way.
>>
>
> Do you have a suggestion for a less-weird-looking way to do it?

Only the obvious but hard to read:

VMDEF_PAT := 
^_ZN9Arguments17SharedArchivePathE$$|^UseSharedSpaces$$|^gHotSpotVM|^_ZTV

>> I assume you have verified the results are identical?
>>
>
> Yes.
>
>> I would be good to see this applied uniformly across all platforms as
>> well (except windows).
>>
>
> I suppose, but isn't linux the only platform where we might be
> cross-compiling?  I'm not setup to
> build for aix, bsd, or solaris, and if I build in JPRT, I'm not sure it
> will save the vm.def or mapfile to
> make a comparison against.  Can we make cleaning up the other platforms
> a separate RFE?

Getting rid of shell scripts from the build is a Good Thing(TM)! But yes 
we can make this a separate RFE.

Thanks,
David

>
> dl
>
>> Thanks,
>> David
>>
>>> dl
>>>
>>> On 1/21/2015 12:11 AM, Dmitry Samersoff wrote:
>>>> Dean,
>>>>
>>>> vm.make  ll. 247
>>>>
>>>> 1. *.o should be  $(Obj_Files)
>>>>
>>>> 2.
>>>>
>>>> $(NM) --defined-only *.o | sort -k3 -u |
>>>>   awk '/$(VMDEF_PAT)/{ print "\t" $$3 ";" }'
>>>>
>>>> should give you the same result with less efforts
>>>>
>>>> -Dmitry
>>>>
>>>> On 2015-01-21 07:59, Dean Long wrote:
>>>>> Here's version 2, which does everything in vm.make and doesn't do
>>>>> anything that is shell-specific:
>>>>>
>>>>> http://cr.openjdk.java.net/~dlong/8031064//webrev.2/
>>>>>
>>>>> thanks,
>>>>>
>>>>> dl
>>>>
>>>
>


From dean.long at oracle.com  Fri Jan 23 07:29:52 2015
From: dean.long at oracle.com (Dean Long)
Date: Thu, 22 Jan 2015 23:29:52 -0800
Subject: RFR (XS) 8031064: build_vm_def.sh not working correctly for new
	build cross compile
In-Reply-To: <54C1EE07.6040308@oracle.com>
References: <54B6FA6C.40202@oracle.com>	<54B75EB5.3020407@oracle.com>	<54B760DB.70200@oracle.com>	<54B765DC.8050801@oracle.com>	<54B845E3.7060000@oracle.com>	<54B8EC3F.5030408@oracle.com>	<CACONdhLFYadG=xNx8YRkPT8BGqwWn=0u24Lo149gKvj245c=1A@mail.gmail.com>	<54BF3214.2090903@oracle.com>
	<54BF5F2C.2020203@oracle.com> <54C02AA3.6020503@oracle.com>
	<54C0CEBC.4030807@oracle.com> <54C13AE3.1020506@oracle.com>
	<54C1EE07.6040308@oracle.com>
Message-ID: <54C1F870.7050701@oracle.com>

Done:  https://bugs.openjdk.java.net/browse/JDK-8071436

dl

On 1/22/2015 10:45 PM, Dmitry Samersoff wrote:
> Dean,
>
>> Can we make cleaning up the other platforms
>> a separate RFE?
> I think yes. So please file the RFE.
>
> -Dmitry
>
>
> On 2015-01-22 21:01, Dean Long wrote:
>> On 1/22/2015 2:19 AM, David Holmes wrote:
>>> On 22/01/2015 8:39 AM, Dean Long wrote:
>>>> Thanks Dmitry.  The updated webrev is here:
>>>>
>>>>       http://cr.openjdk.java.net/~dlong/8031064/webrev.3/
>>> This looks weird:
>>>
>>> + VMDEF_PAT  = ^_ZTV
>>> + VMDEF_PAT := ^gHotSpotVM|$(VMDEF_PAT)
>>> + VMDEF_PAT := ^UseSharedSpaces$$|$(VMDEF_PAT)
>>> + VMDEF_PAT := ^_ZN9Arguments17SharedArchivePathE$$|$(VMDEF_PAT)
>>>
>>> but I can sort of see why you wanted to do it that way.
>>>
>> Do you have a suggestion for a less-weird-looking way to do it?
>>
>>> I assume you have verified the results are identical?
>>>
>> Yes.
>>
>>> I would be good to see this applied uniformly across all platforms as
>>> well (except windows).
>>>
>> I suppose, but isn't linux the only platform where we might be
>> cross-compiling?  I'm not setup to
>> build for aix, bsd, or solaris, and if I build in JPRT, I'm not sure it
>> will save the vm.def or mapfile to
>> make a comparison against.  Can we make cleaning up the other platforms
>> a separate RFE?
>>
>> dl
>>
>>> Thanks,
>>> David
>>>
>>>> dl
>>>>
>>>> On 1/21/2015 12:11 AM, Dmitry Samersoff wrote:
>>>>> Dean,
>>>>>
>>>>> vm.make  ll. 247
>>>>>
>>>>> 1. *.o should be  $(Obj_Files)
>>>>>
>>>>> 2.
>>>>>
>>>>> $(NM) --defined-only *.o | sort -k3 -u |
>>>>>    awk '/$(VMDEF_PAT)/{ print "\t" $$3 ";" }'
>>>>>
>>>>> should give you the same result with less efforts
>>>>>
>>>>> -Dmitry
>>>>>
>>>>> On 2015-01-21 07:59, Dean Long wrote:
>>>>>> Here's version 2, which does everything in vm.make and doesn't do
>>>>>> anything that is shell-specific:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dlong/8031064//webrev.2/
>>>>>>
>>>>>> thanks,
>>>>>>
>>>>>> dl
>



From dean.long at oracle.com  Fri Jan 23 07:36:57 2015
From: dean.long at oracle.com (Dean Long)
Date: Thu, 22 Jan 2015 23:36:57 -0800
Subject: RFR (XS) 8031064: build_vm_def.sh not working correctly for new
	build cross compile
In-Reply-To: <54C1F1E7.80201@oracle.com>
References: <54B6FA6C.40202@oracle.com>	<54B75EB5.3020407@oracle.com>	<54B760DB.70200@oracle.com>	<54B765DC.8050801@oracle.com>	<54B845E3.7060000@oracle.com>	<54B8EC3F.5030408@oracle.com>	<CACONdhLFYadG=xNx8YRkPT8BGqwWn=0u24Lo149gKvj245c=1A@mail.gmail.com>	<54BF3214.2090903@oracle.com>
	<54BF5F2C.2020203@oracle.com> <54C02AA3.6020503@oracle.com>
	<54C0CEBC.4030807@oracle.com> <54C13AE3.1020506@oracle.com>
	<54C1F1E7.80201@oracle.com>
Message-ID: <54C1FA19.1010101@oracle.com>

On 1/22/2015 11:01 PM, David Holmes wrote:
>
>
> On 23/01/2015 4:01 AM, Dean Long wrote:
>> On 1/22/2015 2:19 AM, David Holmes wrote:
>>> On 22/01/2015 8:39 AM, Dean Long wrote:
>>>> Thanks Dmitry.  The updated webrev is here:
>>>>
>>>>      http://cr.openjdk.java.net/~dlong/8031064/webrev.3/
>>>
>>> This looks weird:
>>>
>>> + VMDEF_PAT  = ^_ZTV
>>> + VMDEF_PAT := ^gHotSpotVM|$(VMDEF_PAT)
>>> + VMDEF_PAT := ^UseSharedSpaces$$|$(VMDEF_PAT)
>>> + VMDEF_PAT := ^_ZN9Arguments17SharedArchivePathE$$|$(VMDEF_PAT)
>>>
>>> but I can sort of see why you wanted to do it that way.
>>>
>>
>> Do you have a suggestion for a less-weird-looking way to do it?
>
> Only the obvious but hard to read:
>
> VMDEF_PAT := 
> ^_ZN9Arguments17SharedArchivePathE$$|^UseSharedSpaces$$|^gHotSpotVM|^_ZTV
>

Sure, I will do that.  Can I count that as "reviewed"?  And do I need 
another Reviewer for this change, or am I good to go?

dl

>>> I assume you have verified the results are identical?
>>>
>>
>> Yes.
>>
>>> I would be good to see this applied uniformly across all platforms as
>>> well (except windows).
>>>
>>
>> I suppose, but isn't linux the only platform where we might be
>> cross-compiling?  I'm not setup to
>> build for aix, bsd, or solaris, and if I build in JPRT, I'm not sure it
>> will save the vm.def or mapfile to
>> make a comparison against.  Can we make cleaning up the other platforms
>> a separate RFE?
>
> Getting rid of shell scripts from the build is a Good Thing(TM)! But 
> yes we can make this a separate RFE.
>
> Thanks,
> David
>
>>
>> dl
>>
>>> Thanks,
>>> David
>>>
>>>> dl
>>>>
>>>> On 1/21/2015 12:11 AM, Dmitry Samersoff wrote:
>>>>> Dean,
>>>>>
>>>>> vm.make  ll. 247
>>>>>
>>>>> 1. *.o should be  $(Obj_Files)
>>>>>
>>>>> 2.
>>>>>
>>>>> $(NM) --defined-only *.o | sort -k3 -u |
>>>>>   awk '/$(VMDEF_PAT)/{ print "\t" $$3 ";" }'
>>>>>
>>>>> should give you the same result with less efforts
>>>>>
>>>>> -Dmitry
>>>>>
>>>>> On 2015-01-21 07:59, Dean Long wrote:
>>>>>> Here's version 2, which does everything in vm.make and doesn't do
>>>>>> anything that is shell-specific:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dlong/8031064//webrev.2/
>>>>>>
>>>>>> thanks,
>>>>>>
>>>>>> dl
>>>>>
>>>>
>>



From david.holmes at oracle.com  Fri Jan 23 07:41:07 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 23 Jan 2015 17:41:07 +1000
Subject: RFR (XS) 8031064: build_vm_def.sh not working correctly for new
	build cross compile
In-Reply-To: <54C1FA19.1010101@oracle.com>
References: <54B6FA6C.40202@oracle.com>	<54B75EB5.3020407@oracle.com>	<54B760DB.70200@oracle.com>	<54B765DC.8050801@oracle.com>	<54B845E3.7060000@oracle.com>	<54B8EC3F.5030408@oracle.com>	<CACONdhLFYadG=xNx8YRkPT8BGqwWn=0u24Lo149gKvj245c=1A@mail.gmail.com>	<54BF3214.2090903@oracle.com>
	<54BF5F2C.2020203@oracle.com> <54C02AA3.6020503@oracle.com>
	<54C0CEBC.4030807@oracle.com> <54C13AE3.1020506@oracle.com>
	<54C1F1E7.80201@oracle.com> <54C1FA19.1010101@oracle.com>
Message-ID: <54C1FB13.1080205@oracle.com>

On 23/01/2015 5:36 PM, Dean Long wrote:
> On 1/22/2015 11:01 PM, David Holmes wrote:
>>
>>
>> On 23/01/2015 4:01 AM, Dean Long wrote:
>>> On 1/22/2015 2:19 AM, David Holmes wrote:
>>>> On 22/01/2015 8:39 AM, Dean Long wrote:
>>>>> Thanks Dmitry.  The updated webrev is here:
>>>>>
>>>>>      http://cr.openjdk.java.net/~dlong/8031064/webrev.3/
>>>>
>>>> This looks weird:
>>>>
>>>> + VMDEF_PAT  = ^_ZTV
>>>> + VMDEF_PAT := ^gHotSpotVM|$(VMDEF_PAT)
>>>> + VMDEF_PAT := ^UseSharedSpaces$$|$(VMDEF_PAT)
>>>> + VMDEF_PAT := ^_ZN9Arguments17SharedArchivePathE$$|$(VMDEF_PAT)
>>>>
>>>> but I can sort of see why you wanted to do it that way.
>>>>
>>>
>>> Do you have a suggestion for a less-weird-looking way to do it?
>>
>> Only the obvious but hard to read:
>>
>> VMDEF_PAT :=
>> ^_ZN9Arguments17SharedArchivePathE$$|^UseSharedSpaces$$|^gHotSpotVM|^_ZTV
>>
>
> Sure, I will do that.  Can I count that as "reviewed"?  And do I need
> another Reviewer for this change, or am I good to go?

If you change it you will have to redo all your testing. Just leave 
as-is - the readability wins here. Up to you though.

Dmitry and I have reviewed this. So you have one "Reviewer" and one 
"reviewer" :)

Thanks,
David

> dl
>
>>>> I assume you have verified the results are identical?
>>>>
>>>
>>> Yes.
>>>
>>>> I would be good to see this applied uniformly across all platforms as
>>>> well (except windows).
>>>>
>>>
>>> I suppose, but isn't linux the only platform where we might be
>>> cross-compiling?  I'm not setup to
>>> build for aix, bsd, or solaris, and if I build in JPRT, I'm not sure it
>>> will save the vm.def or mapfile to
>>> make a comparison against.  Can we make cleaning up the other platforms
>>> a separate RFE?
>>
>> Getting rid of shell scripts from the build is a Good Thing(TM)! But
>> yes we can make this a separate RFE.
>>
>> Thanks,
>> David
>>
>>>
>>> dl
>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> dl
>>>>>
>>>>> On 1/21/2015 12:11 AM, Dmitry Samersoff wrote:
>>>>>> Dean,
>>>>>>
>>>>>> vm.make  ll. 247
>>>>>>
>>>>>> 1. *.o should be  $(Obj_Files)
>>>>>>
>>>>>> 2.
>>>>>>
>>>>>> $(NM) --defined-only *.o | sort -k3 -u |
>>>>>>   awk '/$(VMDEF_PAT)/{ print "\t" $$3 ";" }'
>>>>>>
>>>>>> should give you the same result with less efforts
>>>>>>
>>>>>> -Dmitry
>>>>>>
>>>>>> On 2015-01-21 07:59, Dean Long wrote:
>>>>>>> Here's version 2, which does everything in vm.make and doesn't do
>>>>>>> anything that is shell-specific:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~dlong/8031064//webrev.2/
>>>>>>>
>>>>>>> thanks,
>>>>>>>
>>>>>>> dl
>>>>>>
>>>>>
>>>
>


From dean.long at oracle.com  Fri Jan 23 08:39:22 2015
From: dean.long at oracle.com (Dean Long)
Date: Fri, 23 Jan 2015 00:39:22 -0800
Subject: RFR (XS) 8031064: build_vm_def.sh not working correctly for new
	build cross compile
In-Reply-To: <54C1FB13.1080205@oracle.com>
References: <54B6FA6C.40202@oracle.com>	<54B75EB5.3020407@oracle.com>	<54B760DB.70200@oracle.com>	<54B765DC.8050801@oracle.com>	<54B845E3.7060000@oracle.com>	<54B8EC3F.5030408@oracle.com>	<CACONdhLFYadG=xNx8YRkPT8BGqwWn=0u24Lo149gKvj245c=1A@mail.gmail.com>	<54BF3214.2090903@oracle.com>
	<54BF5F2C.2020203@oracle.com> <54C02AA3.6020503@oracle.com>
	<54C0CEBC.4030807@oracle.com> <54C13AE3.1020506@oracle.com>
	<54C1F1E7.80201@oracle.com> <54C1FA19.1010101@oracle.com>
	<54C1FB13.1080205@oracle.com>
Message-ID: <54C208BA.40905@oracle.com>

David and Dmitry, thanks for the reviews!

dl

On 1/22/2015 11:41 PM, David Holmes wrote:
> On 23/01/2015 5:36 PM, Dean Long wrote:
>> On 1/22/2015 11:01 PM, David Holmes wrote:
>>>
>>>
>>> On 23/01/2015 4:01 AM, Dean Long wrote:
>>>> On 1/22/2015 2:19 AM, David Holmes wrote:
>>>>> On 22/01/2015 8:39 AM, Dean Long wrote:
>>>>>> Thanks Dmitry.  The updated webrev is here:
>>>>>>
>>>>>>      http://cr.openjdk.java.net/~dlong/8031064/webrev.3/
>>>>>
>>>>> This looks weird:
>>>>>
>>>>> + VMDEF_PAT  = ^_ZTV
>>>>> + VMDEF_PAT := ^gHotSpotVM|$(VMDEF_PAT)
>>>>> + VMDEF_PAT := ^UseSharedSpaces$$|$(VMDEF_PAT)
>>>>> + VMDEF_PAT := ^_ZN9Arguments17SharedArchivePathE$$|$(VMDEF_PAT)
>>>>>
>>>>> but I can sort of see why you wanted to do it that way.
>>>>>
>>>>
>>>> Do you have a suggestion for a less-weird-looking way to do it?
>>>
>>> Only the obvious but hard to read:
>>>
>>> VMDEF_PAT :=
>>> ^_ZN9Arguments17SharedArchivePathE$$|^UseSharedSpaces$$|^gHotSpotVM|^_ZTV 
>>>
>>>
>>
>> Sure, I will do that.  Can I count that as "reviewed"?  And do I need
>> another Reviewer for this change, or am I good to go?
>
> If you change it you will have to redo all your testing. Just leave 
> as-is - the readability wins here. Up to you though.
>
> Dmitry and I have reviewed this. So you have one "Reviewer" and one 
> "reviewer" :)
>
> Thanks,
> David
>
>> dl
>>
>>>>> I assume you have verified the results are identical?
>>>>>
>>>>
>>>> Yes.
>>>>
>>>>> I would be good to see this applied uniformly across all platforms as
>>>>> well (except windows).
>>>>>
>>>>
>>>> I suppose, but isn't linux the only platform where we might be
>>>> cross-compiling?  I'm not setup to
>>>> build for aix, bsd, or solaris, and if I build in JPRT, I'm not 
>>>> sure it
>>>> will save the vm.def or mapfile to
>>>> make a comparison against.  Can we make cleaning up the other 
>>>> platforms
>>>> a separate RFE?
>>>
>>> Getting rid of shell scripts from the build is a Good Thing(TM)! But
>>> yes we can make this a separate RFE.
>>>
>>> Thanks,
>>> David
>>>
>>>>
>>>> dl
>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> dl
>>>>>>
>>>>>> On 1/21/2015 12:11 AM, Dmitry Samersoff wrote:
>>>>>>> Dean,
>>>>>>>
>>>>>>> vm.make  ll. 247
>>>>>>>
>>>>>>> 1. *.o should be  $(Obj_Files)
>>>>>>>
>>>>>>> 2.
>>>>>>>
>>>>>>> $(NM) --defined-only *.o | sort -k3 -u |
>>>>>>>   awk '/$(VMDEF_PAT)/{ print "\t" $$3 ";" }'
>>>>>>>
>>>>>>> should give you the same result with less efforts
>>>>>>>
>>>>>>> -Dmitry
>>>>>>>
>>>>>>> On 2015-01-21 07:59, Dean Long wrote:
>>>>>>>> Here's version 2, which does everything in vm.make and doesn't do
>>>>>>>> anything that is shell-specific:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~dlong/8031064//webrev.2/
>>>>>>>>
>>>>>>>> thanks,
>>>>>>>>
>>>>>>>> dl
>>>>>>>
>>>>>>
>>>>
>>



From erik.joelsson at oracle.com  Fri Jan 23 10:42:20 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 23 Jan 2015 11:42:20 +0100
Subject: RFR: JDK-8071329: Stop exporting INCLUDE and LIB when building
	on windows
In-Reply-To: <CACONdhKxAuG2kxZgTs7hxFum56iF_mQwGMWp0ajCz-=0atW3+A@mail.gmail.com>
References: <54C10BC8.50805@oracle.com>
	<CACONdhKxAuG2kxZgTs7hxFum56iF_mQwGMWp0ajCz-=0atW3+A@mail.gmail.com>
Message-ID: <54C2258C.3080401@oracle.com>

Hello Dave,

While readability is improved with aligned variable assignments, we have 
opted not to encourage that style of coding. See our build system code 
conventions [1], specifically:

18. Avoid padding internally in a line with spaces to try to align some 
feature into columns with surrounding lines.

With the following rationale:

17-18. A very typical use case of makefile changes is to add things 
(files, compiler directives, etc) to a list. These rules help making 
such changes easy and context free. Otherwise the developer must modify 
several lines that are unrelated to the actual change. Chances are that 
a nicely padded grid will not be updated and start deteriorating from 
the very first change.

So it would be unlikely for us to accept such a change.

[1] http://openjdk.java.net/groups/build/doc/code-conventions.html

/Erik

On 2015-01-22 17:37, Dave Pointon wrote:
> Hiya Erik ,
>
> ?FWIW, this looks not unreasonable to this ?non-reviewer.
>
> By way of an aside, I have nearly completed a set of changes to the 
> make files (in our repos) that, IMO, considerably improves the 
> readability of makefiles in which there are calls to macros using 
> extended argument lists - by judicious use of alignment of the ':=' 
> together with continuation lines. Presumably, I'd have to raise a bug 
> to cover such changes ?
>
> ?TIA & best rgds ,?
>
> --
> Dave Pointon FIAP MBCS
>
> Now I saw, tho' too late, the folly of beginning a work before we 
> count the cost and before we we judge rightly of our strength to go 
> thro' with it - Robinson Crusoe
>
> On 22 January 2015 at 14:40, Erik Joelsson <erik.joelsson at oracle.com 
> <mailto:erik.joelsson at oracle.com>> wrote:
>
>     Hello,
>
>     Please review this patch, which makes it possible to take a
>     compile command line from the make debug log on Windows, and rerun
>     it in a normal cygwin environment, without the need for running
>     vsvars*.bat first.
>
>     When building native code on windows, using Visual Studio,
>     configure extracts the build environment from the setup .bat file
>     provided by VS and sets 3 variables in spec.gmk: PATH, INCLUDE and
>     LIB. These 3 variables are also exported into the environment in
>     spec.gmk, so that every tool run by the build will see them. While
>     this is convenient, it makes the command lines used by the build
>     unusable outside of the build, unless you also export these
>     variables with the correct values.
>
>     I have removed the need for INCLUDE and LIB to be exported, by
>     converting their contents into compiler and linker flags. These
>     flags conceptually fit well in the recent SYSROOT_CFLAGS and
>     SYSROOT_LDFLAGS variables.
>
>     The PATH variable would be nice to not have to set, and while not
>     setting it seems to work most of the time, I suspect that there
>     are cases when it won't work. More specifically, in certain
>     environments, some dll needed by the compiler program might not be
>     on the path without it. So I left it being set for now.
>
>     The new LDFLAGS requires unpack200.exe to stop being linked
>     differently to all other executables. There is no reason for this
>     discrepancy that I can find, it just seems like someone did a bit
>     of a quick hack getting it to build long ago in the old build, and
>     we wanted to keep it equivalent in build-infra.
>
>     The hotspot build still requires the variables to be exported, so
>     they are still being defined in hotspot-spec.gmk.
>
>     While working on this, I stumbled on a problem when running "make
>     reconfigure". The PATH variable value, since exported in make,
>     would get longer and longer for each time you run reconfigure. I
>     fixed this by saving the original path and resetting it before
>     running configure from make.
>
>     Bug: https://bugs.openjdk.java.net/browse/JDK-8071329
>     Webrevs:
>     http://cr.openjdk.java.net/~erikj/8071329/webrev.root.01/
>     <http://cr.openjdk.java.net/%7Eerikj/8071329/webrev.root.01/>
>     http://cr.openjdk.java.net/~erikj/8071329/webrev.jdk.01/
>     <http://cr.openjdk.java.net/%7Eerikj/8071329/webrev.jdk.01/>
>
>     /Erik
>
>



From erik.joelsson at oracle.com  Fri Jan 23 11:17:41 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 23 Jan 2015 12:17:41 +0100
Subject: RFR: JDK-8069261: Create make dependencies on make variable values
In-Reply-To: <54BFBAD5.3020908@oracle.com>
References: <54BD0796.3080404@oracle.com> <54BFBAD5.3020908@oracle.com>
Message-ID: <54C22DD5.5030403@oracle.com>

Hello,

Thanks for the comments. Here is a new version:
http://cr.openjdk.java.net/~erikj/8069261/webrev.02/

In addition to fixing the concerns below, I fixed the following:

* Added test-make to the all target so that it gets tested in JPRT. It 
takes close to no time to run.

* Added 1 second sleeps in the tests when running on macosx, since the 
filesystem on mac only has 1 second resolution. (WOW!)

* Changed WriteFile to use printf instead of echo since echo on Solaris 
interprets things like '\t', which messes up comparisons.

* Reworked how DependOnVariable is used in JavaCompilation.gmk. Instead 
of just blindly adding all input variables, I moved the definitions 
closer to the recipes, like in NativeCompilation.gmk. I think this is 
generally better, but the triggering reason was that too much unneeded 
stuff got into the vardep variable value and the command line got too 
long on Windows.

* For SetupArchive, I discovered that for vardeps changes, we have to 
force a full recreation of the jar to be sure those changes are really 
picked up. I also discovered that we currently didn't rebuild a jar if 
the manifest template file was changed. (I'm happy I had test-make tests 
for SetupArchive when fixing this.)

/Erik

On 2015-01-21 15:42, Magnus Ihse Bursie wrote:
>
> Some minor comments.
> The name standard of the new vardeps files seems a bit vague. :) I 
> suggest the following:
>
> * In JavaCompilation:
>   $1_VARDEPS_FILE := $$(call DependOnVariable, $1_VARDEPS, $$(dir 
> $$($1_JAR))_the.$$($1_JARNAME)_vardeps)
> Use .vardeps instead
>
> * In MakeBase:
> DependOnVariableFileName = \
>     $(strip $(if $(strip $2), $2, \
> $(MAKESUPPORT_OUTPUTDIR)/vardeps/$(DependOnVariableDirName)/$(strip 
> $1).value))
> Use .vardeps instead
>
> * Also, in Tools.gmk the additions:
>     CFLAGS_windows := -nologo, \
> seems to have crept in by mistake.
>
> * In NativeCompilation, the line:
>  $$($1_RES): $$($1_VERSIONINFO_RESOURCE) $$($1_RES_VARDEPS_FILE)
> is mis-indented
>
> * Perhaps you can add some comment clarifying that $1_COMPILE_VARDEPS 
> contains exactly the variables that add_native_source depend on,
> and that $1_COMPILE_VARDEPS_FILE is used by add_native_source?
>
> Otherwise, it looks all very good!
>
> /Magnus



From magnus.ihse.bursie at oracle.com  Fri Jan 23 12:04:06 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 23 Jan 2015 13:04:06 +0100
Subject: RFR: JDK-8071329: Stop exporting INCLUDE and LIB when building
	on windows
In-Reply-To: <54C10BC8.50805@oracle.com>
References: <54C10BC8.50805@oracle.com>
Message-ID: <54C238B6.1000901@oracle.com>

On 2015-01-22 15:40, Erik Joelsson wrote:
> Hello,
>
> The new LDFLAGS requires unpack200.exe to stop being linked 
> differently to all other executables. There is no reason for this 
> discrepancy that I can find, it just seems like someone did a bit of a 
> quick hack getting it to build long ago in the old build, and we 
> wanted to keep it equivalent in build-infra.

I like the cleanup. Nevertheless, it would be good to check this by the 
group owning unpack200. Is it core libs?

> The hotspot build still requires the variables to be exported, so they 
> are still being defined in hotspot-spec.gmk.
>
> While working on this, I stumbled on a problem when running "make 
> reconfigure". The PATH variable value, since exported in make, would 
> get longer and longer for each time you run reconfigure. I fixed this 
> by saving the original path and resetting it before running configure 
> from make.

Apart from wanting a second opinion on the unpack200 stuff, it looks 
good to me. Nice work!

/Magnus


From erik.joelsson at oracle.com  Fri Jan 23 12:04:37 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 23 Jan 2015 13:04:37 +0100
Subject: RFR: JDK-8071329: Stop exporting INCLUDE and LIB when building
	on windows
In-Reply-To: <54C10BC8.50805@oracle.com>
References: <54C10BC8.50805@oracle.com>
Message-ID: <54C238D5.3010505@oracle.com>

Adding Kumar since he has history in the unpack200 executable and I'm 
changing how it is being linked on Windows.

In the old build, unpack200.exe was linked with cl.exe instead of 
link.exe like all other executables and libraries. Since the formatting 
of options is completely different, the same linker flags were not used. 
In this change, I'm removing this special treatment of unpack200.exe so 
that it is linked just like all other executables.

/Erik

On 2015-01-22 15:40, Erik Joelsson wrote:
> Hello,
>
> Please review this patch, which makes it possible to take a compile 
> command line from the make debug log on Windows, and rerun it in a 
> normal cygwin environment, without the need for running vsvars*.bat 
> first.
>
> When building native code on windows, using Visual Studio, configure 
> extracts the build environment from the setup .bat file provided by VS 
> and sets 3 variables in spec.gmk: PATH, INCLUDE and LIB. These 3 
> variables are also exported into the environment in spec.gmk, so that 
> every tool run by the build will see them. While this is convenient, 
> it makes the command lines used by the build unusable outside of the 
> build, unless you also export these variables with the correct values.
>
> I have removed the need for INCLUDE and LIB to be exported, by 
> converting their contents into compiler and linker flags. These flags 
> conceptually fit well in the recent SYSROOT_CFLAGS and SYSROOT_LDFLAGS 
> variables.
>
> The PATH variable would be nice to not have to set, and while not 
> setting it seems to work most of the time, I suspect that there are 
> cases when it won't work. More specifically, in certain environments, 
> some dll needed by the compiler program might not be on the path 
> without it. So I left it being set for now.
>
> The new LDFLAGS requires unpack200.exe to stop being linked 
> differently to all other executables. There is no reason for this 
> discrepancy that I can find, it just seems like someone did a bit of a 
> quick hack getting it to build long ago in the old build, and we 
> wanted to keep it equivalent in build-infra.
>
> The hotspot build still requires the variables to be exported, so they 
> are still being defined in hotspot-spec.gmk.
>
> While working on this, I stumbled on a problem when running "make 
> reconfigure". The PATH variable value, since exported in make, would 
> get longer and longer for each time you run reconfigure. I fixed this 
> by saving the original path and resetting it before running configure 
> from make.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8071329
> Webrevs:
> http://cr.openjdk.java.net/~erikj/8071329/webrev.root.01/
> http://cr.openjdk.java.net/~erikj/8071329/webrev.jdk.01/
>
> /Erik



From magnus.ihse.bursie at oracle.com  Fri Jan 23 12:10:27 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 23 Jan 2015 13:10:27 +0100
Subject: Problem with Windows build - freetype.dll: %1 is not a valid
	Win32 application
In-Reply-To: <BCECF94448C3704799FDEB187695635BB82CD1@EXCH01.terma.com>
References: <BCECF94448C3704799FDEB187695635BB82CD1@EXCH01.terma.com>
Message-ID: <54C23A33.5000103@oracle.com>

On 2015-01-19 09:39, Mads Bondo Dydensborg wrote:
> Hi there
>
> As written about earlier, I have compiled OpenJDK on Windows 7 64 bit, using Visual Studio 2010 Express SP 1, under Cygwin. (eventually: make clean images). AFAIK, VS Express will only build a 32 bit image, and has done. A simple HelloWorld test seems to work. However, if I try to run anything graphical, I get a linker error regarding Freetype:
>
> mbd at LT01666 ~/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/build/windows-x86-normal-server-release/images/j2sdk-image/demo/jfc/FileChooserDemo
> $ ../../../bin/java.exe -jar FileChooserDemo.jar
> jan. 19, 2015 8:39:41 AM FileChooserDemo main
> SEVERE: null
> java.lang.reflect.InvocationTargetException
>          at java.awt.EventQueue.invokeAndWait(EventQueue.java:1300)
>          at java.awt.EventQueue.invokeAndWait(EventQueue.java:1275)
>          at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1348)
>          at FileChooserDemo.main(FileChooserDemo.java:796)
> Caused by: java.lang.UnsatisfiedLinkError: C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\build\windows-x86-normal-server-release\images\j2sdk-image\jre\bin\freetype.dll: %1 is not a valid Win32 application
>          at java.lang.ClassLoader$NativeLibrary.load(Native Method)
> ....(lots of FontManager => ClassLoader$NativeLibrary stuff).
>
> I am a bit new to Windows, but checking the lib in question:
>
> mbd at LT01666 ~/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/build/windows-x86-normal-server-release/images/j2sdk-image/jre/bin
> $ file freetype.dll
> freetype.dll: current ar archive
>
> mbd at LT01666 ~/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/build/windows-x86-normal-server-release/images/j2sdk-image/jre/bin
> $ ldd freetype.dll
>          ntdll.dll => /cygdrive/c/windows/SysWOW64/ntdll.dll (0x77e70000)
>          kernel32.dll => /cygdrive/c/windows/syswow64/kernel32.dll (0x75900000)
>          KERNELBASE.dll => /cygdrive/c/windows/syswow64/KERNELBASE.dll (0x75a10000)
>
> I am not sure if it is 32 or 64 bit, really...
>
> As part of the build process, I had to create a copy of freetype.dll.a - this was installed in the X86 part of the Windows Program Files directory - I assumed that it was 32 bit.
>
> Any help/hints much appreciated.

Freetype on Windows has long been a frustrating source of problems.

In JDK9 there is a new configure option, --with-freetype-src, which 
helps out a lot with the problematic freetype on Windows. It just 
requires you to download the freetype source code and it will 
automatically compile a correct freetype library for use by OpenJDK.

AFAIK this patch has not been backported to JDK8, however. But if you 
can switch to JDK9 I highly recommend  it. An alternative solution might 
be to download JDK9 just to use this feature, and then point to the 
newly built freetype library using configure in JDK8.

/Magnus


From magnus.ihse.bursie at oracle.com  Fri Jan 23 12:12:19 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 23 Jan 2015 13:12:19 +0100
Subject: Building open jdk 8 from source fails
In-Reply-To: <CAG6=6-QP0UkDkCPV+wkJVf3FXwm5Eryeioth8tMw8RCANbC1Ew@mail.gmail.com>
References: <CAG6=6-TO7FU4diVNjT5CUUvMZEbMbfhNQx1wdAwpRL-WS5sA7w@mail.gmail.com>	<CA+3eh11xjb2wR0sOYuUhXxM9NrfsXyfZQ6DhX=Whd1CYh8ucqg@mail.gmail.com>
	<CAG6=6-QP0UkDkCPV+wkJVf3FXwm5Eryeioth8tMw8RCANbC1Ew@mail.gmail.com>
Message-ID: <54C23AA3.3050708@oracle.com>

On 2015-01-18 04:47, lee json wrote:
> I switch to cloning repository at
> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/ by command `hg clone
> http://hg.openjdk.java.net/jdk8u/jdk8u-dev`
>
> Then build with command line `bash ./configure
> --with-boot-jdk=/home/jason/jdk1.7.0_6` or `bash ./configure`. And
> then execute `make` or `make all` command.
>
> The first step i.e. configure successfully completes. Its output looks
> as the section configure. But failing compile source as the section of
> make, when calling make/ make all. With or wihtout make clean before
> make/ make all doesn't make any differences.
>
> How to fix such errors? Thanks

It looks like you have not gotten all source code correctly. Just 
cloning the top-level repo is not enough.

Try running "bash get_source.sh".

/Magnus



From magnus.ihse.bursie at oracle.com  Fri Jan 23 12:34:57 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 23 Jan 2015 13:34:57 +0100
Subject: RFR: JDK-8069261: Create make dependencies on make variable values
In-Reply-To: <54C22DD5.5030403@oracle.com>
References: <54BD0796.3080404@oracle.com> <54BFBAD5.3020908@oracle.com>
	<54C22DD5.5030403@oracle.com>
Message-ID: <54C23FF1.2000302@oracle.com>

On 2015-01-23 12:17, Erik Joelsson wrote:
> Hello,
>
> Thanks for the comments. Here is a new version:
> http://cr.openjdk.java.net/~erikj/8069261/webrev.02/
>
> In addition to fixing the concerns below, I fixed the following:
>
> * Added test-make to the all target so that it gets tested in JPRT. It 
> takes close to no time to run.
While I do like to see the make tests being run more frequently, I'm not 
sure I like the idea of adding them to the "all" target. I think 
building and testing should be kept as separate as possible, even if it 
matters testing the build system.

If your goal is to get it run in JPRT, why not add it to the JPRT 
bundles target instead?

> * Added 1 second sleeps in the tests when running on macosx, since the 
> filesystem on mac only has 1 second resolution. (WOW!)
>
> * Changed WriteFile to use printf instead of echo since echo on 
> Solaris interprets things like '\t', which messes up comparisons.
>
> * Reworked how DependOnVariable is used in JavaCompilation.gmk. 
> Instead of just blindly adding all input variables, I moved the 
> definitions closer to the recipes, like in NativeCompilation.gmk. I 
> think this is generally better, but the triggering reason was that too 
> much unneeded stuff got into the vardep variable value and the command 
> line got too long on Windows.
>
> * For SetupArchive, I discovered that for vardeps changes, we have to 
> force a full recreation of the jar to be sure those changes are really 
> picked up. I also discovered that we currently didn't rebuild a jar if 
> the manifest template file was changed. (I'm happy I had test-make 
> tests for SetupArchive when fixing this.)

Great! :-)

Seems like it could be a good thing to add a test that changes to the 
manifest file trigger a build? :-) (The current test seems to bundle 
manifest updating with other changes which could by themselves trigger 
the update.)

/Magnus

>
> /Erik
>
> On 2015-01-21 15:42, Magnus Ihse Bursie wrote:
>>
>> Some minor comments.
>> The name standard of the new vardeps files seems a bit vague. :) I 
>> suggest the following:
>>
>> * In JavaCompilation:
>>   $1_VARDEPS_FILE := $$(call DependOnVariable, $1_VARDEPS, $$(dir 
>> $$($1_JAR))_the.$$($1_JARNAME)_vardeps)
>> Use .vardeps instead
>>
>> * In MakeBase:
>> DependOnVariableFileName = \
>>     $(strip $(if $(strip $2), $2, \
>> $(MAKESUPPORT_OUTPUTDIR)/vardeps/$(DependOnVariableDirName)/$(strip 
>> $1).value))
>> Use .vardeps instead
>>
>> * Also, in Tools.gmk the additions:
>>     CFLAGS_windows := -nologo, \
>> seems to have crept in by mistake.
>>
>> * In NativeCompilation, the line:
>>  $$($1_RES): $$($1_VERSIONINFO_RESOURCE) $$($1_RES_VARDEPS_FILE)
>> is mis-indented
>>
>> * Perhaps you can add some comment clarifying that $1_COMPILE_VARDEPS 
>> contains exactly the variables that add_native_source depend on,
>> and that $1_COMPILE_VARDEPS_FILE is used by add_native_source?
>>
>> Otherwise, it looks all very good!
>>
>> /Magnus
>



From erik.joelsson at oracle.com  Fri Jan 23 13:35:44 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 23 Jan 2015 14:35:44 +0100
Subject: RFR: JDK-8069261: Create make dependencies on make variable values
In-Reply-To: <54C23FF1.2000302@oracle.com>
References: <54BD0796.3080404@oracle.com> <54BFBAD5.3020908@oracle.com>
	<54C22DD5.5030403@oracle.com> <54C23FF1.2000302@oracle.com>
Message-ID: <54C24E30.8070609@oracle.com>

Hello,

New webrev:

On 2015-01-23 13:34, Magnus Ihse Bursie wrote:
> On 2015-01-23 12:17, Erik Joelsson wrote:
>> * Added test-make to the all target so that it gets tested in JPRT. 
>> It takes close to no time to run.
> While I do like to see the make tests being run more frequently, I'm 
> not sure I like the idea of adding them to the "all" target. I think 
> building and testing should be kept as separate as possible, even if 
> it matters testing the build system.
>
> If your goal is to get it run in JPRT, why not add it to the JPRT 
> bundles target instead?
>
Removed it for now.
>>
>> * For SetupArchive, I discovered that for vardeps changes, we have to 
>> force a full recreation of the jar to be sure those changes are 
>> really picked up. I also discovered that we currently didn't rebuild 
>> a jar if the manifest template file was changed. (I'm happy I had 
>> test-make tests for SetupArchive when fixing this.)
>
> Great! :-)
>
> Seems like it could be a good thing to add a test that changes to the 
> manifest file trigger a build? :-) (The current test seems to bundle 
> manifest updating with other changes which could by themselves trigger 
> the update.)
>
Implemented.

/Erik


From erik.joelsson at oracle.com  Fri Jan 23 13:36:30 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 23 Jan 2015 14:36:30 +0100
Subject: RFR: JDK-8069261: Create make dependencies on make variable values
In-Reply-To: <54C24E30.8070609@oracle.com>
References: <54BD0796.3080404@oracle.com>
	<54BFBAD5.3020908@oracle.com>	<54C22DD5.5030403@oracle.com>
	<54C23FF1.2000302@oracle.com> <54C24E30.8070609@oracle.com>
Message-ID: <54C24E5E.4040406@oracle.com>

And the webrev link: http://cr.openjdk.java.net/~erikj/8069261/webrev.03/

/Erik

On 2015-01-23 14:35, Erik Joelsson wrote:
> Hello,
>
> New webrev:
>
> On 2015-01-23 13:34, Magnus Ihse Bursie wrote:
>> On 2015-01-23 12:17, Erik Joelsson wrote:
>>> * Added test-make to the all target so that it gets tested in JPRT. 
>>> It takes close to no time to run.
>> While I do like to see the make tests being run more frequently, I'm 
>> not sure I like the idea of adding them to the "all" target. I think 
>> building and testing should be kept as separate as possible, even if 
>> it matters testing the build system.
>>
>> If your goal is to get it run in JPRT, why not add it to the JPRT 
>> bundles target instead?
>>
> Removed it for now.
>>>
>>> * For SetupArchive, I discovered that for vardeps changes, we have 
>>> to force a full recreation of the jar to be sure those changes are 
>>> really picked up. I also discovered that we currently didn't rebuild 
>>> a jar if the manifest template file was changed. (I'm happy I had 
>>> test-make tests for SetupArchive when fixing this.)
>>
>> Great! :-)
>>
>> Seems like it could be a good thing to add a test that changes to the 
>> manifest file trigger a build? :-) (The current test seems to bundle 
>> manifest updating with other changes which could by themselves 
>> trigger the update.)
>>
> Implemented.
>
> /Erik



From magnus.ihse.bursie at oracle.com  Fri Jan 23 14:16:46 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 23 Jan 2015 15:16:46 +0100
Subject: RFR: JDK-8069261: Create make dependencies on make variable values
In-Reply-To: <54C24E30.8070609@oracle.com>
References: <54BD0796.3080404@oracle.com> <54BFBAD5.3020908@oracle.com>
	<54C22DD5.5030403@oracle.com> <54C23FF1.2000302@oracle.com>
	<54C24E30.8070609@oracle.com>
Message-ID: <54C257CE.1010407@oracle.com>

On 2015-01-23 14:35, Erik Joelsson wrote:
> Hello,
>
> New webrev:
>
> On 2015-01-23 13:34, Magnus Ihse Bursie wrote:
>> On 2015-01-23 12:17, Erik Joelsson wrote:
>>> * Added test-make to the all target so that it gets tested in JPRT. 
>>> It takes close to no time to run.
>> While I do like to see the make tests being run more frequently, I'm 
>> not sure I like the idea of adding them to the "all" target. I think 
>> building and testing should be kept as separate as possible, even if 
>> it matters testing the build system.
>>
>> If your goal is to get it run in JPRT, why not add it to the JPRT 
>> bundles target instead?
>>
> Removed it for now.
>>>
>>> * For SetupArchive, I discovered that for vardeps changes, we have 
>>> to force a full recreation of the jar to be sure those changes are 
>>> really picked up. I also discovered that we currently didn't rebuild 
>>> a jar if the manifest template file was changed. (I'm happy I had 
>>> test-make tests for SetupArchive when fixing this.)
>>
>> Great! :-)
>>
>> Seems like it could be a good thing to add a test that changes to the 
>> manifest file trigger a build? :-) (The current test seems to bundle 
>> manifest updating with other changes which could by themselves 
>> trigger the update.)
>>
> Implemented.

Looks good to me.

/Magnus


From erik.joelsson at oracle.com  Fri Jan 23 14:35:42 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 23 Jan 2015 15:35:42 +0100
Subject: RFR: JDK-8055190: Cleanup include and exclude of core-libs native
	libraries after source code restructure
Message-ID: <54C25C3E.4030501@oracle.com>

Hello,

Please review this build patch, cleaning up some in the native 
compilation of some core libraries. After the source code restructure 
into modules, the need for explicit exclude and include of source files 
was reduced. This patch moves some OS specific files to OS specific 
source dirs and adjusts the makefiles. It's based on Magnus' review 
comments on the source code restructure change.

Bug: https://bugs.openjdk.java.net/browse/JDK-8055190
Webrev: http://cr.openjdk.java.net/~erikj/8055190/webrev.01/

/Erik


From Alan.Bateman at oracle.com  Fri Jan 23 14:41:32 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 23 Jan 2015 14:41:32 +0000
Subject: RFR: JDK-8055190: Cleanup include and exclude of core-libs native
	libraries after source code restructure
In-Reply-To: <54C25C3E.4030501@oracle.com>
References: <54C25C3E.4030501@oracle.com>
Message-ID: <54C25D9C.2040408@oracle.com>

On 23/01/2015 14:35, Erik Joelsson wrote:
> Hello,
>
> Please review this build patch, cleaning up some in the native 
> compilation of some core libraries. After the source code restructure 
> into modules, the need for explicit exclude and include of source 
> files was reduced. This patch moves some OS specific files to OS 
> specific source dirs and adjusts the makefiles. It's based on Magnus' 
> review comments on the source code restructure change.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8055190
> Webrev: http://cr.openjdk.java.net/~erikj/8055190/webrev.01/
>
> /Erik
This looks a good clean-up and demonstrates the usefulness of the new 
source layout.

Can refs.allowed be removed? I thought we removed the JDK 8 dependency 
checker early in JDK 9 so this file shouldn't be needed.

-Alan


From erik.joelsson at oracle.com  Fri Jan 23 14:59:18 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 23 Jan 2015 15:59:18 +0100
Subject: RFR: JDK-8055190: Cleanup include and exclude of core-libs native
	libraries after source code restructure
In-Reply-To: <54C25D9C.2040408@oracle.com>
References: <54C25C3E.4030501@oracle.com> <54C25D9C.2040408@oracle.com>
Message-ID: <54C261C6.5030705@oracle.com>

On 2015-01-23 15:41, Alan Bateman wrote:
> On 23/01/2015 14:35, Erik Joelsson wrote:
>> Hello,
>>
>> Please review this build patch, cleaning up some in the native 
>> compilation of some core libraries. After the source code restructure 
>> into modules, the need for explicit exclude and include of source 
>> files was reduced. This patch moves some OS specific files to OS 
>> specific source dirs and adjusts the makefiles. It's based on Magnus' 
>> review comments on the source code restructure change.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8055190
>> Webrev: http://cr.openjdk.java.net/~erikj/8055190/webrev.01/
>>
>> /Erik
> This looks a good clean-up and demonstrates the usefulness of the new 
> source layout.
>
Thanks
> Can refs.allowed be removed? I thought we removed the JDK 8 dependency 
> checker early in JDK 9 so this file shouldn't be needed.
>
I was wondering what it was and could not find any usages. With your 
confirmation I have opted to remove it completely instead.

Updated webrev: http://cr.openjdk.java.net/~erikj/8055190/webrev.02/

/Erik


From volker.simonis at gmail.com  Fri Jan 23 16:32:38 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 23 Jan 2015 17:32:38 +0100
Subject: build failure in perfMemory_solaris.cpp?
In-Reply-To: <54C1CBE1.7070505@oracle.com>
References: <54C196EF.3090504@oracle.com>
	<54C1CBE1.7070505@oracle.com>
Message-ID: <CA+3eh1107VQELnzeP_gGjOBzFs=Hkypp5-XWtVLtEakFJrCN9w@mail.gmail.com>

Hi,

we can see the same in our nightly OpenJDK 8/9 builds
(http://cr.openjdk.java.net/~simonis/ppc-aix-port/) and would be
interested in a solution as well.

Thanks,
Volker

On Fri, Jan 23, 2015 at 5:19 AM, David Holmes <david.holmes at oracle.com> wrote:
> Hi Anthony,
>
>
> On 23/01/2015 10:33 AM, Anthony Scarpino wrote:
>>
>> Hi,
>>
>> I just pulled the jdk9/dev gate today and hit a build failure on SPARC
>> Solaris 11.1 when compiling perfMemory_solaris.cpp in hotspot.  I'm
>> using SS12u3 compilers.  Anyone else see a similar error or know what
>> might be going wrong?
>>
>> ...hotspot/src/os/solaris/vm/perfMemory_solaris.cpp", line 337: Error:
>> dd_fd is not a member of DIR.
>> ...hotspot/src/os/solaris/vm/perfMemory_solaris.cpp", line 369: Error:
>> dd_fd is not a member of DIR."
>> gmake[8]: *** [perfMemory_solaris.o] Error 2
>
>
> This code was brought in via the recent CPU integration of bug 8050807. (Hi
> Jerry! - cc'd)
>
> It looks like Solaris has two potential definitions of DIR:
>
> #if defined(__USE_LEGACY_PROTOTYPES__)
> /* traditional SVR4 definition */
> typedef struct {
>         int     dd_fd;          /* file descriptor */
>         int     dd_loc;         /* offset in block */
>         int     dd_size;        /* amount of valid data */
>         char    *dd_buf;        /* directory block */
> } DIR;                          /* stream data from opendir() */
> #else
> /* default definition (POSIX conformant) */
> typedef struct {
>         int     d_fd;           /* file descriptor */
>         int     d_loc;          /* offset in block */
>         int     d_size;         /* amount of valid data */
>         char    *d_buf;         /* directory block */
> } DIR;                          /* stream data from opendir() */
> #endif  /* __USE_LEGACY_PROTOTYPES__ */
>
> I can't see what controls __USE_LEGACY_PROTOTYPES__ but presumably either
> something in Solaris 11.1, or something in SS12u3 is causing this
> difference.
>
> David
>
>> thanks
>>
>> Tony


From bradford.wetmore at oracle.com  Fri Jan 23 18:07:48 2015
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Fri, 23 Jan 2015 10:07:48 -0800
Subject: build failure in perfMemory_solaris.cpp?
In-Reply-To: <CA+3eh1107VQELnzeP_gGjOBzFs=Hkypp5-XWtVLtEakFJrCN9w@mail.gmail.com>
References: <54C196EF.3090504@oracle.com>	<54C1CBE1.7070505@oracle.com>
	<CA+3eh1107VQELnzeP_gGjOBzFs=Hkypp5-XWtVLtEakFJrCN9w@mail.gmail.com>
Message-ID: <54C28DF4.6070902@oracle.com>

Is there a bug id yet?  I haven't seen one showing up in a quick search 
for dd_fd or perfMemory_solaris.cpp.

For the record, I'm on what I think is the required platform/compilers:

% uname -a
SunOS sca00bkv 5.11 11.1 sun4v sparc sun4v

% more /etc/release
                             Oracle Solaris 11.1 SPARC
   Copyright (c) 1983, 2013, Oracle and/or its affiliates.  All rights 
reserved.
                            Assembled 06 November 2013

% grep BUILD_CC out.txt
BUILD_CC:= /java/devtools/sparc/SUNWspro/SS12u3/bin/cc

Brad



On 1/23/2015 8:32 AM, Volker Simonis wrote:
> Hi,
>
> we can see the same in our nightly OpenJDK 8/9 builds
> (http://cr.openjdk.java.net/~simonis/ppc-aix-port/) and would be
> interested in a solution as well.
>
> Thanks,
> Volker
>
> On Fri, Jan 23, 2015 at 5:19 AM, David Holmes <david.holmes at oracle.com> wrote:
>> Hi Anthony,
>>
>>
>> On 23/01/2015 10:33 AM, Anthony Scarpino wrote:
>>>
>>> Hi,
>>>
>>> I just pulled the jdk9/dev gate today and hit a build failure on SPARC
>>> Solaris 11.1 when compiling perfMemory_solaris.cpp in hotspot.  I'm
>>> using SS12u3 compilers.  Anyone else see a similar error or know what
>>> might be going wrong?
>>>
>>> ...hotspot/src/os/solaris/vm/perfMemory_solaris.cpp", line 337: Error:
>>> dd_fd is not a member of DIR.
>>> ...hotspot/src/os/solaris/vm/perfMemory_solaris.cpp", line 369: Error:
>>> dd_fd is not a member of DIR."
>>> gmake[8]: *** [perfMemory_solaris.o] Error 2
>>
>>
>> This code was brought in via the recent CPU integration of bug 8050807. (Hi
>> Jerry! - cc'd)
>>
>> It looks like Solaris has two potential definitions of DIR:
>>
>> #if defined(__USE_LEGACY_PROTOTYPES__)
>> /* traditional SVR4 definition */
>> typedef struct {
>>          int     dd_fd;          /* file descriptor */
>>          int     dd_loc;         /* offset in block */
>>          int     dd_size;        /* amount of valid data */
>>          char    *dd_buf;        /* directory block */
>> } DIR;                          /* stream data from opendir() */
>> #else
>> /* default definition (POSIX conformant) */
>> typedef struct {
>>          int     d_fd;           /* file descriptor */
>>          int     d_loc;          /* offset in block */
>>          int     d_size;         /* amount of valid data */
>>          char    *d_buf;         /* directory block */
>> } DIR;                          /* stream data from opendir() */
>> #endif  /* __USE_LEGACY_PROTOTYPES__ */
>>
>> I can't see what controls __USE_LEGACY_PROTOTYPES__ but presumably either
>> something in Solaris 11.1, or something in SS12u3 is causing this
>> difference.
>>
>> David
>>
>>> thanks
>>>
>>> Tony


From anthony.scarpino at oracle.com  Fri Jan 23 18:26:40 2015
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Fri, 23 Jan 2015 10:26:40 -0800
Subject: build failure in perfMemory_solaris.cpp?
In-Reply-To: <54C28DF4.6070902@oracle.com>
References: <54C196EF.3090504@oracle.com>	<54C1CBE1.7070505@oracle.com>	<CA+3eh1107VQELnzeP_gGjOBzFs=Hkypp5-XWtVLtEakFJrCN9w@mail.gmail.com>
	<54C28DF4.6070902@oracle.com>
Message-ID: <54C29260.1070105@oracle.com>

I created one:

https://bugs.openjdk.java.net/browse/JDK-8071501

Tony

On 01/23/2015 10:07 AM, Bradford Wetmore wrote:
> Is there a bug id yet?  I haven't seen one showing up in a quick search
> for dd_fd or perfMemory_solaris.cpp.
>
> For the record, I'm on what I think is the required platform/compilers:
>
> % uname -a
> SunOS sca00bkv 5.11 11.1 sun4v sparc sun4v
>
> % more /etc/release
>                              Oracle Solaris 11.1 SPARC
>    Copyright (c) 1983, 2013, Oracle and/or its affiliates.  All rights
> reserved.
>                             Assembled 06 November 2013
>
> % grep BUILD_CC out.txt
> BUILD_CC:= /java/devtools/sparc/SUNWspro/SS12u3/bin/cc
>
> Brad
>
>
>
> On 1/23/2015 8:32 AM, Volker Simonis wrote:
>> Hi,
>>
>> we can see the same in our nightly OpenJDK 8/9 builds
>> (http://cr.openjdk.java.net/~simonis/ppc-aix-port/) and would be
>> interested in a solution as well.
>>
>> Thanks,
>> Volker
>>
>> On Fri, Jan 23, 2015 at 5:19 AM, David Holmes
>> <david.holmes at oracle.com> wrote:
>>> Hi Anthony,
>>>
>>>
>>> On 23/01/2015 10:33 AM, Anthony Scarpino wrote:
>>>>
>>>> Hi,
>>>>
>>>> I just pulled the jdk9/dev gate today and hit a build failure on SPARC
>>>> Solaris 11.1 when compiling perfMemory_solaris.cpp in hotspot.  I'm
>>>> using SS12u3 compilers.  Anyone else see a similar error or know what
>>>> might be going wrong?
>>>>
>>>> ...hotspot/src/os/solaris/vm/perfMemory_solaris.cpp", line 337: Error:
>>>> dd_fd is not a member of DIR.
>>>> ...hotspot/src/os/solaris/vm/perfMemory_solaris.cpp", line 369: Error:
>>>> dd_fd is not a member of DIR."
>>>> gmake[8]: *** [perfMemory_solaris.o] Error 2
>>>
>>>
>>> This code was brought in via the recent CPU integration of bug
>>> 8050807. (Hi
>>> Jerry! - cc'd)
>>>
>>> It looks like Solaris has two potential definitions of DIR:
>>>
>>> #if defined(__USE_LEGACY_PROTOTYPES__)
>>> /* traditional SVR4 definition */
>>> typedef struct {
>>>          int     dd_fd;          /* file descriptor */
>>>          int     dd_loc;         /* offset in block */
>>>          int     dd_size;        /* amount of valid data */
>>>          char    *dd_buf;        /* directory block */
>>> } DIR;                          /* stream data from opendir() */
>>> #else
>>> /* default definition (POSIX conformant) */
>>> typedef struct {
>>>          int     d_fd;           /* file descriptor */
>>>          int     d_loc;          /* offset in block */
>>>          int     d_size;         /* amount of valid data */
>>>          char    *d_buf;         /* directory block */
>>> } DIR;                          /* stream data from opendir() */
>>> #endif  /* __USE_LEGACY_PROTOTYPES__ */
>>>
>>> I can't see what controls __USE_LEGACY_PROTOTYPES__ but presumably
>>> either
>>> something in Solaris 11.1, or something in SS12u3 is causing this
>>> difference.
>>>
>>> David
>>>
>>>> thanks
>>>>
>>>> Tony



From alejandro.murillo at oracle.com  Fri Jan 23 22:07:25 2015
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Fri, 23 Jan 2015 15:07:25 -0700
Subject: build failure in perfMemory_solaris.cpp?
In-Reply-To: <54C29260.1070105@oracle.com>
References: <54C196EF.3090504@oracle.com>	<54C1CBE1.7070505@oracle.com>	<CA+3eh1107VQELnzeP_gGjOBzFs=Hkypp5-XWtVLtEakFJrCN9w@mail.gmail.com>	<54C28DF4.6070902@oracle.com>
	<54C29260.1070105@oracle.com>
Message-ID: <54C2C61D.7060900@oracle.com>


by the timing when this started to happen, I believe
this  was caused by the CPU changes integrated into jdk9/dev
on Wednesday (they didn't come through jdk9/hs).
I went to check those changesets and this looks like the prime suspect:

Changeset: c656c7540cb1
Author:    gthornbr
Date:      2014-11-17 15:51 -0500
URL:http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c656c7540cb1

8050807: Better performing performance data handling
Reviewed-by: dcubed, pnauman, ctornqvi, dholmes, mschoene
Contributed-by:gerald.thornbrugh at oracle.com

! src/os/bsd/vm/perfMemory_bsd.cpp
! src/os/linux/vm/perfMemory_linux.cpp
! src/os/solaris/vm/perfMemory_solaris.cpp
! src/share/vm/utilities/vmError.cpp


Jerry, I'm assigning the bug to you. Check it out and reassign if needed

Alejandro

On 1/23/2015 11:26 AM, Anthony Scarpino wrote:
> I created one:
>
> https://bugs.openjdk.java.net/browse/JDK-8071501
>
> Tony
>
> On 01/23/2015 10:07 AM, Bradford Wetmore wrote:
>> Is there a bug id yet?  I haven't seen one showing up in a quick search
>> for dd_fd or perfMemory_solaris.cpp.
>>
>> For the record, I'm on what I think is the required platform/compilers:
>>
>> % uname -a
>> SunOS sca00bkv 5.11 11.1 sun4v sparc sun4v
>>
>> % more /etc/release
>>                              Oracle Solaris 11.1 SPARC
>>    Copyright (c) 1983, 2013, Oracle and/or its affiliates.  All rights
>> reserved.
>>                             Assembled 06 November 2013
>>
>> % grep BUILD_CC out.txt
>> BUILD_CC:= /java/devtools/sparc/SUNWspro/SS12u3/bin/cc
>>
>> Brad
>>
>>
>>
>> On 1/23/2015 8:32 AM, Volker Simonis wrote:
>>> Hi,
>>>
>>> we can see the same in our nightly OpenJDK 8/9 builds
>>> (http://cr.openjdk.java.net/~simonis/ppc-aix-port/) and would be
>>> interested in a solution as well.
>>>
>>> Thanks,
>>> Volker
>>>
>>> On Fri, Jan 23, 2015 at 5:19 AM, David Holmes
>>> <david.holmes at oracle.com> wrote:
>>>> Hi Anthony,
>>>>
>>>>
>>>> On 23/01/2015 10:33 AM, Anthony Scarpino wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I just pulled the jdk9/dev gate today and hit a build failure on 
>>>>> SPARC
>>>>> Solaris 11.1 when compiling perfMemory_solaris.cpp in hotspot.  I'm
>>>>> using SS12u3 compilers.  Anyone else see a similar error or know what
>>>>> might be going wrong?
>>>>>
>>>>> ...hotspot/src/os/solaris/vm/perfMemory_solaris.cpp", line 337: 
>>>>> Error:
>>>>> dd_fd is not a member of DIR.
>>>>> ...hotspot/src/os/solaris/vm/perfMemory_solaris.cpp", line 369: 
>>>>> Error:
>>>>> dd_fd is not a member of DIR."
>>>>> gmake[8]: *** [perfMemory_solaris.o] Error 2
>>>>
>>>>
>>>> This code was brought in via the recent CPU integration of bug
>>>> 8050807. (Hi
>>>> Jerry! - cc'd)
>>>>
>>>> It looks like Solaris has two potential definitions of DIR:
>>>>
>>>> #if defined(__USE_LEGACY_PROTOTYPES__)
>>>> /* traditional SVR4 definition */
>>>> typedef struct {
>>>>          int     dd_fd;          /* file descriptor */
>>>>          int     dd_loc;         /* offset in block */
>>>>          int     dd_size;        /* amount of valid data */
>>>>          char    *dd_buf;        /* directory block */
>>>> } DIR;                          /* stream data from opendir() */
>>>> #else
>>>> /* default definition (POSIX conformant) */
>>>> typedef struct {
>>>>          int     d_fd;           /* file descriptor */
>>>>          int     d_loc;          /* offset in block */
>>>>          int     d_size;         /* amount of valid data */
>>>>          char    *d_buf;         /* directory block */
>>>> } DIR;                          /* stream data from opendir() */
>>>> #endif  /* __USE_LEGACY_PROTOTYPES__ */
>>>>
>>>> I can't see what controls __USE_LEGACY_PROTOTYPES__ but presumably
>>>> either
>>>> something in Solaris 11.1, or something in SS12u3 is causing this
>>>> difference.
>>>>
>>>> David
>>>>
>>>>> thanks
>>>>>
>>>>> Tony
>

-- 
Alejandro



From david.holmes at oracle.com  Sat Jan 24 00:32:18 2015
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 24 Jan 2015 10:32:18 +1000
Subject: build failure in perfMemory_solaris.cpp?
In-Reply-To: <54C2C61D.7060900@oracle.com>
References: <54C196EF.3090504@oracle.com>	<54C1CBE1.7070505@oracle.com>	<CA+3eh1107VQELnzeP_gGjOBzFs=Hkypp5-XWtVLtEakFJrCN9w@mail.gmail.com>	<54C28DF4.6070902@oracle.com>	<54C29260.1070105@oracle.com>
	<54C2C61D.7060900@oracle.com>
Message-ID: <54C2E812.7060106@oracle.com>

The Solaris problem doesn't appear when using our S10u6 devkits so 
wasn't noticed internally. It isn't clear exactly when Solaris decided 
to switch from SVR4 definition to POSIX definition. Not sure if we want 
ugly ifdefs or wait until our official compiler set encounters the problem.

Can't comment on the AIX situation.

David

On 24/01/2015 8:07 AM, Alejandro E Murillo wrote:
>
> by the timing when this started to happen, I believe
> this  was caused by the CPU changes integrated into jdk9/dev
> on Wednesday (they didn't come through jdk9/hs).
> I went to check those changesets and this looks like the prime suspect:
>
> Changeset: c656c7540cb1
> Author:    gthornbr
> Date:      2014-11-17 15:51 -0500
> URL:http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c656c7540cb1
>
> 8050807: Better performing performance data handling
> Reviewed-by: dcubed, pnauman, ctornqvi, dholmes, mschoene
> Contributed-by:gerald.thornbrugh at oracle.com
>
> ! src/os/bsd/vm/perfMemory_bsd.cpp
> ! src/os/linux/vm/perfMemory_linux.cpp
> ! src/os/solaris/vm/perfMemory_solaris.cpp
> ! src/share/vm/utilities/vmError.cpp
>
>
> Jerry, I'm assigning the bug to you. Check it out and reassign if needed
>
> Alejandro
>
> On 1/23/2015 11:26 AM, Anthony Scarpino wrote:
>> I created one:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8071501
>>
>> Tony
>>
>> On 01/23/2015 10:07 AM, Bradford Wetmore wrote:
>>> Is there a bug id yet?  I haven't seen one showing up in a quick search
>>> for dd_fd or perfMemory_solaris.cpp.
>>>
>>> For the record, I'm on what I think is the required platform/compilers:
>>>
>>> % uname -a
>>> SunOS sca00bkv 5.11 11.1 sun4v sparc sun4v
>>>
>>> % more /etc/release
>>>                              Oracle Solaris 11.1 SPARC
>>>    Copyright (c) 1983, 2013, Oracle and/or its affiliates.  All rights
>>> reserved.
>>>                             Assembled 06 November 2013
>>>
>>> % grep BUILD_CC out.txt
>>> BUILD_CC:= /java/devtools/sparc/SUNWspro/SS12u3/bin/cc
>>>
>>> Brad
>>>
>>>
>>>
>>> On 1/23/2015 8:32 AM, Volker Simonis wrote:
>>>> Hi,
>>>>
>>>> we can see the same in our nightly OpenJDK 8/9 builds
>>>> (http://cr.openjdk.java.net/~simonis/ppc-aix-port/) and would be
>>>> interested in a solution as well.
>>>>
>>>> Thanks,
>>>> Volker
>>>>
>>>> On Fri, Jan 23, 2015 at 5:19 AM, David Holmes
>>>> <david.holmes at oracle.com> wrote:
>>>>> Hi Anthony,
>>>>>
>>>>>
>>>>> On 23/01/2015 10:33 AM, Anthony Scarpino wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I just pulled the jdk9/dev gate today and hit a build failure on
>>>>>> SPARC
>>>>>> Solaris 11.1 when compiling perfMemory_solaris.cpp in hotspot.  I'm
>>>>>> using SS12u3 compilers.  Anyone else see a similar error or know what
>>>>>> might be going wrong?
>>>>>>
>>>>>> ...hotspot/src/os/solaris/vm/perfMemory_solaris.cpp", line 337:
>>>>>> Error:
>>>>>> dd_fd is not a member of DIR.
>>>>>> ...hotspot/src/os/solaris/vm/perfMemory_solaris.cpp", line 369:
>>>>>> Error:
>>>>>> dd_fd is not a member of DIR."
>>>>>> gmake[8]: *** [perfMemory_solaris.o] Error 2
>>>>>
>>>>>
>>>>> This code was brought in via the recent CPU integration of bug
>>>>> 8050807. (Hi
>>>>> Jerry! - cc'd)
>>>>>
>>>>> It looks like Solaris has two potential definitions of DIR:
>>>>>
>>>>> #if defined(__USE_LEGACY_PROTOTYPES__)
>>>>> /* traditional SVR4 definition */
>>>>> typedef struct {
>>>>>          int     dd_fd;          /* file descriptor */
>>>>>          int     dd_loc;         /* offset in block */
>>>>>          int     dd_size;        /* amount of valid data */
>>>>>          char    *dd_buf;        /* directory block */
>>>>> } DIR;                          /* stream data from opendir() */
>>>>> #else
>>>>> /* default definition (POSIX conformant) */
>>>>> typedef struct {
>>>>>          int     d_fd;           /* file descriptor */
>>>>>          int     d_loc;          /* offset in block */
>>>>>          int     d_size;         /* amount of valid data */
>>>>>          char    *d_buf;         /* directory block */
>>>>> } DIR;                          /* stream data from opendir() */
>>>>> #endif  /* __USE_LEGACY_PROTOTYPES__ */
>>>>>
>>>>> I can't see what controls __USE_LEGACY_PROTOTYPES__ but presumably
>>>>> either
>>>>> something in Solaris 11.1, or something in SS12u3 is causing this
>>>>> difference.
>>>>>
>>>>> David
>>>>>
>>>>>> thanks
>>>>>>
>>>>>> Tony
>>
>


From Alan.Bateman at oracle.com  Sat Jan 24 08:55:40 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 24 Jan 2015 08:55:40 +0000
Subject: RFR: JDK-8055190: Cleanup include and exclude of core-libs native
	libraries after source code restructure
In-Reply-To: <54C261C6.5030705@oracle.com>
References: <54C25C3E.4030501@oracle.com> <54C25D9C.2040408@oracle.com>
	<54C261C6.5030705@oracle.com>
Message-ID: <54C35E0C.8080406@oracle.com>

On 23/01/2015 14:59, Erik Joelsson wrote:
> :
>> Can refs.allowed be removed? I thought we removed the JDK 8 
>> dependency checker early in JDK 9 so this file shouldn't be needed.
>>
> I was wondering what it was and could not find any usages. With your 
> confirmation I have opted to remove it completely instead.
>
> Updated webrev: http://cr.openjdk.java.net/~erikj/8055190/webrev.02/
Thanks, this looks good to me.

-Alan


From mark.reinhold at oracle.com  Sat Jan 24 23:05:09 2015
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Sat, 24 Jan 2015 15:05:09 -0800
Subject: OpenJDK Governing Board CFV: New Build Group Lead: Tim Bell
In-Reply-To: <20150120092831.324636@eggemoggin.niobe.net>
References: <20150120092831.324636@eggemoggin.niobe.net>
Message-ID: <20150124150509.472760@eggemoggin.niobe.net>

2015/1/20 9:28 -0800, mark.reinhold at oracle.com:
> Kelly O'Hair resigned as the Lead of the Build Group in April 2014 [1].
> Tim Bell was voted in as the new Group Lead shortly thereafter [2].
> (Unfortunately this particular change slipped through the cracks, which
>  is why you're only hearing about it now.  My apologies.)
> 
> Governing Board members: Please vote on whether to ratify this change, as
> required by the Bylaws [3].  Votes are due in one week, by 18:00 UTC next
> Tuesday, 27 January 2015.  Votes must be cast in the open by replying to
> this message.

Thank you for your votes.  A majority have voted in favor of
ratification, so this vote can close early.

Tim Bell is now the Lead of the Build Group.

- Mark


From erik.joelsson at oracle.com  Mon Jan 26 09:47:06 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 26 Jan 2015 10:47:06 +0100
Subject: RFR: JDK-8071329: Stop exporting INCLUDE and LIB when building
	on windows
In-Reply-To: <54C10BC8.50805@oracle.com>
References: <54C10BC8.50805@oracle.com>
Message-ID: <54C60D1A.8090408@oracle.com>

Adding core-libs-dev looking for a reviewer for the unpack200 changes.

In the old build, unpack200.exe was linked with cl.exe instead of 
link.exe like all other executables and libraries. Since the formatting 
of options is completely different, the same linker flags were not used. 
In this change, I'm removing this special treatment of unpack200.exe so 
that it is linked just like all other executables.

/Erik

On 2015-01-22 15:40, Erik Joelsson wrote:
> Hello,
>
> Please review this patch, which makes it possible to take a compile 
> command line from the make debug log on Windows, and rerun it in a 
> normal cygwin environment, without the need for running vsvars*.bat 
> first.
>
> When building native code on windows, using Visual Studio, configure 
> extracts the build environment from the setup .bat file provided by VS 
> and sets 3 variables in spec.gmk: PATH, INCLUDE and LIB. These 3 
> variables are also exported into the environment in spec.gmk, so that 
> every tool run by the build will see them. While this is convenient, 
> it makes the command lines used by the build unusable outside of the 
> build, unless you also export these variables with the correct values.
>
> I have removed the need for INCLUDE and LIB to be exported, by 
> converting their contents into compiler and linker flags. These flags 
> conceptually fit well in the recent SYSROOT_CFLAGS and SYSROOT_LDFLAGS 
> variables.
>
> The PATH variable would be nice to not have to set, and while not 
> setting it seems to work most of the time, I suspect that there are 
> cases when it won't work. More specifically, in certain environments, 
> some dll needed by the compiler program might not be on the path 
> without it. So I left it being set for now.
>
> The new LDFLAGS requires unpack200.exe to stop being linked 
> differently to all other executables. There is no reason for this 
> discrepancy that I can find, it just seems like someone did a bit of a 
> quick hack getting it to build long ago in the old build, and we 
> wanted to keep it equivalent in build-infra.
>
> The hotspot build still requires the variables to be exported, so they 
> are still being defined in hotspot-spec.gmk.
>
> While working on this, I stumbled on a problem when running "make 
> reconfigure". The PATH variable value, since exported in make, would 
> get longer and longer for each time you run reconfigure. I fixed this 
> by saving the original path and resetting it before running configure 
> from make.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8071329
> Webrevs:
> http://cr.openjdk.java.net/~erikj/8071329/webrev.root.01/
> http://cr.openjdk.java.net/~erikj/8071329/webrev.jdk.01/
>
> /Erik



From erik.joelsson at oracle.com  Mon Jan 26 11:26:00 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 26 Jan 2015 12:26:00 +0100
Subject: RFR: JDK-8071550: SetupJavaComilation EXCLUDE/INCLUDE/EXCLUDE_FILE
	do not work on META-INF files
Message-ID: <54C62448.9030207@oracle.com>

Hello,

Please review this small fix in JavaCompilation.gmk. SetupJavaComilation 
EXCLUDE/INCLUDE/EXCLUDE_FILE do not work on META-INF files, unless there 
is a COPY or COPY_FILES parameter set. The fix is quite simple. Move the 
filtering of $1_ALL_COPIES outside of the conditional for if $1_COPY or 
$1_COPY_FILES are set.

Bug: https://bugs.openjdk.java.net/browse/JDK-8071550
Webrev: http://cr.openjdk.java.net/~erikj/8071550/webrev.01/

/Erik


From jvanek at redhat.com  Mon Jan 26 14:08:17 2015
From: jvanek at redhat.com (Jiri Vanek)
Date: Mon, 26 Jan 2015 15:08:17 +0100
Subject: [rfc][jdk7] jhat manpage have corrupted url in see also.
Message-ID: <54C64A51.8070907@redhat.com>

hi!

jhat.1  have wrong url in "see also" section in openjdk7 [1]

Jdk 8 and 9 have this url correct.

Attached patch is fixing it: https://jvanek.fedorapeople.org/oracle/jdk7/webrevs/jhat.1/v1/

I do not have commit access, so please if anybody can review and push, I will be happy. It is also 
unifying dots on end of this affected lines

I'm not sure if jdk7u or this one is more correct list. But if this one is at least bit correct....

TY!
  J.


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1164762


From magnus.ihse.bursie at oracle.com  Mon Jan 26 15:04:24 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 26 Jan 2015 16:04:24 +0100
Subject: RFR: JDK-8071550: SetupJavaComilation EXCLUDE/INCLUDE/EXCLUDE_FILE
	do not work on META-INF files
In-Reply-To: <54C62448.9030207@oracle.com>
References: <54C62448.9030207@oracle.com>
Message-ID: <54C65778.7040600@oracle.com>

On 2015-01-26 12:26, Erik Joelsson wrote:
> Hello,
>
> Please review this small fix in JavaCompilation.gmk. 
> SetupJavaComilation EXCLUDE/INCLUDE/EXCLUDE_FILE do not work on 
> META-INF files, unless there is a COPY or COPY_FILES parameter set. 
> The fix is quite simple. Move the filtering of $1_ALL_COPIES outside 
> of the conditional for if $1_COPY or $1_COPY_FILES are set.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8071550
> Webrev: http://cr.openjdk.java.net/~erikj/8071550/webrev.01/
>
> /Erik

Looks good to me.

/Magnus


From jsonlee.ft at gmail.com  Tue Jan 27 12:07:34 2015
From: jsonlee.ft at gmail.com (lee json)
Date: Tue, 27 Jan 2015 20:07:34 +0800
Subject: Building open jdk 8 from source fails
In-Reply-To: <54C23AA3.3050708@oracle.com>
References: <CAG6=6-TO7FU4diVNjT5CUUvMZEbMbfhNQx1wdAwpRL-WS5sA7w@mail.gmail.com>
	<CA+3eh11xjb2wR0sOYuUhXxM9NrfsXyfZQ6DhX=Whd1CYh8ucqg@mail.gmail.com>
	<CAG6=6-QP0UkDkCPV+wkJVf3FXwm5Eryeioth8tMw8RCANbC1Ew@mail.gmail.com>
	<54C23AA3.3050708@oracle.com>
Message-ID: <CAG6=6-SVmMO+Dbv2hycfhMZtX+2jxTxvMQsX58Sm7SDZa5Bc9A@mail.gmail.com>

No luck. After running bash get_source.sh, then re-configure, make,
etc. still produce the same error.

On 23 January 2015 at 20:12, Magnus Ihse Bursie
<magnus.ihse.bursie at oracle.com> wrote:
> On 2015-01-18 04:47, lee json wrote:
>>
>> I switch to cloning repository at
>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/ by command `hg clone
>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev`
>>
>> Then build with command line `bash ./configure
>> --with-boot-jdk=/home/jason/jdk1.7.0_6` or `bash ./configure`. And
>> then execute `make` or `make all` command.
>>
>> The first step i.e. configure successfully completes. Its output looks
>> as the section configure. But failing compile source as the section of
>> make, when calling make/ make all. With or wihtout make clean before
>> make/ make all doesn't make any differences.
>>
>> How to fix such errors? Thanks
>
>
> It looks like you have not gotten all source code correctly. Just cloning
> the top-level repo is not enough.
>
> Try running "bash get_source.sh".
>
> /Magnus
>


From erik.joelsson at oracle.com  Tue Jan 27 13:23:23 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 27 Jan 2015 14:23:23 +0100
Subject: RFR: JDK-8062223: Upgrading to ccache 1.3.10 disables the use of
	ccache
Message-ID: <54C7914B.1050408@oracle.com>

Hello,

Please review this fix cleaning up the ccache setup in configure. This 
patch addresses the concerns in the following bugs:
https://bugs.openjdk.java.net/browse/JDK-8065791
https://bugs.openjdk.java.net/browse/JDK-8014074
https://bugs.openjdk.java.net/browse/JDK-8062223

Webrev: http://cr.openjdk.java.net/~erikj/8062223/webrev.root.01/

I changed the test for ccache version to explicitly check for known 
older versions that we don't want to use with precompiled headers. The 
test is only done if precompiled headers are enabled, since without 
precompiled headers, we don't know of any issues with ccache.

I fixed the ccache options needed to fully function with precompiled 
headers in hotspot. These options will now be used if precompiled 
headers are enabled. They currently aren't fully used.

I updated the documentation to reflect our current stance on ccache.

As noted in JDK-8014074, ccache works better without precompiled 
headers, so I recommend turning it off when using ccache. (I actually 
recommend turning it off on linux regardless.)

Some numbers building just hotspot ("make hotspot") from my machine 
(E5-2665 @ 2.4GHz, 16 cores + HT) with JOBS=15 which is default:

Product/release with precompiled headers
no ccache: 03:13
empty cache: 03:37
perfect cache: 01:36

Product/release without precompiled headers
no ccache: 02:35
empty cache: 02:43
perfect cache: 01:04

/Erik


From magnus.ihse.bursie at oracle.com  Tue Jan 27 13:35:01 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 27 Jan 2015 14:35:01 +0100
Subject: Building open jdk 8 from source fails
In-Reply-To: <CAG6=6-SVmMO+Dbv2hycfhMZtX+2jxTxvMQsX58Sm7SDZa5Bc9A@mail.gmail.com>
References: <CAG6=6-TO7FU4diVNjT5CUUvMZEbMbfhNQx1wdAwpRL-WS5sA7w@mail.gmail.com>	<CA+3eh11xjb2wR0sOYuUhXxM9NrfsXyfZQ6DhX=Whd1CYh8ucqg@mail.gmail.com>	<CAG6=6-QP0UkDkCPV+wkJVf3FXwm5Eryeioth8tMw8RCANbC1Ew@mail.gmail.com>	<54C23AA3.3050708@oracle.com>
	<CAG6=6-SVmMO+Dbv2hycfhMZtX+2jxTxvMQsX58Sm7SDZa5Bc9A@mail.gmail.com>
Message-ID: <54C79405.30703@oracle.com>

On 2015-01-27 13:07, lee json wrote:
> No luck. After running bash get_source.sh, then re-configure, make,
> etc. still produce the same error.
Did you run "make clean"? You can even try running "make dist-clean" and 
re-running configure to really start from a clean slate.

/Magnus

>
> On 23 January 2015 at 20:12, Magnus Ihse Bursie
> <magnus.ihse.bursie at oracle.com> wrote:
>> On 2015-01-18 04:47, lee json wrote:
>>> I switch to cloning repository at
>>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/ by command `hg clone
>>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev`
>>>
>>> Then build with command line `bash ./configure
>>> --with-boot-jdk=/home/jason/jdk1.7.0_6` or `bash ./configure`. And
>>> then execute `make` or `make all` command.
>>>
>>> The first step i.e. configure successfully completes. Its output looks
>>> as the section configure. But failing compile source as the section of
>>> make, when calling make/ make all. With or wihtout make clean before
>>> make/ make all doesn't make any differences.
>>>
>>> How to fix such errors? Thanks
>>
>> It looks like you have not gotten all source code correctly. Just cloning
>> the top-level repo is not enough.
>>
>> Try running "bash get_source.sh".
>>
>> /Magnus
>>



From philip.race at oracle.com  Tue Jan 27 21:24:09 2015
From: philip.race at oracle.com (Phil Race)
Date: Tue, 27 Jan 2015 13:24:09 -0800
Subject: RFR: 8071710: [solaris] libfontmanager should be linked against
	headless awt library
Message-ID: <54C801F9.1050005@oracle.com>

Hi,

A mistake was made in JDK 8 so that the font libraries for Solaris are now
being linked against X11 libraries and this is a problem for headless 
(server) use
For more details see :
https://bugs.openjdk.java.net/browse/JDK-8071710

I am presenting jdk 9 & 8 fixes here since this needs a backport and the
change is not identical

The open part of the JDK 9 fix : http://cr.openjdk.java.net/~prr/8071710/

The complete JDK 8 fix : http://cr.openjdk.java.net/~prr/8071710.8u/
(the t2k linking was moved to closed at some point)

I've submitted JPRT jobs and also verified that UI demos (like 
SwingSet2) still run

-phil.





From jsonlee.ft at gmail.com  Wed Jan 28 04:20:58 2015
From: jsonlee.ft at gmail.com (lee json)
Date: Wed, 28 Jan 2015 12:20:58 +0800
Subject: Building open jdk 8 from source fails
In-Reply-To: <54C79405.30703@oracle.com>
References: <CAG6=6-TO7FU4diVNjT5CUUvMZEbMbfhNQx1wdAwpRL-WS5sA7w@mail.gmail.com>
	<CA+3eh11xjb2wR0sOYuUhXxM9NrfsXyfZQ6DhX=Whd1CYh8ucqg@mail.gmail.com>
	<CAG6=6-QP0UkDkCPV+wkJVf3FXwm5Eryeioth8tMw8RCANbC1Ew@mail.gmail.com>
	<54C23AA3.3050708@oracle.com>
	<CAG6=6-SVmMO+Dbv2hycfhMZtX+2jxTxvMQsX58Sm7SDZa5Bc9A@mail.gmail.com>
	<54C79405.30703@oracle.com>
Message-ID: <CAG6=6-Rzm0aJ1njyqQLqhNNNvCS96QzVzQwUpJeawZmLkUpcjA@mail.gmail.com>

dist clean and configure (with boot jdk) look correct. But really no
luck when executing make

===== below is the output when executing make dist-clean

Cleaning langtools build artifacts ... done
Cleaning corba build artifacts ... done
Cleaning jaxp build artifacts ... done
Cleaning jaxws build artifacts ... done
Cleaning hotspot build artifacts ... done
Cleaning jdk build artifacts ... done
Cleaning nashorn build artifacts ... done
Cleaning images build artifacts ... done
Cleaning overlay-images build artifacts ... done
Cleaning bootcycle-build build artifacts ... done
Cleaning docs build artifacts ... done
Cleaning docstemp build artifacts ... done
Cleaning testoutput build artifacts ... done
Cleaned all build artifacts.
Removing configuration directory for 'linux-x86-normal-server-release'
Cleaned everything, you will have to re-run configure.

===== below is the output when executing configure --with-boot-jdk

A new configuration has been successfully created in
/home/jason/projects/jdk8u-dev/build/linux-x86-normal-server-release
using configure arguments '--with-boot-jdk=/home/jason/jdk1.7.0_60

Configuration summary:
* Debug level:    release
* JDK variant:    normal
* JVM variants:   server
* OpenJDK target: OS: linux, CPU architecture: x86, address length: 32

Tools summary:
* Boot JDK:       java version "1.7.0_60" Java(TM) SE Runtime
Environment (build 1.7.0_60-b19) Java HotSpot(TM) Server VM (build
24.60-b09, mixed mode)  (at /home/jason/jdk1.7.0_60)
* C Compiler:     gcc-4.9 (Debian 4.9.1-19) version 4.9.1 (at /usr/bin/gcc-4.9)
* C++ Compiler:   g++-4.9 (Debian 4.9.1-19) version 4.9.1 (at /usr/bin/g++-4.9)

Build performance summary:
* Cores to use:   4
* Memory limit:   7998 MB
* ccache status:  installed, but disabled (version older than 3.1.4)

============ below is the output when executing make

Building OpenJDK for target 'default' in configuration
'linux-x86-normal-server-release'

## Starting langtools
Compiling 2 files for BUILD_TOOLS
/home/jason/projects/jdk8u-dev/langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java:310:
error: cannot find symbol
        return tk.accepts(S.token(lookahead + 1).kind);
                                                ^
  symbol:   variable kind
  location: class Token

...

100 errors
make[1]: *** No rule to make target 'all', needed by 'default'.  Stop.
/home/jason/projects/jdk8u-dev//make/Main.gmk:83: recipe for target
'langtools-only' failed
make: *** [langtools-only] Error 2




On 27 January 2015 at 21:35, Magnus Ihse Bursie
<magnus.ihse.bursie at oracle.com> wrote:
> On 2015-01-27 13:07, lee json wrote:
>>
>> No luck. After running bash get_source.sh, then re-configure, make,
>> etc. still produce the same error.
>
> Did you run "make clean"? You can even try running "make dist-clean" and
> re-running configure to really start from a clean slate.
>
> /Magnus
>
>
>>
>> On 23 January 2015 at 20:12, Magnus Ihse Bursie
>> <magnus.ihse.bursie at oracle.com> wrote:
>>>
>>> On 2015-01-18 04:47, lee json wrote:
>>>>
>>>> I switch to cloning repository at
>>>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/ by command `hg clone
>>>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev`
>>>>
>>>> Then build with command line `bash ./configure
>>>> --with-boot-jdk=/home/jason/jdk1.7.0_6` or `bash ./configure`. And
>>>> then execute `make` or `make all` command.
>>>>
>>>> The first step i.e. configure successfully completes. Its output looks
>>>> as the section configure. But failing compile source as the section of
>>>> make, when calling make/ make all. With or wihtout make clean before
>>>> make/ make all doesn't make any differences.
>>>>
>>>> How to fix such errors? Thanks
>>>
>>>
>>> It looks like you have not gotten all source code correctly. Just cloning
>>> the top-level repo is not enough.
>>>
>>> Try running "bash get_source.sh".
>>>
>>> /Magnus
>>>
>


From erik.joelsson at oracle.com  Wed Jan 28 09:02:26 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 28 Jan 2015 10:02:26 +0100
Subject: RFR: 8071710: [solaris] libfontmanager should be linked against
	headless awt library
In-Reply-To: <54C801F9.1050005@oracle.com>
References: <54C801F9.1050005@oracle.com>
Message-ID: <54C8A5A2.3070506@oracle.com>

Looks good to me. Nice to get rid of the weird X_LIBS dependency.

/Erik

On 2015-01-27 22:24, Phil Race wrote:
> Hi,
>
> A mistake was made in JDK 8 so that the font libraries for Solaris are 
> now
> being linked against X11 libraries and this is a problem for headless 
> (server) use
> For more details see :
> https://bugs.openjdk.java.net/browse/JDK-8071710
>
> I am presenting jdk 9 & 8 fixes here since this needs a backport and the
> change is not identical
>
> The open part of the JDK 9 fix : http://cr.openjdk.java.net/~prr/8071710/
>
> The complete JDK 8 fix : http://cr.openjdk.java.net/~prr/8071710.8u/
> (the t2k linking was moved to closed at some point)
>
> I've submitted JPRT jobs and also verified that UI demos (like 
> SwingSet2) still run
>
> -phil.
>
>
>



From erik.joelsson at oracle.com  Wed Jan 28 10:46:07 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 28 Jan 2015 11:46:07 +0100
Subject: RFR: JDK-8071651: infinite build loops in 9-dev windows platform
	on Jan 26
Message-ID: <54C8BDEF.3000404@oracle.com>

Hello,

Please review this followup fix for the vardeps patch (JDK-8069261). It 
seems that in Cygwin, when running gnu make 3.82, whitespace isn't 
stripped in the exact same way as on other versions of gnumake that I 
have tested (4.0 on all platforms, 3.81 on linux). The fix to this 
problem was to change the string equals macro that I created and strip 
the arguments in that.

Added a test that reproduces the problem.

Bug: https://bugs.openjdk.java.net/browse/JDK-8071651
Webrev: http://cr.openjdk.java.net/~erikj/8071651/webrev.root.01/

/Erik


From Alan.Bateman at oracle.com  Wed Jan 28 11:51:01 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 28 Jan 2015 11:51:01 +0000
Subject: RFR: JDK-8071651: infinite build loops in 9-dev windows platform
	on Jan 26
In-Reply-To: <54C8BDEF.3000404@oracle.com>
References: <54C8BDEF.3000404@oracle.com>
Message-ID: <54C8CD25.1090307@oracle.com>

On 28/01/2015 10:46, Erik Joelsson wrote:
> Hello,
>
> Please review this followup fix for the vardeps patch (JDK-8069261). 
> It seems that in Cygwin, when running gnu make 3.82, whitespace isn't 
> stripped in the exact same way as on other versions of gnumake that I 
> have tested (4.0 on all platforms, 3.81 on linux). The fix to this 
> problem was to change the string equals macro that I created and strip 
> the arguments in that.
>
> Added a test that reproduces the problem.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8071651
> Webrev: http://cr.openjdk.java.net/~erikj/8071651/webrev.root.01/
The stripping in MakeBase.gmk looks okay to me. Also the test to check 
equals looks okay too.

-Alan


From magnus.ihse.bursie at oracle.com  Wed Jan 28 12:41:32 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 28 Jan 2015 13:41:32 +0100
Subject: RFR: JDK-8071651: infinite build loops in 9-dev windows platform
	on Jan 26
In-Reply-To: <54C8BDEF.3000404@oracle.com>
References: <54C8BDEF.3000404@oracle.com>
Message-ID: <54C8D8FC.8000201@oracle.com>

On 2015-01-28 11:46, Erik Joelsson wrote:
> Hello,
>
> Please review this followup fix for the vardeps patch (JDK-8069261). 
> It seems that in Cygwin, when running gnu make 3.82, whitespace isn't 
> stripped in the exact same way as on other versions of gnumake that I 
> have tested (4.0 on all platforms, 3.81 on linux). The fix to this 
> problem was to change the string equals macro that I created and strip 
> the arguments in that.
>
> Added a test that reproduces the problem.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8071651
> Webrev: http://cr.openjdk.java.net/~erikj/8071651/webrev.root.01/
>
> /Erik

Looks good to me.

Thank you for adding to the test suite!

/Magnus


From magnus.ihse.bursie at oracle.com  Wed Jan 28 13:15:27 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 28 Jan 2015 14:15:27 +0100
Subject: [OpenJDK 2D-Dev] RFR: 8071710: [solaris] libfontmanager should
	be linked against headless awt library
In-Reply-To: <54C801F9.1050005@oracle.com>
References: <54C801F9.1050005@oracle.com>
Message-ID: <54C8E0EF.2010107@oracle.com>

On 2015-01-27 22:24, Phil Race wrote:
> Hi,
>
> A mistake was made in JDK 8 so that the font libraries for Solaris are 
> now
> being linked against X11 libraries and this is a problem for headless 
> (server) use
> For more details see :
> https://bugs.openjdk.java.net/browse/JDK-8071710
>
> I am presenting jdk 9 & 8 fixes here since this needs a backport and the
> change is not identical
>
> The open part of the JDK 9 fix : http://cr.openjdk.java.net/~prr/8071710/
>
> The complete JDK 8 fix : http://cr.openjdk.java.net/~prr/8071710.8u/
> (the t2k linking was moved to closed at some point)
>
> I've submitted JPRT jobs and also verified that UI demos (like 
> SwingSet2) still run

There is an additional fix you need to to, otherwise you will introduce 
a race condition.

This code:
ifneq (, $(findstring $(OPENJDK_TARGET_OS), solaris aix))
   $(BUILD_LIBFONTMANAGER): $(BUILD_LIBAWT_XAWT)
endif

makes sure that libfontmanager is not built until libawt_xawt is present 
(otherwise linking will fail). With your patch, you should change this to

ifeq ($(OPENJDK_TARGET_OS), aix))
   $(BUILD_LIBFONTMANAGER): $(BUILD_LIBAWT_XAWT)
else ifeq ($(OPENJDK_TARGET_OS), solaris))
   $(BUILD_LIBFONTMANAGER): $(BUILD_LIBAWT_HEADLESS)
endif

Otherwise, it looks good.

Erik and I have been discussing for some time to change the framework so 
this kind of dependencies will be automatically enforced, but somehow 
that idea always gets pushed down the priority slide. :(

/Magnus


From erik.joelsson at oracle.com  Wed Jan 28 13:20:40 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 28 Jan 2015 14:20:40 +0100
Subject: [OpenJDK 2D-Dev] RFR: 8071710: [solaris] libfontmanager should
	be linked against headless awt library
In-Reply-To: <54C8E0EF.2010107@oracle.com>
References: <54C801F9.1050005@oracle.com> <54C8E0EF.2010107@oracle.com>
Message-ID: <54C8E228.2050008@oracle.com>

Hello,

On 2015-01-28 14:15, Magnus Ihse Bursie wrote:
> On 2015-01-27 22:24, Phil Race wrote:
>> Hi,
>>
>> A mistake was made in JDK 8 so that the font libraries for Solaris 
>> are now
>> being linked against X11 libraries and this is a problem for headless 
>> (server) use
>> For more details see :
>> https://bugs.openjdk.java.net/browse/JDK-8071710
>>
>> I am presenting jdk 9 & 8 fixes here since this needs a backport and the
>> change is not identical
>>
>> The open part of the JDK 9 fix : 
>> http://cr.openjdk.java.net/~prr/8071710/
>>
>> The complete JDK 8 fix : http://cr.openjdk.java.net/~prr/8071710.8u/
>> (the t2k linking was moved to closed at some point)
>>
>> I've submitted JPRT jobs and also verified that UI demos (like 
>> SwingSet2) still run
>
> There is an additional fix you need to to, otherwise you will 
> introduce a race condition.
>
> This code:
> ifneq (, $(findstring $(OPENJDK_TARGET_OS), solaris aix))
>   $(BUILD_LIBFONTMANAGER): $(BUILD_LIBAWT_XAWT)
> endif
>
Thanks for noticing this Magnus!
> makes sure that libfontmanager is not built until libawt_xawt is 
> present (otherwise linking will fail). With your patch, you should 
> change this to
>
> ifeq ($(OPENJDK_TARGET_OS), aix))
>   $(BUILD_LIBFONTMANAGER): $(BUILD_LIBAWT_XAWT)
> else ifeq ($(OPENJDK_TARGET_OS), solaris))
>   $(BUILD_LIBFONTMANAGER): $(BUILD_LIBAWT_HEADLESS)
> endif
>
Actually, in the jdk8 patch, only solaris is changed, but in the jdk9 
patch, both aix and solaris are changed. If that is indeed the 
intention, the above is correct for jdk8, but I suspect the changes 
should match?

/Erik
> Otherwise, it looks good.
>
> Erik and I have been discussing for some time to change the framework 
> so this kind of dependencies will be automatically enforced, but 
> somehow that idea always gets pushed down the priority slide. :(
>
> /Magnus



From erik.joelsson at oracle.com  Wed Jan 28 13:58:13 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 28 Jan 2015 14:58:13 +0100
Subject: RFR: JDK-8071781: Bootcycle build fails on macosx
Message-ID: <54C8EAF5.1050705@oracle.com>

Hello,

Please review this small fix for bootcycle-images on macosx. The space 
in the patsubst call caused HOTSPOT_DIST to contain a leading space 
which in turn made hotspot/make/bsd/makefiles/universal.gmk fail to run 
lipo on the files in HOTSPOT_DIST in the second phase bootcycle build.

Bug: https://bugs.openjdk.java.net/browse/JDK-8071781
Patch inline:
diff --git a/common/autoconf/bootcycle-spec.gmk.in 
b/common/autoconf/bootcycle-spec.gmk.in
--- a/common/autoconf/bootcycle-spec.gmk.in
+++ b/common/autoconf/bootcycle-spec.gmk.in
@@ -48,8 +48,9 @@
  # The bootcycle build has a different output directory
  OLD_BUILD_OUTPUT:=@BUILD_OUTPUT@
  BUILD_OUTPUT:=$(OLD_BUILD_OUTPUT)/bootcycle-build
-# The HOTSPOT_DIST dir is not defined relative to BUILD_OUTPUT in spec.gmk
-HOTSPOT_DIST:=$(patsubst $(OLD_BUILD_OUTPUT)%, $(BUILD_OUTPUT)%, 
$(HOTSPOT_DIST))
+# The HOTSPOT_DIST dir is not defined relative to BUILD_OUTPUT in 
spec.gmk. Must not
+# use space in this patsubst to avoid leading space in HOTSPOT_DIST.
+HOTSPOT_DIST:=$(patsubst 
$(OLD_BUILD_OUTPUT)%,$(BUILD_OUTPUT)%,$(HOTSPOT_DIST))
  SJAVAC_SERVER_DIR:=$(patsubst $(OLD_BUILD_OUTPUT)%, $(BUILD_OUTPUT)%, 
$(SJAVAC_SERVER_DIR))

  JAVA_CMD:=$(BOOT_JDK)/bin/java



From magnus.ihse.bursie at oracle.com  Wed Jan 28 14:23:22 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 28 Jan 2015 15:23:22 +0100
Subject: RFR: JDK-8071781: Bootcycle build fails on macosx
In-Reply-To: <54C8EAF5.1050705@oracle.com>
References: <54C8EAF5.1050705@oracle.com>
Message-ID: <54C8F0DA.3080400@oracle.com>

On 2015-01-28 14:58, Erik Joelsson wrote:
> Hello,
>
> Please review this small fix for bootcycle-images on macosx. The space 
> in the patsubst call caused HOTSPOT_DIST to contain a leading space 
> which in turn made hotspot/make/bsd/makefiles/universal.gmk fail to 
> run lipo on the files in HOTSPOT_DIST in the second phase bootcycle 
> build.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8071781
> Patch inline:
> diff --git a/common/autoconf/bootcycle-spec.gmk.in 
> b/common/autoconf/bootcycle-spec.gmk.in
> --- a/common/autoconf/bootcycle-spec.gmk.in
> +++ b/common/autoconf/bootcycle-spec.gmk.in
> @@ -48,8 +48,9 @@
>  # The bootcycle build has a different output directory
>  OLD_BUILD_OUTPUT:=@BUILD_OUTPUT@
>  BUILD_OUTPUT:=$(OLD_BUILD_OUTPUT)/bootcycle-build
> -# The HOTSPOT_DIST dir is not defined relative to BUILD_OUTPUT in 
> spec.gmk
> -HOTSPOT_DIST:=$(patsubst $(OLD_BUILD_OUTPUT)%, $(BUILD_OUTPUT)%, 
> $(HOTSPOT_DIST))
> +# The HOTSPOT_DIST dir is not defined relative to BUILD_OUTPUT in 
> spec.gmk. Must not
> +# use space in this patsubst to avoid leading space in HOTSPOT_DIST.
> +HOTSPOT_DIST:=$(patsubst 
> $(OLD_BUILD_OUTPUT)%,$(BUILD_OUTPUT)%,$(HOTSPOT_DIST))
>  SJAVAC_SERVER_DIR:=$(patsubst $(OLD_BUILD_OUTPUT)%, $(BUILD_OUTPUT)%, 
> $(SJAVAC_SERVER_DIR))
>
>  JAVA_CMD:=$(BOOT_JDK)/bin/java
>

Looks good to me. But oh how a single small space can cause the entire 
build to come into a flaming crash. :-)

/Magnus


From pointo1d at gmail.com  Wed Jan 28 15:24:10 2015
From: pointo1d at gmail.com (Dave Pointon)
Date: Wed, 28 Jan 2015 15:24:10 +0000
Subject: Compile fails in JDK8
Message-ID: <CACONdhKc3c+uTOGgz6qqnjrvkj_U3qWLQWm1Yw6_QizeBA4QGA@mail.gmail.com>

Hi all ,


I'm hoping someone can help me out with the following error when attempting
to build in JDK8 forest on RHEL 6.5 ...

/home/dpointo8/sandbox/source/jdk/src/share/native/sun/misc/Signal.c:45:29:
error: sun_misc_Signal.h: No such file or directory
gmake[2]: *** [/home/dpointo8/sandbox/jcl-bin/jdk/objs/libjava/Signal.o]
Error 1
gmake[2]: *** Waiting for unfinished jobs....
gmake[2]: Leaving directory
`/home/dpointo8/work/repos/Hg/80head.new/jdk/makefiles'
gmake[1]: *** [libs-only] Error 2
gmake[1]: Leaving directory
`/home/dpointo8/work/repos/Hg/80head.new/jdk/makefiles'
make: *** [jdk-only] Error 2
make images failed, aborting...


I've looked thro' the whole of the forest and the header file is nowhere to
be found and neither is it to be found anywhere else on the compile host,
so the question is, can anyone tell me from where this file originates ?

TIA ,
--
Dave Pointon FIAP MBCS

Now I saw, tho' too late, the folly of beginning a work before we count the
cost and before we we judge rightly of our strength to go thro' with it -
Robinson Crusoe


From aph at redhat.com  Wed Jan 28 15:53:54 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 28 Jan 2015 15:53:54 +0000
Subject: Compile fails in JDK8
In-Reply-To: <CACONdhKc3c+uTOGgz6qqnjrvkj_U3qWLQWm1Yw6_QizeBA4QGA@mail.gmail.com>
References: <CACONdhKc3c+uTOGgz6qqnjrvkj_U3qWLQWm1Yw6_QizeBA4QGA@mail.gmail.com>
Message-ID: <54C90612.20701@redhat.com>

On 01/28/2015 03:24 PM, Dave Pointon wrote:
> I've looked thro' the whole of the forest and the header file is nowhere to
> be found and neither is it to be found anywhere else on the compile host,
> so the question is, can anyone tell me from where this file originates ?

It's generated at build time.  It should be in build/linux-$ARCH-normal-server-release/jdk/gensrc_headers/sun_misc_Signal.h

Andrew.



From pointo1d at gmail.com  Wed Jan 28 15:56:16 2015
From: pointo1d at gmail.com (Dave Pointon)
Date: Wed, 28 Jan 2015 15:56:16 +0000
Subject: Compile fails in JDK8
In-Reply-To: <54C90612.20701@redhat.com>
References: <CACONdhKc3c+uTOGgz6qqnjrvkj_U3qWLQWm1Yw6_QizeBA4QGA@mail.gmail.com>
	<54C90612.20701@redhat.com>
Message-ID: <CACONdhLUJJ_xfQ6jrK6+Hd+s-nK8ghCp0RuZf=nXkYce9TvcAw@mail.gmail.com>

TFT Andrew ,

?I did wonder ... I had a look in there - to no avail but your confirmation
was what was required - I've now a better idea of where to start looking :-)
?
Many thanx agin.

--
Dave Pointon FIAP MBCS

Now I saw, tho' too late, the folly of beginning a work before we count the
cost and before we we judge rightly of our strength to go thro' with it -
Robinson Crusoe

On 28 January 2015 at 15:53, Andrew Haley <aph at redhat.com> wrote:

> On 01/28/2015 03:24 PM, Dave Pointon wrote:
> > I've looked thro' the whole of the forest and the header file is nowhere
> to
> > be found and neither is it to be found anywhere else on the compile host,
> > so the question is, can anyone tell me from where this file originates ?
>
> It's generated at build time.  It should be in
> build/linux-$ARCH-normal-server-release/jdk/gensrc_headers/sun_misc_Signal.h
>
> Andrew.
>
>


From philip.race at oracle.com  Wed Jan 28 19:04:10 2015
From: philip.race at oracle.com (Phil Race)
Date: Wed, 28 Jan 2015 11:04:10 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8071710: [solaris] libfontmanager should
	be linked against headless awt library
In-Reply-To: <54C8E0EF.2010107@oracle.com>
References: <54C801F9.1050005@oracle.com> <54C8E0EF.2010107@oracle.com>
Message-ID: <54C932AA.7040701@oracle.com>

I have updated both the patches to add the dependency that headless awt
must be built first and also corrected that AIX should be given the same 
treatment
as Solaris in both releases :
jdk9: http://cr.openjdk.java.net/~prr/8071710.1/
jdk8u: http://cr.openjdk.java.net/~prr/8071710.8u.1/

-phil.

On 01/28/2015 05:15 AM, Magnus Ihse Bursie wrote:
> On 2015-01-27 22:24, Phil Race wrote:
>> Hi,
>>
>> A mistake was made in JDK 8 so that the font libraries for Solaris 
>> are now
>> being linked against X11 libraries and this is a problem for headless 
>> (server) use
>> For more details see :
>> https://bugs.openjdk.java.net/browse/JDK-8071710
>>
>> I am presenting jdk 9 & 8 fixes here since this needs a backport and the
>> change is not identical
>>
>> The open part of the JDK 9 fix : 
>> http://cr.openjdk.java.net/~prr/8071710/
>>
>> The complete JDK 8 fix : http://cr.openjdk.java.net/~prr/8071710.8u/
>> (the t2k linking was moved to closed at some point)
>>
>> I've submitted JPRT jobs and also verified that UI demos (like 
>> SwingSet2) still run
>
> There is an additional fix you need to to, otherwise you will 
> introduce a race condition.
>
> This code:
> ifneq (, $(findstring $(OPENJDK_TARGET_OS), solaris aix))
>   $(BUILD_LIBFONTMANAGER): $(BUILD_LIBAWT_XAWT)
> endif
>
> makes sure that libfontmanager is not built until libawt_xawt is 
> present (otherwise linking will fail). With your patch, you should 
> change this to
>
> ifeq ($(OPENJDK_TARGET_OS), aix))
>   $(BUILD_LIBFONTMANAGER): $(BUILD_LIBAWT_XAWT)
> else ifeq ($(OPENJDK_TARGET_OS), solaris))
>   $(BUILD_LIBFONTMANAGER): $(BUILD_LIBAWT_HEADLESS)
> endif
>
> Otherwise, it looks good.
>
> Erik and I have been discussing for some time to change the framework 
> so this kind of dependencies will be automatically enforced, but 
> somehow that idea always gets pushed down the priority slide. :(
>
> /Magnus



From erik.joelsson at oracle.com  Thu Jan 29 08:22:38 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 29 Jan 2015 09:22:38 +0100
Subject: [OpenJDK 2D-Dev] RFR: 8071710: [solaris] libfontmanager should
	be linked against headless awt library
In-Reply-To: <54C932AA.7040701@oracle.com>
References: <54C801F9.1050005@oracle.com> <54C8E0EF.2010107@oracle.com>
	<54C932AA.7040701@oracle.com>
Message-ID: <54C9EDCE.5080005@oracle.com>

Thanks, that looks good to me.

/Erik

On 2015-01-28 20:04, Phil Race wrote:
> I have updated both the patches to add the dependency that headless awt
> must be built first and also corrected that AIX should be given the 
> same treatment
> as Solaris in both releases :
> jdk9: http://cr.openjdk.java.net/~prr/8071710.1/
> jdk8u: http://cr.openjdk.java.net/~prr/8071710.8u.1/
>
> -phil.
>
> On 01/28/2015 05:15 AM, Magnus Ihse Bursie wrote:
>> On 2015-01-27 22:24, Phil Race wrote:
>>> Hi,
>>>
>>> A mistake was made in JDK 8 so that the font libraries for Solaris 
>>> are now
>>> being linked against X11 libraries and this is a problem for 
>>> headless (server) use
>>> For more details see :
>>> https://bugs.openjdk.java.net/browse/JDK-8071710
>>>
>>> I am presenting jdk 9 & 8 fixes here since this needs a backport and 
>>> the
>>> change is not identical
>>>
>>> The open part of the JDK 9 fix : 
>>> http://cr.openjdk.java.net/~prr/8071710/
>>>
>>> The complete JDK 8 fix : http://cr.openjdk.java.net/~prr/8071710.8u/
>>> (the t2k linking was moved to closed at some point)
>>>
>>> I've submitted JPRT jobs and also verified that UI demos (like 
>>> SwingSet2) still run
>>
>> There is an additional fix you need to to, otherwise you will 
>> introduce a race condition.
>>
>> This code:
>> ifneq (, $(findstring $(OPENJDK_TARGET_OS), solaris aix))
>>   $(BUILD_LIBFONTMANAGER): $(BUILD_LIBAWT_XAWT)
>> endif
>>
>> makes sure that libfontmanager is not built until libawt_xawt is 
>> present (otherwise linking will fail). With your patch, you should 
>> change this to
>>
>> ifeq ($(OPENJDK_TARGET_OS), aix))
>>   $(BUILD_LIBFONTMANAGER): $(BUILD_LIBAWT_XAWT)
>> else ifeq ($(OPENJDK_TARGET_OS), solaris))
>>   $(BUILD_LIBFONTMANAGER): $(BUILD_LIBAWT_HEADLESS)
>> endif
>>
>> Otherwise, it looks good.
>>
>> Erik and I have been discussing for some time to change the framework 
>> so this kind of dependencies will be automatically enforced, but 
>> somehow that idea always gets pushed down the priority slide. :(
>>
>> /Magnus
>



From mkorszun at gmail.com  Thu Jan 29 15:47:21 2015
From: mkorszun at gmail.com (matchew)
Date: Thu, 29 Jan 2015 16:47:21 +0100
Subject: OpenJDK 8 build fails on Ubuntu 12.04.5 LTS
Message-ID: <CAAt5ms8tS1bw2ARy--qMko4RGanw8RH6fVsADzuNqzPwURTU_A@mail.gmail.com>

When it comes to JDK compilation (i am executing *make all*) I am getting
this error:

## Starting jdk
Compiling 162 files for BUILD_TOOLS
/bin/sh: 1:
-Xbootclasspath/p:/opt/openjdk/8/build/linux-x86_64-normal-server-release/langtools/dist/bootstrap/lib/javac.jar:
not found
make[2]: ***
[/opt/openjdk/8/build/linux-x86_64-normal-server-release/jdk/btclasses/_the.BUILD_TOOLS_batch]
Error 127
make[1]: *** [gensrc-only] Error 2
make: *** [jdk-only] Error 2

Which is strange because file
/opt/openjdk/8/build/linux-x86_64-normal-server-release/langtools/dist/bootstrap/lib/javac.jar
 exists.

*Tools summary:*

** Boot JDK:*
java version "1.7.0_65" OpenJDK Runtime Environment (IcedTea 2.5.3)
(7u71-2.5.3-0ubuntu0.12.04.1) OpenJDK 64-Bit Server VM (build 24.65-b04,
mixed mode)  (at /usr/lib/jvm/java-7-openjdk-amd64)

** C Compiler:*
gcc-4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5) version 4.6.3 (at /usr/bin/gcc-4.6)

** C++ Compiler:*
g++-4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5) version 4.6.3 (at /usr/bin/g++-4.6)

*System:*
Linux lxc-dev-19 3.2.0-63-virtual #95-Ubuntu SMP Thu May 15 23:24:31 UTC
2014 x86_64 x86_64 x86_64 GNU/Linux

Thanks in Advance
--
Mateusz


From magnus.ihse.bursie at oracle.com  Thu Jan 29 21:02:52 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 29 Jan 2015 22:02:52 +0100
Subject: OpenJDK 8 build fails on Ubuntu 12.04.5 LTS
In-Reply-To: <CAAt5ms8tS1bw2ARy--qMko4RGanw8RH6fVsADzuNqzPwURTU_A@mail.gmail.com>
References: <CAAt5ms8tS1bw2ARy--qMko4RGanw8RH6fVsADzuNqzPwURTU_A@mail.gmail.com>
Message-ID: <54CA9FFC.6030806@oracle.com>

On 2015-01-29 16:47, matchew wrote:
> When it comes to JDK compilation (i am executing *make all*) I am getting
> this error:
>
> ## Starting jdk
> Compiling 162 files for BUILD_TOOLS
> /bin/sh: 1:
> -Xbootclasspath/p:/opt/openjdk/8/build/linux-x86_64-normal-server-release/langtools/dist/bootstrap/lib/javac.jar:
> not found
> make[2]: ***
> [/opt/openjdk/8/build/linux-x86_64-normal-server-release/jdk/btclasses/_the.BUILD_TOOLS_batch]
> Error 127
> make[1]: *** [gensrc-only] Error 2
> make: *** [jdk-only] Error 2
>
> Which is strange because file
> /opt/openjdk/8/build/linux-x86_64-normal-server-release/langtools/dist/bootstrap/lib/javac.jar
>   exists.

The command line was supposed to look something like this
/usr/bin/java 
-Xbootclasspath/p:/opt/openjdk/8/build/linux-x86_64-normal-server-release/langtools/dist/bootstrap/lib/javac.jar 
...
but the executable java is missing.  Thus the shell tries to execute 
-Xbootclasspath... but that is not a valid executable.

Most likely, your spec.gmk is broken somehow, and $(JAVA) expands to 
nothing.

Did you get any error messages when running configure?

/Magnus


From mkorszun at gmail.com  Thu Jan 29 22:03:47 2015
From: mkorszun at gmail.com (matchew)
Date: Thu, 29 Jan 2015 23:03:47 +0100
Subject: OpenJDK 8 build fails on Ubuntu 12.04.5 LTS
In-Reply-To: <54CA9FFC.6030806@oracle.com>
References: <CAAt5ms8tS1bw2ARy--qMko4RGanw8RH6fVsADzuNqzPwURTU_A@mail.gmail.com>
	<54CA9FFC.6030806@oracle.com>
Message-ID: <CAAt5ms88oz+HV1GQnGO9w4XfOPoyJZ_aYZxofyMBP7g2P0_30A@mail.gmail.com>

No, configure was successful. Here is the summary:

====================================================
A new configuration has been successfully created in
/opt/openjdk/8/build/linux-x86_64-normal-server-release
using configure arguments '--with-cacerts-file=/etc/ssl/certs/java/cacerts
--with-boot-jdk=/usr/lib/jvm/java-7-openjdk-amd64'.

Configuration summary:
* Debug level:    release
* JDK variant:    normal
* JVM variants:   server
* OpenJDK target: OS: linux, CPU architecture: x86, address length: 64

Tools summary:
* Boot JDK:       java version "1.7.0_65" OpenJDK Runtime Environment
(IcedTea 2.5.3) (7u71-2.5.3-0ubuntu0.12.04.1) OpenJDK 64-Bit Server VM
(build 24.65-b04, mixed mode)  (at /usr/lib/jvm/java-7-openjdk-amd64)
* C Compiler:     gcc-4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5) version 4.6.3 (at
/usr/bin/gcc-4.6)
* C++ Compiler:   g++-4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5) version 4.6.3 (at
/usr/bin/g++-4.6)

Build performance summary:
* Cores to use:   1
* Memory limit:   3750 MB
* ccache status:  not installed (consider installing)

WARNING: You have old-style ALT_ environment variables set.
These are not respected, and will be ignored. It is recommended
that you clean your environment. The following variables are set:
ALT_BOOTDIR=/usr/lib/jvm/java-7-openjdk-amd64
ALT_CACERTS_FILE=/etc/ssl/certs/java/cacerts

WARNING: The result of this configuration has overridden an older
configuration. You *should* run 'make clean' to make sure you get a
proper build. Failure to do so might result in strange build problems.

In the past I was using http://hg.openjdk.java.net/jdk8/jdk8 but recently
switched to http://hg.openjdk.java.net/jdk8u/jdk8u and faced above problems.

2015-01-29 22:02 GMT+01:00 Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com
>:

> On 2015-01-29 16:47, matchew wrote:
>
>> When it comes to JDK compilation (i am executing *make all*) I am getting
>> this error:
>>
>> ## Starting jdk
>> Compiling 162 files for BUILD_TOOLS
>> /bin/sh: 1:
>> -Xbootclasspath/p:/opt/openjdk/8/build/linux-x86_64-
>> normal-server-release/langtools/dist/bootstrap/lib/javac.jar:
>> not found
>> make[2]: ***
>> [/opt/openjdk/8/build/linux-x86_64-normal-server-release/
>> jdk/btclasses/_the.BUILD_TOOLS_batch]
>> Error 127
>> make[1]: *** [gensrc-only] Error 2
>> make: *** [jdk-only] Error 2
>>
>> Which is strange because file
>> /opt/openjdk/8/build/linux-x86_64-normal-server-release/
>> langtools/dist/bootstrap/lib/javac.jar
>>   exists.
>>
>
> The command line was supposed to look something like this
> /usr/bin/java -Xbootclasspath/p:/opt/openjdk/8/build/linux-x86_64-
> normal-server-release/langtools/dist/bootstrap/lib/javac.jar ...
> but the executable java is missing.  Thus the shell tries to execute
> -Xbootclasspath... but that is not a valid executable.
>
> Most likely, your spec.gmk is broken somehow, and $(JAVA) expands to
> nothing.
>
> Did you get any error messages when running configure?
>
> /Magnus
>


From david.holmes at oracle.com  Fri Jan 30 03:13:54 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 30 Jan 2015 13:13:54 +1000
Subject: OpenJDK 8 build fails on Ubuntu 12.04.5 LTS
In-Reply-To: <CAAt5ms88oz+HV1GQnGO9w4XfOPoyJZ_aYZxofyMBP7g2P0_30A@mail.gmail.com>
References: <CAAt5ms8tS1bw2ARy--qMko4RGanw8RH6fVsADzuNqzPwURTU_A@mail.gmail.com>	<54CA9FFC.6030806@oracle.com>
	<CAAt5ms88oz+HV1GQnGO9w4XfOPoyJZ_aYZxofyMBP7g2P0_30A@mail.gmail.com>
Message-ID: <54CAF6F2.5090603@oracle.com>

Did you try removing the existing configuration and generating it 
cleanly as the warning suggested?

David

On 30/01/2015 8:03 AM, matchew wrote:
> No, configure was successful. Here is the summary:
>
> ====================================================
> A new configuration has been successfully created in
> /opt/openjdk/8/build/linux-x86_64-normal-server-release
> using configure arguments '--with-cacerts-file=/etc/ssl/certs/java/cacerts
> --with-boot-jdk=/usr/lib/jvm/java-7-openjdk-amd64'.
>
> Configuration summary:
> * Debug level:    release
> * JDK variant:    normal
> * JVM variants:   server
> * OpenJDK target: OS: linux, CPU architecture: x86, address length: 64
>
> Tools summary:
> * Boot JDK:       java version "1.7.0_65" OpenJDK Runtime Environment
> (IcedTea 2.5.3) (7u71-2.5.3-0ubuntu0.12.04.1) OpenJDK 64-Bit Server VM
> (build 24.65-b04, mixed mode)  (at /usr/lib/jvm/java-7-openjdk-amd64)
> * C Compiler:     gcc-4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5) version 4.6.3 (at
> /usr/bin/gcc-4.6)
> * C++ Compiler:   g++-4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5) version 4.6.3 (at
> /usr/bin/g++-4.6)
>
> Build performance summary:
> * Cores to use:   1
> * Memory limit:   3750 MB
> * ccache status:  not installed (consider installing)
>
> WARNING: You have old-style ALT_ environment variables set.
> These are not respected, and will be ignored. It is recommended
> that you clean your environment. The following variables are set:
> ALT_BOOTDIR=/usr/lib/jvm/java-7-openjdk-amd64
> ALT_CACERTS_FILE=/etc/ssl/certs/java/cacerts
>
> WARNING: The result of this configuration has overridden an older
> configuration. You *should* run 'make clean' to make sure you get a
> proper build. Failure to do so might result in strange build problems.
>
> In the past I was using http://hg.openjdk.java.net/jdk8/jdk8 but recently
> switched to http://hg.openjdk.java.net/jdk8u/jdk8u and faced above problems.
>
> 2015-01-29 22:02 GMT+01:00 Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com
>> :
>
>> On 2015-01-29 16:47, matchew wrote:
>>
>>> When it comes to JDK compilation (i am executing *make all*) I am getting
>>> this error:
>>>
>>> ## Starting jdk
>>> Compiling 162 files for BUILD_TOOLS
>>> /bin/sh: 1:
>>> -Xbootclasspath/p:/opt/openjdk/8/build/linux-x86_64-
>>> normal-server-release/langtools/dist/bootstrap/lib/javac.jar:
>>> not found
>>> make[2]: ***
>>> [/opt/openjdk/8/build/linux-x86_64-normal-server-release/
>>> jdk/btclasses/_the.BUILD_TOOLS_batch]
>>> Error 127
>>> make[1]: *** [gensrc-only] Error 2
>>> make: *** [jdk-only] Error 2
>>>
>>> Which is strange because file
>>> /opt/openjdk/8/build/linux-x86_64-normal-server-release/
>>> langtools/dist/bootstrap/lib/javac.jar
>>>    exists.
>>>
>>
>> The command line was supposed to look something like this
>> /usr/bin/java -Xbootclasspath/p:/opt/openjdk/8/build/linux-x86_64-
>> normal-server-release/langtools/dist/bootstrap/lib/javac.jar ...
>> but the executable java is missing.  Thus the shell tries to execute
>> -Xbootclasspath... but that is not a valid executable.
>>
>> Most likely, your spec.gmk is broken somehow, and $(JAVA) expands to
>> nothing.
>>
>> Did you get any error messages when running configure?
>>
>> /Magnus
>>


From mkorszun at gmail.com  Fri Jan 30 09:40:36 2015
From: mkorszun at gmail.com (matchew)
Date: Fri, 30 Jan 2015 10:40:36 +0100
Subject: OpenJDK 8 build fails on Ubuntu 12.04.5 LTS
In-Reply-To: <54CAD6EB.20305@oracle.com>
References: <CAAt5ms8tS1bw2ARy--qMko4RGanw8RH6fVsADzuNqzPwURTU_A@mail.gmail.com>
	<54CA9FFC.6030806@oracle.com>
	<CAAt5ms88oz+HV1GQnGO9w4XfOPoyJZ_aYZxofyMBP7g2P0_30A@mail.gmail.com>
	<54CAD6EB.20305@oracle.com>
Message-ID: <CAAt5ms_bocSubQCGKVbtX33K2zHkSu2KfVM5wiReptk-C=7DbA@mail.gmail.com>

$ grep JAVA /opt/openjdk/8/build/linux-x86_64-normal-server-release/spec.gmk
ENABLE_SJAVAC:=no
SJAVAC_SERVER_DIR:=
JAVA_FLAGS:= -Xms64M -Xmx1100M -XX:PermSize=32m -XX:MaxPermSize=160m
-XX:ThreadStackSize=1536
JAVA= $(BOOT_JDK)/bin/java $(JAVA_FLAGS)
JAVAC= $(BOOT_JDK)/bin/javac
JAVAC_FLAGS?=
JAVAH= $(BOOT_JDK)/bin/javah
# You run the new javac using the boot jdk with $(BOOT_JDK)/bin/java
$(NEW_JAVAC) ...
BOOTSTRAP_JAVAC_JAR:=$(LANGTOOLS_OUTPUTDIR)/dist/bootstrap/lib/javac.jar
BOOTSTRAP_JAVAC_ARGS:="-Xbootclasspath/p:$(BOOTSTRAP_JAVAC_JAR)" -cp
$(BOOTSTRAP_JAVAC_JAR)
NEW_JAVAC   = $(BOOTSTRAP_JAVAC_ARGS) com.sun.tools.javac.Main
NEW_JAVADOC = $(BOOTSTRAP_JAVAC_ARGS) com.sun.tools.javadoc.Main
SJAVAC_SERVER_JAVA:= /usr/lib/jvm/java-7-openjdk-amd64/bin/java  -verbosegc
-d64 -Xms1000M -Xmx1500M

Yes, I did fresh clone from http://hg.openjdk.java.net/jdk8u/jdk8u but I am
using the same build script/procedure I was using before and it was totally
fine with last tag from http://hg.openjdk.java.net/jdk8/jdk8.

2015-01-30 1:57 GMT+01:00 Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
:

>  On 2015-01-29 23:03, matchew wrote:
>
> No, configure was successful. Here is the summary:
>
>
> Weird. What does "grep JAVA
> /opt/openjdk/8/build/linux-x86_64-normal-server-release/spec.gmk" give you?
>
>
>
>  In the past I was using http://hg.openjdk.java.net/jdk8/jdk8 but
> recently switched to http://hg.openjdk.java.net/jdk8u/jdk8u and faced
> above problems.
>
>
> Just to make sure, you did a fresh clone from jdk8u and did not try to
> re-use an old clone from jdk8?
>
> /Magnus
>
>


From mkorszun at gmail.com  Fri Jan 30 09:42:41 2015
From: mkorszun at gmail.com (matchew)
Date: Fri, 30 Jan 2015 10:42:41 +0100
Subject: OpenJDK 8 build fails on Ubuntu 12.04.5 LTS
In-Reply-To: <54CAF6F2.5090603@oracle.com>
References: <CAAt5ms8tS1bw2ARy--qMko4RGanw8RH6fVsADzuNqzPwURTU_A@mail.gmail.com>
	<54CA9FFC.6030806@oracle.com>
	<CAAt5ms88oz+HV1GQnGO9w4XfOPoyJZ_aYZxofyMBP7g2P0_30A@mail.gmail.com>
	<54CAF6F2.5090603@oracle.com>
Message-ID: <CAAt5ms8qBuws7+VCQ+c=tGA87x5O-i3_H_SiBCqFHa_OtDPbjQ@mail.gmail.com>

I have rebuilt everything from the scratch and still have this error. Here
is configure summary:

====================================================
A new configuration has been successfully created in
/opt/openjdk/8/build/linux-x86_64-normal-server-release
using configure arguments '--with-cacerts-file=/etc/ssl/certs/java/cacerts
--with-boot-jdk=/usr/lib/jvm/java-7-openjdk-amd64
--with-build-number=jdk8u31-b13 --with-update-version=jdk8u31-b13'.

Configuration summary:
* Debug level:    release
* JDK variant:    normal
* JVM variants:   server
* OpenJDK target: OS: linux, CPU architecture: x86, address length: 64

Tools summary:
* Boot JDK:       java version "1.7.0_65" OpenJDK Runtime Environment
(IcedTea 2.5.3) (7u71-2.5.3-0ubuntu0.12.04.1) OpenJDK 64-Bit Server VM
(build 24.65-b04, mixed mode)  (at /usr/lib/jvm/java-7-openjdk-amd64)
* C Compiler:     gcc-4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5) version 4.6.3 (at
/usr/bin/gcc-4.6)
* C++ Compiler:   g++-4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5) version 4.6.3 (at
/usr/bin/g++-4.6)

Build performance summary:
* Cores to use:   1
* Memory limit:   3750 MB
* ccache status:  not installed (consider installing)

Build performance tip: ccache gives a tremendous speedup for C++
recompilations.
You do not have ccache installed. Try installing it.
You might be able to fix this by running 'sudo apt-get install ccache'.

WARNING: You have old-style ALT_ environment variables set.
These are not respected, and will be ignored. It is recommended
that you clean your environment. The following variables are set:
ALT_BOOTDIR=/usr/lib/jvm/java-7-openjdk-amd64
ALT_CACERTS_FILE=/etc/ssl/certs/java/cacerts


WARNING: You have the following ALT_ variables set:
ALT_CACERTS_FILE=/etc/ssl/certs/java/cacerts
ALT_BOOTDIR=/usr/lib/jvm/java-7-openjdk-amd64
ALT_ variables are deprecated and will be ignored. Please clean your
environment.

Building OpenJDK for target 'all' in configuration
'linux-x86_64-normal-server-release'

2015-01-30 4:13 GMT+01:00 David Holmes <david.holmes at oracle.com>:

> Did you try removing the existing configuration and generating it cleanly
> as the warning suggested?
>
> David
>
>
> On 30/01/2015 8:03 AM, matchew wrote:
>
>> No, configure was successful. Here is the summary:
>>
>> ====================================================
>> A new configuration has been successfully created in
>> /opt/openjdk/8/build/linux-x86_64-normal-server-release
>> using configure arguments '--with-cacerts-file=/etc/ssl/
>> certs/java/cacerts
>> --with-boot-jdk=/usr/lib/jvm/java-7-openjdk-amd64'.
>>
>> Configuration summary:
>> * Debug level:    release
>> * JDK variant:    normal
>> * JVM variants:   server
>> * OpenJDK target: OS: linux, CPU architecture: x86, address length: 64
>>
>> Tools summary:
>> * Boot JDK:       java version "1.7.0_65" OpenJDK Runtime Environment
>> (IcedTea 2.5.3) (7u71-2.5.3-0ubuntu0.12.04.1) OpenJDK 64-Bit Server VM
>> (build 24.65-b04, mixed mode)  (at /usr/lib/jvm/java-7-openjdk-amd64)
>> * C Compiler:     gcc-4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5) version 4.6.3 (at
>> /usr/bin/gcc-4.6)
>> * C++ Compiler:   g++-4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5) version 4.6.3 (at
>> /usr/bin/g++-4.6)
>>
>> Build performance summary:
>> * Cores to use:   1
>> * Memory limit:   3750 MB
>> * ccache status:  not installed (consider installing)
>>
>> WARNING: You have old-style ALT_ environment variables set.
>> These are not respected, and will be ignored. It is recommended
>> that you clean your environment. The following variables are set:
>> ALT_BOOTDIR=/usr/lib/jvm/java-7-openjdk-amd64
>> ALT_CACERTS_FILE=/etc/ssl/certs/java/cacerts
>>
>> WARNING: The result of this configuration has overridden an older
>> configuration. You *should* run 'make clean' to make sure you get a
>> proper build. Failure to do so might result in strange build problems.
>>
>> In the past I was using http://hg.openjdk.java.net/jdk8/jdk8 but recently
>> switched to http://hg.openjdk.java.net/jdk8u/jdk8u and faced above
>> problems.
>>
>> 2015-01-29 22:02 GMT+01:00 Magnus Ihse Bursie <
>> magnus.ihse.bursie at oracle.com
>>
>>> :
>>>
>>
>>  On 2015-01-29 16:47, matchew wrote:
>>>
>>>  When it comes to JDK compilation (i am executing *make all*) I am
>>>> getting
>>>> this error:
>>>>
>>>> ## Starting jdk
>>>> Compiling 162 files for BUILD_TOOLS
>>>> /bin/sh: 1:
>>>> -Xbootclasspath/p:/opt/openjdk/8/build/linux-x86_64-
>>>> normal-server-release/langtools/dist/bootstrap/lib/javac.jar:
>>>> not found
>>>> make[2]: ***
>>>> [/opt/openjdk/8/build/linux-x86_64-normal-server-release/
>>>> jdk/btclasses/_the.BUILD_TOOLS_batch]
>>>> Error 127
>>>> make[1]: *** [gensrc-only] Error 2
>>>> make: *** [jdk-only] Error 2
>>>>
>>>> Which is strange because file
>>>> /opt/openjdk/8/build/linux-x86_64-normal-server-release/
>>>> langtools/dist/bootstrap/lib/javac.jar
>>>>    exists.
>>>>
>>>>
>>> The command line was supposed to look something like this
>>> /usr/bin/java -Xbootclasspath/p:/opt/openjdk/8/build/linux-x86_64-
>>> normal-server-release/langtools/dist/bootstrap/lib/javac.jar ...
>>> but the executable java is missing.  Thus the shell tries to execute
>>> -Xbootclasspath... but that is not a valid executable.
>>>
>>> Most likely, your spec.gmk is broken somehow, and $(JAVA) expands to
>>> nothing.
>>>
>>> Did you get any error messages when running configure?
>>>
>>> /Magnus
>>>
>>>


From magnus.ihse.bursie at oracle.com  Fri Jan 30 10:24:07 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 30 Jan 2015 11:24:07 +0100
Subject: RFR: JDK-8062223: Upgrading to ccache 1.3.10 disables the use
	of ccache
In-Reply-To: <54C7914B.1050408@oracle.com>
References: <54C7914B.1050408@oracle.com>
Message-ID: <54CB5BC7.5020106@oracle.com>

On 2015-01-27 14:23, Erik Joelsson wrote:
> Hello,
>
> Please review this fix cleaning up the ccache setup in configure. This 
> patch addresses the concerns in the following bugs:
> https://bugs.openjdk.java.net/browse/JDK-8065791
> https://bugs.openjdk.java.net/browse/JDK-8014074
> https://bugs.openjdk.java.net/browse/JDK-8062223
>
> Webrev: http://cr.openjdk.java.net/~erikj/8062223/webrev.root.01/

I would prefer if you rewrote the code in build-performance.m4 slightly.

We have an anti-pattern that's unfortunately too common in our autoconf 
scripts, but I'm trying to eradicate it. :-)

The thing to note is that AC_ARG_ENABLE() is not affected by "if". So 
even when you write:
  162   if test "x$TOOLCHAIN_TYPE" = "xgcc" -o "x$TOOLCHAIN_TYPE" = 
"xclang"; then
  163     AC_ARG_ENABLE([ccache],
  164         [AS_HELP_STRING([--enable-ccache],
  165         [enable using ccache to speed up recompilations 
@<:@disabled@:>@])])

the argument --enable-ccache is available for all toolchains. This is a 
good thing, since we don't want to make options becoming unknown (and 
thus fail) depending on circumstances. However, this behavior cannot be 
deduced from the code, where it looks like it is conditional.

A better pattern is something like this:
AC_DEFUN([HANDLE_MY_OPT]), ([
   # Always start by declaring the option
   AC_ARG_ENABLE([myopt], ...)

   if test SUPPORTED_PLATFORM; then
    # .. handle option
   else
     AC_MSG_WARN([--myopt is ignored on this platform])
    # or ERROR if more appropriate
   fi
])


Also, you now sets
CCACHE_SLOPPINESS=pch_defines,time_macros
only if -fpch-preprocess works with the compiler. But if it don't, you 
should probably set
CCACHE_SLOPPINESS=time_macros
to keep the old behavior. Unless time_macros makes no sense if not 
-fpch-preprocess is enabled?

Otherwise it looks good!

/Magnus

>
> I changed the test for ccache version to explicitly check for known 
> older versions that we don't want to use with precompiled headers. The 
> test is only done if precompiled headers are enabled, since without 
> precompiled headers, we don't know of any issues with ccache.
>
> I fixed the ccache options needed to fully function with precompiled 
> headers in hotspot. These options will now be used if precompiled 
> headers are enabled. They currently aren't fully used.
>
> I updated the documentation to reflect our current stance on ccache.
>
> As noted in JDK-8014074, ccache works better without precompiled 
> headers, so I recommend turning it off when using ccache. (I actually 
> recommend turning it off on linux regardless.)
>
> Some numbers building just hotspot ("make hotspot") from my machine 
> (E5-2665 @ 2.4GHz, 16 cores + HT) with JOBS=15 which is default:
>
> Product/release with precompiled headers
> no ccache: 03:13
> empty cache: 03:37
> perfect cache: 01:36
>
> Product/release without precompiled headers
> no ccache: 02:35
> empty cache: 02:43
> perfect cache: 01:04
>
> /Erik



From magnus.ihse.bursie at oracle.com  Fri Jan 30 10:35:57 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 30 Jan 2015 11:35:57 +0100
Subject: [OpenJDK 2D-Dev] RFR: 8071710: [solaris] libfontmanager should
	be linked against headless awt library
In-Reply-To: <54C932AA.7040701@oracle.com>
References: <54C801F9.1050005@oracle.com> <54C8E0EF.2010107@oracle.com>
	<54C932AA.7040701@oracle.com>
Message-ID: <54CB5E8D.3030601@oracle.com>

On 2015-01-28 20:04, Phil Race wrote:
> I have updated both the patches to add the dependency that headless awt
> must be built first and also corrected that AIX should be given the 
> same treatment
> as Solaris in both releases :
> jdk9: http://cr.openjdk.java.net/~prr/8071710.1/
> jdk8u: http://cr.openjdk.java.net/~prr/8071710.8u.1/

Looks good to me.

/Magnus



From erik.joelsson at oracle.com  Fri Jan 30 10:38:03 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 30 Jan 2015 11:38:03 +0100
Subject: RFR: JDK-8062223: Upgrading to ccache 1.3.10 disables the use
	of ccache
In-Reply-To: <54CB5BC7.5020106@oracle.com>
References: <54C7914B.1050408@oracle.com> <54CB5BC7.5020106@oracle.com>
Message-ID: <54CB5F0B.3090004@oracle.com>


On 2015-01-30 11:24, Magnus Ihse Bursie wrote:
> On 2015-01-27 14:23, Erik Joelsson wrote:
>> Hello,
>>
>> Please review this fix cleaning up the ccache setup in configure. 
>> This patch addresses the concerns in the following bugs:
>> https://bugs.openjdk.java.net/browse/JDK-8065791
>> https://bugs.openjdk.java.net/browse/JDK-8014074
>> https://bugs.openjdk.java.net/browse/JDK-8062223
>>
>> Webrev: http://cr.openjdk.java.net/~erikj/8062223/webrev.root.01/
>
> I would prefer if you rewrote the code in build-performance.m4 slightly.
>
> We have an anti-pattern that's unfortunately too common in our 
> autoconf scripts, but I'm trying to eradicate it. :-)
>
> The thing to note is that AC_ARG_ENABLE() is not affected by "if". So 
> even when you write:
>  162   if test "x$TOOLCHAIN_TYPE" = "xgcc" -o "x$TOOLCHAIN_TYPE" = 
> "xclang"; then
>  163     AC_ARG_ENABLE([ccache],
>  164         [AS_HELP_STRING([--enable-ccache],
>  165         [enable using ccache to speed up recompilations 
> @<:@disabled@:>@])])
>
> the argument --enable-ccache is available for all toolchains. This is 
> a good thing, since we don't want to make options becoming unknown 
> (and thus fail) depending on circumstances. However, this behavior 
> cannot be deduced from the code, where it looks like it is conditional.
>
> A better pattern is something like this:
> AC_DEFUN([HANDLE_MY_OPT]), ([
>   # Always start by declaring the option
>   AC_ARG_ENABLE([myopt], ...)
>
>   if test SUPPORTED_PLATFORM; then
>    # .. handle option
>   else
>     AC_MSG_WARN([--myopt is ignored on this platform])
>    # or ERROR if more appropriate
>   fi
> ])
>
Right, that should be fixed.
>
> Also, you now sets
> CCACHE_SLOPPINESS=pch_defines,time_macros
> only if -fpch-preprocess works with the compiler. But if it don't, you 
> should probably set
> CCACHE_SLOPPINESS=time_macros
> to keep the old behavior. Unless time_macros makes no sense if not 
> -fpch-preprocess is enabled?
>
time_macros was set only for precompiled headers. With newer versions of 
ccache you also need to set pch_defines. There is no need for either if 
not using precompiled headers.

/Erik
> Otherwise it looks good!
>
> /Magnus
>
>>
>> I changed the test for ccache version to explicitly check for known 
>> older versions that we don't want to use with precompiled headers. 
>> The test is only done if precompiled headers are enabled, since 
>> without precompiled headers, we don't know of any issues with ccache.
>>
>> I fixed the ccache options needed to fully function with precompiled 
>> headers in hotspot. These options will now be used if precompiled 
>> headers are enabled. They currently aren't fully used.
>>
>> I updated the documentation to reflect our current stance on ccache.
>>
>> As noted in JDK-8014074, ccache works better without precompiled 
>> headers, so I recommend turning it off when using ccache. (I actually 
>> recommend turning it off on linux regardless.)
>>
>> Some numbers building just hotspot ("make hotspot") from my machine 
>> (E5-2665 @ 2.4GHz, 16 cores + HT) with JOBS=15 which is default:
>>
>> Product/release with precompiled headers
>> no ccache: 03:13
>> empty cache: 03:37
>> perfect cache: 01:36
>>
>> Product/release without precompiled headers
>> no ccache: 02:35
>> empty cache: 02:43
>> perfect cache: 01:04
>>
>> /Erik
>



From magnus.ihse.bursie at oracle.com  Fri Jan 30 10:42:44 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 30 Jan 2015 11:42:44 +0100
Subject: Building open jdk 8 from source fails
In-Reply-To: <CAG6=6-Rzm0aJ1njyqQLqhNNNvCS96QzVzQwUpJeawZmLkUpcjA@mail.gmail.com>
References: <CAG6=6-TO7FU4diVNjT5CUUvMZEbMbfhNQx1wdAwpRL-WS5sA7w@mail.gmail.com>	<CA+3eh11xjb2wR0sOYuUhXxM9NrfsXyfZQ6DhX=Whd1CYh8ucqg@mail.gmail.com>	<CAG6=6-QP0UkDkCPV+wkJVf3FXwm5Eryeioth8tMw8RCANbC1Ew@mail.gmail.com>	<54C23AA3.3050708@oracle.com>	<CAG6=6-SVmMO+Dbv2hycfhMZtX+2jxTxvMQsX58Sm7SDZa5Bc9A@mail.gmail.com>	<54C79405.30703@oracle.com>
	<CAG6=6-Rzm0aJ1njyqQLqhNNNvCS96QzVzQwUpJeawZmLkUpcjA@mail.gmail.com>
Message-ID: <54CB6024.8050501@oracle.com>

On 2015-01-28 05:20, lee json wrote:
> dist clean and configure (with boot jdk) look correct. But really no
> luck when executing make

I'm sorry, but I can't help you any further. Maybe someone in the 
langtools team recognize the error and know what can cause it?

/Magnus



From erik.joelsson at oracle.com  Fri Jan 30 10:51:09 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 30 Jan 2015 11:51:09 +0100
Subject: RFR: JDK-8062223: Upgrading to ccache 1.3.10 disables the use
	of ccache
In-Reply-To: <54CB5F0B.3090004@oracle.com>
References: <54C7914B.1050408@oracle.com> <54CB5BC7.5020106@oracle.com>
	<54CB5F0B.3090004@oracle.com>
Message-ID: <54CB621D.5090405@oracle.com>

Hello,

New webrev: http://cr.openjdk.java.net/~erikj/8062223/webrev.root.02/

Fixed the anti pattern. Also made it a fatal error to try to use ccache 
if the compiler does not support the option as it's unclear if it really 
works correctly then. On the other hand, that option has been around for 
a long time so it will never fail.

/Erik

On 2015-01-30 11:38, Erik Joelsson wrote:
>
> On 2015-01-30 11:24, Magnus Ihse Bursie wrote:
>> On 2015-01-27 14:23, Erik Joelsson wrote:
>>> Hello,
>>>
>>> Please review this fix cleaning up the ccache setup in configure. 
>>> This patch addresses the concerns in the following bugs:
>>> https://bugs.openjdk.java.net/browse/JDK-8065791
>>> https://bugs.openjdk.java.net/browse/JDK-8014074
>>> https://bugs.openjdk.java.net/browse/JDK-8062223
>>>
>>> Webrev: http://cr.openjdk.java.net/~erikj/8062223/webrev.root.01/
>>
>> I would prefer if you rewrote the code in build-performance.m4 slightly.
>>
>> We have an anti-pattern that's unfortunately too common in our 
>> autoconf scripts, but I'm trying to eradicate it. :-)
>>
>> The thing to note is that AC_ARG_ENABLE() is not affected by "if". So 
>> even when you write:
>>  162   if test "x$TOOLCHAIN_TYPE" = "xgcc" -o "x$TOOLCHAIN_TYPE" = 
>> "xclang"; then
>>  163     AC_ARG_ENABLE([ccache],
>>  164         [AS_HELP_STRING([--enable-ccache],
>>  165         [enable using ccache to speed up recompilations 
>> @<:@disabled@:>@])])
>>
>> the argument --enable-ccache is available for all toolchains. This is 
>> a good thing, since we don't want to make options becoming unknown 
>> (and thus fail) depending on circumstances. However, this behavior 
>> cannot be deduced from the code, where it looks like it is conditional.
>>
>> A better pattern is something like this:
>> AC_DEFUN([HANDLE_MY_OPT]), ([
>>   # Always start by declaring the option
>>   AC_ARG_ENABLE([myopt], ...)
>>
>>   if test SUPPORTED_PLATFORM; then
>>    # .. handle option
>>   else
>>     AC_MSG_WARN([--myopt is ignored on this platform])
>>    # or ERROR if more appropriate
>>   fi
>> ])
>>
> Right, that should be fixed.
>>
>> Also, you now sets
>> CCACHE_SLOPPINESS=pch_defines,time_macros
>> only if -fpch-preprocess works with the compiler. But if it don't, 
>> you should probably set
>> CCACHE_SLOPPINESS=time_macros
>> to keep the old behavior. Unless time_macros makes no sense if not 
>> -fpch-preprocess is enabled?
>>
> time_macros was set only for precompiled headers. With newer versions 
> of ccache you also need to set pch_defines. There is no need for 
> either if not using precompiled headers.
>
> /Erik
>> Otherwise it looks good!
>>
>> /Magnus
>>
>>>
>>> I changed the test for ccache version to explicitly check for known 
>>> older versions that we don't want to use with precompiled headers. 
>>> The test is only done if precompiled headers are enabled, since 
>>> without precompiled headers, we don't know of any issues with ccache.
>>>
>>> I fixed the ccache options needed to fully function with precompiled 
>>> headers in hotspot. These options will now be used if precompiled 
>>> headers are enabled. They currently aren't fully used.
>>>
>>> I updated the documentation to reflect our current stance on ccache.
>>>
>>> As noted in JDK-8014074, ccache works better without precompiled 
>>> headers, so I recommend turning it off when using ccache. (I 
>>> actually recommend turning it off on linux regardless.)
>>>
>>> Some numbers building just hotspot ("make hotspot") from my machine 
>>> (E5-2665 @ 2.4GHz, 16 cores + HT) with JOBS=15 which is default:
>>>
>>> Product/release with precompiled headers
>>> no ccache: 03:13
>>> empty cache: 03:37
>>> perfect cache: 01:36
>>>
>>> Product/release without precompiled headers
>>> no ccache: 02:35
>>> empty cache: 02:43
>>> perfect cache: 01:04
>>>
>>> /Erik
>>
>



From magnus.ihse.bursie at oracle.com  Fri Jan 30 11:01:37 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 30 Jan 2015 12:01:37 +0100
Subject: RFR: JDK-8062223: Upgrading to ccache 1.3.10 disables the use
	of ccache
In-Reply-To: <54CB621D.5090405@oracle.com>
References: <54C7914B.1050408@oracle.com> <54CB5BC7.5020106@oracle.com>
	<54CB5F0B.3090004@oracle.com> <54CB621D.5090405@oracle.com>
Message-ID: <54CB6491.5050001@oracle.com>

On 2015-01-30 11:51, Erik Joelsson wrote:
> Hello,
>
> New webrev: http://cr.openjdk.java.net/~erikj/8062223/webrev.root.02/
>
> Fixed the anti pattern.

Sort of. :-) You still ignore the flag silently if it is not supported. 
I would prefer if a AC_MSG_WARN or AC_MSG_NOTICE in that case. If the 
user has explicitely given an argument, I think they deserves to know 
that is was to no effect. But then again, that's no regression so I 
accept if you will not fix it now.

> Also made it a fatal error to try to use ccache if the compiler does 
> not support the option as it's unclear if it really works correctly 
> then. On the other hand, that option has been around for a long time 
> so it will never fail.
Sounds good.

/Magnus


From david.holmes at oracle.com  Fri Jan 30 11:02:40 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 30 Jan 2015 21:02:40 +1000
Subject: OpenJDK 8 build fails on Ubuntu 12.04.5 LTS
In-Reply-To: <CAAt5ms8qBuws7+VCQ+c=tGA87x5O-i3_H_SiBCqFHa_OtDPbjQ@mail.gmail.com>
References: <CAAt5ms8tS1bw2ARy--qMko4RGanw8RH6fVsADzuNqzPwURTU_A@mail.gmail.com>	<54CA9FFC.6030806@oracle.com>	<CAAt5ms88oz+HV1GQnGO9w4XfOPoyJZ_aYZxofyMBP7g2P0_30A@mail.gmail.com>	<54CAF6F2.5090603@oracle.com>
	<CAAt5ms8qBuws7+VCQ+c=tGA87x5O-i3_H_SiBCqFHa_OtDPbjQ@mail.gmail.com>
Message-ID: <54CB64D0.2040506@oracle.com>

Have you tried getting rid of the other warning:

ALT_BOOTDIR=/usr/lib/jvm/java-7-openjdk-amd64

David

On 30/01/2015 7:42 PM, matchew wrote:
> I have rebuilt everything from the scratch and still have this error.
> Here is configure summary:
>
> ====================================================
> A new configuration has been successfully created in
> /opt/openjdk/8/build/linux-x86_64-normal-server-release
> using configure arguments
> '--with-cacerts-file=/etc/ssl/certs/java/cacerts
> --with-boot-jdk=/usr/lib/jvm/java-7-openjdk-amd64
> --with-build-number=jdk8u31-b13 --with-update-version=jdk8u31-b13'.
>
> Configuration summary:
> * Debug level:    release
> * JDK variant:    normal
> * JVM variants:   server
> * OpenJDK target: OS: linux, CPU architecture: x86, address length: 64
>
> Tools summary:
> * Boot JDK:       java version "1.7.0_65" OpenJDK Runtime Environment
> (IcedTea 2.5.3) (7u71-2.5.3-0ubuntu0.12.04.1) OpenJDK 64-Bit Server VM
> (build 24.65-b04, mixed mode)  (at /usr/lib/jvm/java-7-openjdk-amd64)
> * C Compiler:     gcc-4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5) version 4.6.3
> (at /usr/bin/gcc-4.6)
> * C++ Compiler:   g++-4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5) version 4.6.3
> (at /usr/bin/g++-4.6)
>
> Build performance summary:
> * Cores to use:   1
> * Memory limit:   3750 MB
> * ccache status:  not installed (consider installing)
>
> Build performance tip: ccache gives a tremendous speedup for C++
> recompilations.
> You do not have ccache installed. Try installing it.
> You might be able to fix this by running 'sudo apt-get install ccache'.
>
> WARNING: You have old-style ALT_ environment variables set.
> These are not respected, and will be ignored. It is recommended
> that you clean your environment. The following variables are set:
> ALT_BOOTDIR=/usr/lib/jvm/java-7-openjdk-amd64
> ALT_CACERTS_FILE=/etc/ssl/certs/java/cacerts
>
>
> WARNING: You have the following ALT_ variables set:
> ALT_CACERTS_FILE=/etc/ssl/certs/java/cacerts
> ALT_BOOTDIR=/usr/lib/jvm/java-7-openjdk-amd64
> ALT_ variables are deprecated and will be ignored. Please clean your
> environment.
>
> Building OpenJDK for target 'all' in configuration
> 'linux-x86_64-normal-server-release'
>
> 2015-01-30 4:13 GMT+01:00 David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>>:
>
>     Did you try removing the existing configuration and generating it
>     cleanly as the warning suggested?
>
>     David
>
>
>     On 30/01/2015 8:03 AM, matchew wrote:
>
>         No, configure was successful. Here is the summary:
>
>         ==============================__======================
>         A new configuration has been successfully created in
>         /opt/openjdk/8/build/linux-__x86_64-normal-server-release
>         using configure arguments
>         '--with-cacerts-file=/etc/ssl/__certs/java/cacerts
>         --with-boot-jdk=/usr/lib/jvm/__java-7-openjdk-amd64'.
>
>         Configuration summary:
>         * Debug level:    release
>         * JDK variant:    normal
>         * JVM variants:   server
>         * OpenJDK target: OS: linux, CPU architecture: x86, address
>         length: 64
>
>         Tools summary:
>         * Boot JDK:       java version "1.7.0_65" OpenJDK Runtime
>         Environment
>         (IcedTea 2.5.3) (7u71-2.5.3-0ubuntu0.12.04.1) OpenJDK 64-Bit
>         Server VM
>         (build 24.65-b04, mixed mode)  (at
>         /usr/lib/jvm/java-7-openjdk-__amd64)
>         * C Compiler:     gcc-4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5) version
>         4.6.3 (at
>         /usr/bin/gcc-4.6)
>         * C++ Compiler:   g++-4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5) version
>         4.6.3 (at
>         /usr/bin/g++-4.6)
>
>         Build performance summary:
>         * Cores to use:   1
>         * Memory limit:   3750 MB
>         * ccache status:  not installed (consider installing)
>
>         WARNING: You have old-style ALT_ environment variables set.
>         These are not respected, and will be ignored. It is recommended
>         that you clean your environment. The following variables are set:
>         ALT_BOOTDIR=/usr/lib/jvm/java-__7-openjdk-amd64
>         ALT_CACERTS_FILE=/etc/ssl/__certs/java/cacerts
>
>         WARNING: The result of this configuration has overridden an older
>         configuration. You *should* run 'make clean' to make sure you get a
>         proper build. Failure to do so might result in strange build
>         problems.
>
>         In the past I was using http://hg.openjdk.java.net/__jdk8/jdk8
>         <http://hg.openjdk.java.net/jdk8/jdk8> but recently
>         switched to http://hg.openjdk.java.net/__jdk8u/jdk8u
>         <http://hg.openjdk.java.net/jdk8u/jdk8u> and faced above problems.
>
>         2015-01-29 22:02 GMT+01:00 Magnus Ihse Bursie
>         <magnus.ihse.bursie at oracle.com
>         <mailto:magnus.ihse.bursie at oracle.com>
>
>             :
>
>
>             On 2015-01-29 16:47, matchew wrote:
>
>                 When it comes to JDK compilation (i am executing *make
>                 all*) I am getting
>                 this error:
>
>                 ## Starting jdk
>                 Compiling 162 files for BUILD_TOOLS
>                 /bin/sh: 1:
>                 -Xbootclasspath/p:/opt/__openjdk/8/build/linux-x86_64-
>                 normal-server-release/__langtools/dist/bootstrap/lib/__javac.jar:
>                 not found
>                 make[2]: ***
>                 [/opt/openjdk/8/build/linux-__x86_64-normal-server-release/
>                 jdk/btclasses/_the.BUILD___TOOLS_batch]
>                 Error 127
>                 make[1]: *** [gensrc-only] Error 2
>                 make: *** [jdk-only] Error 2
>
>                 Which is strange because file
>                 /opt/openjdk/8/build/linux-__x86_64-normal-server-release/
>                 langtools/dist/bootstrap/lib/__javac.jar
>                     exists.
>
>
>             The command line was supposed to look something like this
>             /usr/bin/java
>             -Xbootclasspath/p:/opt/__openjdk/8/build/linux-x86_64-
>             normal-server-release/__langtools/dist/bootstrap/lib/__javac.jar
>             ...
>             but the executable java is missing.  Thus the shell tries to
>             execute
>             -Xbootclasspath... but that is not a valid executable.
>
>             Most likely, your spec.gmk is broken somehow, and $(JAVA)
>             expands to
>             nothing.
>
>             Did you get any error messages when running configure?
>
>             /Magnus
>
>


From mkorszun at gmail.com  Fri Jan 30 12:47:10 2015
From: mkorszun at gmail.com (matchew)
Date: Fri, 30 Jan 2015 13:47:10 +0100
Subject: OpenJDK 8 build fails on Ubuntu 12.04.5 LTS
In-Reply-To: <54CB5FD9.2060502@oracle.com>
References: <CAAt5ms8tS1bw2ARy--qMko4RGanw8RH6fVsADzuNqzPwURTU_A@mail.gmail.com>
	<54CA9FFC.6030806@oracle.com>
	<CAAt5ms88oz+HV1GQnGO9w4XfOPoyJZ_aYZxofyMBP7g2P0_30A@mail.gmail.com>
	<54CAD6EB.20305@oracle.com>
	<CAAt5ms_bocSubQCGKVbtX33K2zHkSu2KfVM5wiReptk-C=7DbA@mail.gmail.com>
	<54CB5FD9.2060502@oracle.com>
Message-ID: <CAAt5ms9XKrjBcnYzd9sHRSUmmmop2HsFZPDYAwFfdkG-1FWBFA@mail.gmail.com>

Do I need to set JAVA and JAVAC explicitly? What should be the values here?

2015-01-30 11:41 GMT+01:00 Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com
>:

>  On 2015-01-30 10:40, matchew wrote:
>
>  $ grep JAVA
> /opt/openjdk/8/build/linux-x86_64-normal-server-release/spec.gmk
> ENABLE_SJAVAC:=no
> SJAVAC_SERVER_DIR:=
> JAVA_FLAGS:= -Xms64M -Xmx1100M -XX:PermSize=32m -XX:MaxPermSize=160m
> -XX:ThreadStackSize=1536
> JAVA= $(BOOT_JDK)/bin/java $(JAVA_FLAGS)
> JAVAC= $(BOOT_JDK)/bin/javac
> JAVAC_FLAGS?=
> JAVAH= $(BOOT_JDK)/bin/javah
> # You run the new javac using the boot jdk with $(BOOT_JDK)/bin/java
> $(NEW_JAVAC) ...
> BOOTSTRAP_JAVAC_JAR:=$(LANGTOOLS_OUTPUTDIR)/dist/bootstrap/lib/javac.jar
> BOOTSTRAP_JAVAC_ARGS:="-Xbootclasspath/p:$(BOOTSTRAP_JAVAC_JAR)" -cp
> $(BOOTSTRAP_JAVAC_JAR)
> NEW_JAVAC   = $(BOOTSTRAP_JAVAC_ARGS) com.sun.tools.javac.Main
> NEW_JAVADOC = $(BOOTSTRAP_JAVAC_ARGS) com.sun.tools.javadoc.Main
> SJAVAC_SERVER_JAVA:= /usr/lib/jvm/java-7-openjdk-amd64/bin/java
>  -verbosegc -d64 -Xms1000M -Xmx1500M
>
>  Yes, I did fresh clone from http://hg.openjdk.java.net/jdk8u/jdk8u but I
> am using the same build script/procedure I was using before and it was
> totally fine with last tag from http://hg.openjdk.java.net/jdk8/jdk8.
>
>
> That is *really* weird. I'm sorry I can't provide much more assistance at
> this point. Some suggestions:
> * Try removing the ALT_ variables as the warnings suggests. I don't
> believe they should interfere but the problem lies with the boot jdk so the
> ALT_BOOTDIR is a suspect.
> * Check your environment. Do you have JAVA or JAVAC set there?
> * Try running with LOG=debug and see if you can figure out what command
> line is being run and why.
> * If that does not help, running with LOG=trace produces even more logging
> on how make builds the command lines.
> * Both of the logging suggestions above is easier to handle if you first
> figure out a minimal target that reproduces the problem. Perhaps
> "langtools-only"?
>
> /Magnus
>


From magnus.ihse.bursie at oracle.com  Fri Jan 30 15:04:34 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 30 Jan 2015 16:04:34 +0100
Subject: OpenJDK 8 build fails on Ubuntu 12.04.5 LTS
In-Reply-To: <CAAt5ms9XKrjBcnYzd9sHRSUmmmop2HsFZPDYAwFfdkG-1FWBFA@mail.gmail.com>
References: <CAAt5ms8tS1bw2ARy--qMko4RGanw8RH6fVsADzuNqzPwURTU_A@mail.gmail.com>
	<54CA9FFC.6030806@oracle.com>
	<CAAt5ms88oz+HV1GQnGO9w4XfOPoyJZ_aYZxofyMBP7g2P0_30A@mail.gmail.com>
	<54CAD6EB.20305@oracle.com>
	<CAAt5ms_bocSubQCGKVbtX33K2zHkSu2KfVM5wiReptk-C=7DbA@mail.gmail.com>
	<54CB5FD9.2060502@oracle.com>
	<CAAt5ms9XKrjBcnYzd9sHRSUmmmop2HsFZPDYAwFfdkG-1FWBFA@mail.gmail.com>
Message-ID: <E0BD8FB6-013C-4CB3-8653-071579695A1A@oracle.com>



> 30 jan 2015 kl. 13:47 skrev matchew <mkorszun at gmail.com>:
> 
> Do I need to set JAVA and JAVAC explicitly? What should be the values here?

No, on the contrary, the failure could perhaps be caused by having them defined. 

/Magnus
> 
> 2015-01-30 11:41 GMT+01:00 Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>:
>>> On 2015-01-30 10:40, matchew wrote:
>>> $ grep JAVA /opt/openjdk/8/build/linux-x86_64-normal-server-release/spec.gmk
>>> ENABLE_SJAVAC:=no
>>> SJAVAC_SERVER_DIR:=
>>> JAVA_FLAGS:= -Xms64M -Xmx1100M -XX:PermSize=32m -XX:MaxPermSize=160m -XX:ThreadStackSize=1536
>>> JAVA= $(BOOT_JDK)/bin/java $(JAVA_FLAGS)
>>> JAVAC= $(BOOT_JDK)/bin/javac
>>> JAVAC_FLAGS?=
>>> JAVAH= $(BOOT_JDK)/bin/javah
>>> # You run the new javac using the boot jdk with $(BOOT_JDK)/bin/java $(NEW_JAVAC) ...
>>> BOOTSTRAP_JAVAC_JAR:=$(LANGTOOLS_OUTPUTDIR)/dist/bootstrap/lib/javac.jar
>>> BOOTSTRAP_JAVAC_ARGS:="-Xbootclasspath/p:$(BOOTSTRAP_JAVAC_JAR)" -cp $(BOOTSTRAP_JAVAC_JAR)
>>> NEW_JAVAC   = $(BOOTSTRAP_JAVAC_ARGS) com.sun.tools.javac.Main
>>> NEW_JAVADOC = $(BOOTSTRAP_JAVAC_ARGS) com.sun.tools.javadoc.Main
>>> SJAVAC_SERVER_JAVA:= /usr/lib/jvm/java-7-openjdk-amd64/bin/java  -verbosegc -d64 -Xms1000M -Xmx1500M
>>> 
>>> Yes, I did fresh clone from http://hg.openjdk.java.net/jdk8u/jdk8u but I am using the same build script/procedure I was using before and it was totally fine with last tag from http://hg.openjdk.java.net/jdk8/jdk8.
>> 
>> That is *really* weird. I'm sorry I can't provide much more assistance at this point. Some suggestions:
>> * Try removing the ALT_ variables as the warnings suggests. I don't believe they should interfere but the problem lies with the boot jdk so the ALT_BOOTDIR is a suspect.
>> * Check your environment. Do you have JAVA or JAVAC set there?
>> * Try running with LOG=debug and see if you can figure out what command line is being run and why.
>> * If that does not help, running with LOG=trace produces even more logging on how make builds the command lines.
>> * Both of the logging suggestions above is easier to handle if you first figure out a minimal target that reproduces the problem. Perhaps "langtools-only"?
>> 
>> /Magnus
> 


From richard.marks at oracle.com  Wed Jan 21 23:44:46 2015
From: richard.marks at oracle.com (Richard Marks)
Date: Wed, 21 Jan 2015 23:44:46 -0000
Subject: JDK9 Jake build using Xbootclasspath/p
Message-ID: <54C039DE.3040004@oracle.com>

Hi Build Team,

Mandy suggested I email to build-dev to ask questions about the jdk9 
build/makefile issues I may have with Parfait integration.

Parfait requires the build to be done with the boot jdk as the same 
version, and at the moment Jake with a Jake boot fails with an error 
message stating bootclasspath/p deprecated.  I have a work around for 
myself so I can get the build going and work on the parfait components.

Can you please tell me when they are expected to be removed, so I can 
know how long I will have to have the workaround in our code base?

Cheers
Richard Marks
Parfait Development Team.