Re: RFR(XS) 8161915: Linking gtestLauncher may end up linking with non-gtest libjvm

[David Holmes]

Hi Mikael,

On 20/07/2016 11:54 PM, Mikael Gerdin wrote:

Hi all,

Please review this small fix to work around a problem where incremental
builds of hotspot would fail due to the symbol runUnitTests missing.

The cause for the problem is that the unit tests launcher linker command
line contains a -L path containing the standard libjvm.so
 [10] LDFLAGS := -Wl,-z,defs -Wl,-z,now -Wl,-z,relro
-Wl,--allow-shlib-undefined
-L/home/mgerdin/work/repos/hg/jdk9/hs-rt-work/build/linux-x64-slowdebug/support/modules_libs/java.base/amd64
-L/home/mgerdin/work/repos/hg/jdk9/hs-rt-work/build/linux-x64-slowdebug/support/modules_libs/java.base/amd64/server

 [11] LDFLAGS_unix :=
-L/home/mgerdin/work/repos/hg/jdk9/hs-rt-work/build/linux-x64-slowdebug/hotspot/variant-server/libjvm/gtest
-Wl,-z,origin -Wl,-rpath,\$$ORIGIN
 [13] LIBS_unix := -ljvm

This is caused by BUILD_GTEST_LAUNCHER picking up LDFLAGS_TESTEXE which
was recently modified to include -L path to the standard libjvm.so

My suggested fix is to instead use LDFLAGS_JDKEXE for the gtest launcher
since the only difference between them is that TESTEXE appends
JAVA_BASE_LDFLAGS:
flags.m4, 687:  LDFLAGS_TESTEXE="$LDFLAGS_JDKEXE $JAVA_BASE_LDFLAGS"

Since the fix is only one line, I'll paste it inline here:
diff --git a/make/lib/CompileGtest.gmk b/make/lib/CompileGtest.gmk
--- a/make/lib/CompileGtest.gmk
+++ b/make/lib/CompileGtest.gmk
@@ -104,7 +104,7 @@
 -I$(GTEST_FRAMEWORK_SRC)/include, \
 CFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \
 CXXFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \
-LDFLAGS := $(LDFLAGS_TESTEXE), \
+LDFLAGS := $(LDFLAGS_JDKEXE), \
 LDFLAGS_unix := -L$(JVM_OUTPUTDIR)/gtest $(call
SET_SHARED_LIBRARY_ORIGIN), \
 LDFLAGS_solaris := -library=stlport4, \
 LIBS_unix := -ljvm, \


This seems like a reasonable solution at least in the short-term. It may 
be that gtest launcher needs it own compiler/linker options independent 
of other "executables" in the build.


Thanks,
David




Testing: JPRT -testset hotspot
Bug link: https://bugs.openjdk.java.net/browse/JDK-8161915

Please let me know if there is any further testing I should do before
pushing this.

Thanks
/Mikael

Re: [9] RFR: 8160873: (cs) JDK9 Build failure on Hindi locale

[Tim Bell]

On 07/20/16 17:48, Naoto Sato wrote:

Thanks for the review Tim!

On 7/20/16 5:40 PM, Tim Bell wrote:

Naoto:


Please review the fix to the following issue:

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

The proposed fix is located at:

http://cr.openjdk.java.net/~naoto/8160873/webrev.01/

The gist of the issue is that those tools used to generate sources at
build time were affected by the default locale, and if they use some
number formatting functions, the results end up including locale
dependent digits. The fix is to force tools to run in en-US locale by
providing user.language/country properties to bootjdk arguments.


Looks good to me.

It is already common practice for the build to set:

  LC_ALL=C
  export LC_ALL


That works fine on Solaris/Linux platoforms, but for Windows/Linux, 
Java's default locale is determined from the 
ControlPanel/SystemPreferences user settings, thus those system 
properties need to be set.


Even better, in that case.  Approved-

Tim

Re: [9] RFR: 8160873: (cs) JDK9 Build failure on Hindi locale

[Naoto Sato]

Thanks for the review Tim!

On 7/20/16 5:40 PM, Tim Bell wrote:

Naoto:


Please review the fix to the following issue:

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

The proposed fix is located at:

http://cr.openjdk.java.net/~naoto/8160873/webrev.01/

The gist of the issue is that those tools used to generate sources at
build time were affected by the default locale, and if they use some
number formatting functions, the results end up including locale
dependent digits. The fix is to force tools to run in en-US locale by
providing user.language/country properties to bootjdk arguments.


Looks good to me.

It is already common practice for the build to set:

  LC_ALL=C
  export LC_ALL


That works fine on Solaris/Linux platoforms, but for Windows/Linux, 
Java's default locale is determined from the 
ControlPanel/SystemPreferences user settings, thus those system 
properties need to be set.


Naoto

Re: [9] RFR: 8160873: (cs) JDK9 Build failure on Hindi locale

[Tim Bell]

Naoto:


Please review the fix to the following issue:

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

The proposed fix is located at:

http://cr.openjdk.java.net/~naoto/8160873/webrev.01/

The gist of the issue is that those tools used to generate sources at 
build time were affected by the default locale, and if they use some 
number formatting functions, the results end up including locale 
dependent digits. The fix is to force tools to run in en-US locale by 
providing user.language/country properties to bootjdk arguments.


Looks good to me.

It is already common practice for the build to set:

  LC_ALL=C
  export LC_ALL

Tim

Problem running configure on El Capitan

[Lance Andersen]

Hi,

Has there been any changes to the build requirements recently as I am getting 
the error:

——
configure: error: Could not find freetype!  
/Users/ljanders/Documents/hg-workspaces/openjdk9/javadoc-mod/common/autoconf/generated-configure.sh:
 line 82: 5: Bad file descriptor
configure exiting with result code 1


I have not seen this before

Best
Lance

 
  

 Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com 

Cloning issues anyone seeing them?

[Lance Andersen]

Hi all,

Seeing issues with a openjdk9 clone today


source get_source.sh 
WARNING: Mercurial version 2.6.3 or later is recommended. /usr/local/bin/hg is 
version 2.2
# Repositories:  langtools 
langtools:   hg clone http://hg.openjdk.java.net/jdk9/dev/langtools 
langtools
langtools:   requesting all changes
langtools:   adding changesets
langtools:   adding manifests
langtools:   adding file changes
langtools:   transaction abort!
langtools:   rollback completed
langtools:   abort: stream ended unexpectedly (got 2032 bytes, 
expected 4304)
WARNING: langtools exited abnormally (255)
Saving session...
...copying shared history...
...saving history...truncating history files...
...completed.

[Process completed]

—

I have experienced the above occasionally  before but now it is also killing 
the terminal process which it never used to do…

This is on el Capitan

Anyone else having this experience?

Best
Lance


 
  

 Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com 

Re: RFR: JDK-8161057 Solaris: deprecated/obsolete compiler flags should be removed

[Alan Burlison]

On 20/07/2016 18:11, Daniel D. Daugherty wrote:


We have three reviewers on this changeset. We don't have a review
from a current Serviceability team member, but I think Tim and I
can be considered as sufficient review since we're both former
Serviceability team members. :-)

Alan, please confirm that this is good to go.

This change is applied in the repo I have setup for this change:

 > jdk/src/demo/share/jvmti/java_crw_demo/sample.makefile.txt
 >Copyright year updated to '2015' instead of '2016'.


Yes, it is good to go, as a belt-and-braces I've sent you a patch with 
the change above included.


Thanks,

--
Alan Burlison
--

Re: RFR: JDK-8161057 Solaris: deprecated/obsolete compiler flags should be removed

[Daniel D. Daugherty]

We have three reviewers on this changeset. We don't have a review
from a current Serviceability team member, but I think Tim and I
can be considered as sufficient review since we're both former
Serviceability team members. :-)

Alan, please confirm that this is good to go.

This change is applied in the repo I have setup for this change:

> jdk/src/demo/share/jvmti/java_crw_demo/sample.makefile.txt
>Copyright year updated to '2015' instead of '2016'.

Dan

On 7/20/16 10:05 AM, Alan Burlison wrote:

On 20/07/2016 03:17, David Holmes wrote:

There were some JPRT test failures on OSX and Windows, as this 
changeset

doesn't affect those platforms I believe they can be ignored.


If this is with "-testset hotspot" then it shouldn't happen, in that
case please drop me an email pointing to the job. For other testsets,
yes they are transient/intermittent failures.


The "-testset hostpot" run was clean, it was "-testset core" that 
failed, with errors in the same areas that I've seen in other 
unrelated runs.

Re: RFR: JDK-8161057 Solaris: deprecated/obsolete compiler flags should be removed

[Alan Burlison]

On 20/07/2016 03:17, David Holmes wrote:


There were some JPRT test failures on OSX and Windows, as this changeset
doesn't affect those platforms I believe they can be ignored.


If this is with "-testset hotspot" then it shouldn't happen, in that
case please drop me an email pointing to the job. For other testsets,
yes they are transient/intermittent failures.


The "-testset hostpot" run was clean, it was "-testset core" that 
failed, with errors in the same areas that I've seen in other unrelated 
runs.


--
Alan Burlison
--

RFR(XS) 8161915: Linking gtestLauncher may end up linking with non-gtest libjvm

[Mikael Gerdin]

Hi all,

Please review this small fix to work around a problem where incremental 
builds of hotspot would fail due to the symbol runUnitTests missing.


The cause for the problem is that the unit tests launcher linker command 
line contains a -L path containing the standard libjvm.so
 [10] LDFLAGS := -Wl,-z,defs -Wl,-z,now -Wl,-z,relro 
-Wl,--allow-shlib-undefined 
-L/home/mgerdin/work/repos/hg/jdk9/hs-rt-work/build/linux-x64-slowdebug/support/modules_libs/java.base/amd64 
-L/home/mgerdin/work/repos/hg/jdk9/hs-rt-work/build/linux-x64-slowdebug/support/modules_libs/java.base/amd64/server 

 [11] LDFLAGS_unix := 
-L/home/mgerdin/work/repos/hg/jdk9/hs-rt-work/build/linux-x64-slowdebug/hotspot/variant-server/libjvm/gtest 
-Wl,-z,origin -Wl,-rpath,\$$ORIGIN

 [13] LIBS_unix := -ljvm

This is caused by BUILD_GTEST_LAUNCHER picking up LDFLAGS_TESTEXE which 
was recently modified to include -L path to the standard libjvm.so


My suggested fix is to instead use LDFLAGS_JDKEXE for the gtest launcher 
since the only difference between them is that TESTEXE appends 
JAVA_BASE_LDFLAGS:

flags.m4, 687:  LDFLAGS_TESTEXE="$LDFLAGS_JDKEXE $JAVA_BASE_LDFLAGS"

Since the fix is only one line, I'll paste it inline here:
diff --git a/make/lib/CompileGtest.gmk b/make/lib/CompileGtest.gmk
--- a/make/lib/CompileGtest.gmk
+++ b/make/lib/CompileGtest.gmk
@@ -104,7 +104,7 @@
 -I$(GTEST_FRAMEWORK_SRC)/include, \
 CFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \
 CXXFLAGS_DEBUG_SYMBOLS := $(JVM_CFLAGS_SYMBOLS), \
-LDFLAGS := $(LDFLAGS_TESTEXE), \
+LDFLAGS := $(LDFLAGS_JDKEXE), \
 LDFLAGS_unix := -L$(JVM_OUTPUTDIR)/gtest $(call 
SET_SHARED_LIBRARY_ORIGIN), \

 LDFLAGS_solaris := -library=stlport4, \
 LIBS_unix := -ljvm, \


Testing: JPRT -testset hotspot
Bug link: https://bugs.openjdk.java.net/browse/JDK-8161915

Please let me know if there is any further testing I should do before 
pushing this.


Thanks
/Mikael