Re: RFR: JDK-8029942: Update VERSION_MAJOR for JDK 10

[David Holmes]

Hi Erik,

As now discovered the version can't be updated until quite a few changes 
are made in hotspot due to deprecated/obsolete option handling.


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

I would suggest that this bug be taken over by hotspot team (maybe me :) 
) and that everything is pushed to jdk10/dev instead of jdk10/hs so that 
we can get this off the ground.


Thanks,
David

On 26/01/2017 11:56 PM, Erik Joelsson wrote:

The default major version for the jdk 10 repos needs to be updated from
9 to 10.

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

Patch:

diff -r 07f6f1f4140e common/autoconf/version-numbers
--- a/common/autoconf/version-numbers
+++ b/common/autoconf/version-numbers
@@ -25,7 +25,7 @@

 # Default version numbers to use unless overridden by configure

-DEFAULT_VERSION_MAJOR=9
+DEFAULT_VERSION_MAJOR=10
 DEFAULT_VERSION_MINOR=0
 DEFAULT_VERSION_SECURITY=0
 DEFAULT_VERSION_PATCH=0


/Erik

Re: configure - gcc >4.6 needed for JDK9 build

[Mike Burton]

OK so I tried 
 bash configure --with-stdc++lib=dynamic --disable-warnings-as-errors 
--disable-hotspot-gtest
 make clean images

And it worked OK.

Mike


> On 26 Jan 2017, at 17:36, Andrew Haley  wrote:
> 
> On 26/01/17 17:33, Mike Burton wrote:
>> /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a(ctype.o): 
>> relocation R_X86_64_32S against `vtable for std::ctype' can not be 
>> used when making a shared object; recompile with -fPIC
>> /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a: could not read symbols: Bad 
>> value
> 
> Your static libstdc++ has been compiled without -fPIC.  Compiler without 
> static
> libstdc++ and you'll be fine.
> 
> Andrew.
> 

Re: RFR: JDK-8170483: Remove modules_src_jake workaround for JavaFX transition to new module-info syntax

[Mandy Chung]

> On Jan 26, 2017, at 6:36 AM, Erik Joelsson  wrote:
> 
> When the last jake->jdk9 push was done, a temporary workaround for dealing 
> with Javafx was needed. Javafx has now been fully updated to only deliver the 
> new format so the workaround should be removed.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8170483
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8170483/webrev.01/

+1

thanks
Mandy

Re: configure - gcc >4.6 needed for JDK9 build

[Andrew Haley]

On 26/01/17 17:33, Mike Burton wrote:
> /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a(ctype.o): 
> relocation R_X86_64_32S against `vtable for std::ctype' can not be 
> used when making a shared object; recompile with -fPIC
> /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a: could not read symbols: Bad 
> value

Your static libstdc++ has been compiled without -fPIC.  Compiler without static
libstdc++ and you'll be fine.

Andrew.

Re: configure - gcc >4.6 needed for JDK9 build

[Mike Burton]

I get the same error as before, eventually:

1. First of all failed writing to failure-logs/  This seems to happen on every 
clean” build, could it be fixed?
I needed to mkdir -p  
/home/openjdk/dev/jdk9/build/linux-x86_64-normal-server-release/make-support/failure-logs

2. The error from 1. was:
/home/openjdk/dev/jdk9/jdk/src/java.desktop/share/native/libawt/java2d/loops/ProcessPath.c:
 In function 'ProcessPath':
/home/openjdk/dev/jdk9/jdk/src/java.desktop/share/native/libawt/java2d/loops/ProcessPath.c:846:42:
 error: 'params[0]' may be used uninitialized in this function 
[-Werror=uninitialized]
/home/openjdk/dev/jdk9/jdk/src/java.desktop/share/native/libawt/java2d/loops/ProcessPath.c:786:12:
 note: 'params[0]' was declared here
/home/openjdk/dev/jdk9/jdk/src/java.desktop/share/native/libawt/java2d/loops/ProcessPath.c:
 At top level:
cc1: error: unrecognized command line option "-Wno-maybe-uninitialized" 
[-Werror]
cc1: all warnings being treated as errors
make[3]: *** 
[/home/openjdk/dev/jdk9/build/linux-x86_64-normal-server-release/support/native/java.desktop/libawt/ProcessPath.o]
 Error 1
make[2]: *** [java.desktop-libs] Error 1

3. So I tried  `bash configure --disable-warnings-as-errors`  Then `make clean 
images` errored as before:

/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a(ctype.o): relocation 
R_X86_64_32S against `vtable for std::ctype' can not be used when 
making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[3]: *** 
[/home/openjdk/dev/jdk9/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/gtest/libjvm.so]
 Error 1
make[2]: *** [hotspot-server-libs] Error 1

ERROR: Build failed for target 'images' in configuration 
'linux-x86_64-normal-server-release' (exit code 2)

=== Output from failing command(s) repeated here ===
* For target hotspot_variant-server_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link:
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a(ctype.o): relocation 
R_X86_64_32S against `vtable for std::ctype' can not be used when 
making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a: could not read symbols: Bad value

Mike


> On 26 Jan 2017, at 16:00, Erik Joelsson  wrote:
> 
> The option is --disable-hotspot-gtest.
> 
> /Erik
> 
> 
> On 2017-01-26 16:55, Mike Burton wrote:
>> When I do `bash configure —disable-gtest` it errors with:
>> unrecognised options: —disable-gtest
>> 
>> Mike
>> 
>> 
>>> On 26 Jan 2017, at 15:36, Magnus Ihse Bursie 
>>>  wrote:
>>> 
>>> This is an issue with gtest, which is a bit special.
>>> 
>>> If you use --disable-gtest with configure, can you build successfully then?
>>> 
>>> /Magnus
>>> 
 25 jan. 2017 kl. 09:34 skrev Mike Burton :
 
 
>> On 24 Jan 2017, at 21:25, Kim Barrett  wrote:
>> 
>> On Jan 23, 2017, at 5:34 AM, Mike Burton  wrote:
>> 
>> Hello,
>> 
>> I ran an OpenJDK Hack Day session on Saturday, at which some people got 
>> stuck on lost a fair bit of time, failing to build JDK9. Then we found 
>> that updating gcc from 4.6 to 4.8 fixed it.
>> Could the `configure` script be updated (by running get-source.sh) so as 
>> to check for minimum required gcc version?
>> 
>> Best Regards
>> 
>> Mike Burton
> I don’t think there is supposed to be a requirement for gcc > 4.6 in JDK 
> 9.  I’m pretty
> sure there are folks still building with older versions.  It would be 
> helpful to know the
> details of the platform and the error messages that led to the conclusion 
> that something
> more recent was required.
 Platform is Ubuntu 14.04, error message below:
 
 === Output from failing command(s) repeated here ===
 * For target 
 hotspot_variant-server_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link:
 /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a(ctype.o): 
 relocation R_X86_64_32S against `vtable for std::ctype' can not 
 be used when making a shared object; recompile with -fPIC
 /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a: could not read symbols: Bad 
 value
 collect2: ld returned 1 exit status
 === End of repeated output ===
 
 
> 

RE: RFR: JDK-8029942: Update VERSION_MAJOR for JDK 10

[Iris Clark]

Hi, Erik.

Your change looks good.

Thanks,
iris

-Original Message-
From: Erik Joelsson 
Sent: Thursday, January 26, 2017 5:57 AM
To: build-dev
Subject: RFR: JDK-8029942: Update VERSION_MAJOR for JDK 10

The default major version for the jdk 10 repos needs to be updated from 
9 to 10.

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

Patch:

diff -r 07f6f1f4140e common/autoconf/version-numbers
--- a/common/autoconf/version-numbers
+++ b/common/autoconf/version-numbers
@@ -25,7 +25,7 @@

  # Default version numbers to use unless overridden by configure

-DEFAULT_VERSION_MAJOR=9
+DEFAULT_VERSION_MAJOR=10
  DEFAULT_VERSION_MINOR=0
  DEFAULT_VERSION_SECURITY=0
  DEFAULT_VERSION_PATCH=0


/Erik

Re: configure - gcc >4.6 needed for JDK9 build

[Erik Joelsson]

The option is --disable-hotspot-gtest.

/Erik


On 2017-01-26 16:55, Mike Burton wrote:

When I do `bash configure —disable-gtest` it errors with:
unrecognised options: —disable-gtest

Mike



On 26 Jan 2017, at 15:36, Magnus Ihse Bursie  
wrote:

This is an issue with gtest, which is a bit special.

If you use --disable-gtest with configure, can you build successfully then?

/Magnus


25 jan. 2017 kl. 09:34 skrev Mike Burton :



On 24 Jan 2017, at 21:25, Kim Barrett  wrote:

On Jan 23, 2017, at 5:34 AM, Mike Burton  wrote:

Hello,

I ran an OpenJDK Hack Day session on Saturday, at which some people got stuck 
on lost a fair bit of time, failing to build JDK9. Then we found that updating 
gcc from 4.6 to 4.8 fixed it.
Could the `configure` script be updated (by running get-source.sh) so as to 
check for minimum required gcc version?

Best Regards

Mike Burton

I don’t think there is supposed to be a requirement for gcc > 4.6 in JDK 9.  
I’m pretty
sure there are folks still building with older versions.  It would be helpful 
to know the
details of the platform and the error messages that led to the conclusion that 
something
more recent was required.

Platform is Ubuntu 14.04, error message below:

=== Output from failing command(s) repeated here ===
* For target hotspot_variant-server_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link:
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a(ctype.o): relocation 
R_X86_64_32S against `vtable for std::ctype' can not be used when 
making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
=== End of repeated output ===

Re: configure - gcc >4.6 needed for JDK9 build

[Mike Burton]

When I do `bash configure —disable-gtest` it errors with:
unrecognised options: —disable-gtest

Mike


> On 26 Jan 2017, at 15:36, Magnus Ihse Bursie  
> wrote:
> 
> This is an issue with gtest, which is a bit special.
> 
> If you use --disable-gtest with configure, can you build successfully then?
> 
> /Magnus
> 
>> 25 jan. 2017 kl. 09:34 skrev Mike Burton :
>> 
>> 
 On 24 Jan 2017, at 21:25, Kim Barrett  wrote:
 
 On Jan 23, 2017, at 5:34 AM, Mike Burton  wrote:
 
 Hello,
 
 I ran an OpenJDK Hack Day session on Saturday, at which some people got 
 stuck on lost a fair bit of time, failing to build JDK9. Then we found 
 that updating gcc from 4.6 to 4.8 fixed it.
 Could the `configure` script be updated (by running get-source.sh) so as 
 to check for minimum required gcc version?
 
 Best Regards
 
 Mike Burton
>>> 
>>> I don’t think there is supposed to be a requirement for gcc > 4.6 in JDK 9. 
>>>  I’m pretty
>>> sure there are folks still building with older versions.  It would be 
>>> helpful to know the
>>> details of the platform and the error messages that led to the conclusion 
>>> that something
>>> more recent was required.
>> 
>> Platform is Ubuntu 14.04, error message below:
>> 
>> === Output from failing command(s) repeated here ===
>> * For target 
>> hotspot_variant-server_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link:
>> /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a(ctype.o): 
>> relocation R_X86_64_32S against `vtable for std::ctype' can not be 
>> used when making a shared object; recompile with -fPIC
>> /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a: could not read symbols: Bad 
>> value
>> collect2: ld returned 1 exit status
>> === End of repeated output ===
>> 
>> 
> 

Re: configure - gcc >4.6 needed for JDK9 build

[Magnus Ihse Bursie]

This is an issue with gtest, which is a bit special.

If you use --disable-gtest with configure, can you build successfully then?

/Magnus

> 25 jan. 2017 kl. 09:34 skrev Mike Burton :
> 
> 
>>> On 24 Jan 2017, at 21:25, Kim Barrett  wrote:
>>> 
>>> On Jan 23, 2017, at 5:34 AM, Mike Burton  wrote:
>>> 
>>> Hello,
>>> 
>>> I ran an OpenJDK Hack Day session on Saturday, at which some people got 
>>> stuck on lost a fair bit of time, failing to build JDK9. Then we found that 
>>> updating gcc from 4.6 to 4.8 fixed it.
>>> Could the `configure` script be updated (by running get-source.sh) so as to 
>>> check for minimum required gcc version?
>>> 
>>> Best Regards
>>> 
>>> Mike Burton
>> 
>> I don’t think there is supposed to be a requirement for gcc > 4.6 in JDK 9.  
>> I’m pretty
>> sure there are folks still building with older versions.  It would be 
>> helpful to know the
>> details of the platform and the error messages that led to the conclusion 
>> that something
>> more recent was required.
> 
> Platform is Ubuntu 14.04, error message below:
> 
> === Output from failing command(s) repeated here ===
> * For target hotspot_variant-server_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link:
> /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a(ctype.o): 
> relocation R_X86_64_32S against `vtable for std::ctype' can not be 
> used when making a shared object; recompile with -fPIC
> /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a: could not read symbols: Bad 
> value
> collect2: ld returned 1 exit status
> === End of repeated output ===
> 
> 

Re: RFR: JDK-8170483: Remove modules_src_jake workaround for JavaFX transition to new module-info syntax

[Alan Bateman]

On 26/01/2017 14:36, Erik Joelsson wrote:

When the last jake->jdk9 push was done, a temporary workaround for 
dealing with Javafx was needed. Javafx has now been fully updated to 
only deliver the new format so the workaround should be removed.


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

Webrev: http://cr.openjdk.java.net/~erikj/8170483/webrev.01/

This looks okay to me.

-Alan

RFR: JDK-8170483: Remove modules_src_jake workaround for JavaFX transition to new module-info syntax

[Erik Joelsson]

When the last jake->jdk9 push was done, a temporary workaround for 
dealing with Javafx was needed. Javafx has now been fully updated to 
only deliver the new format so the workaround should be removed.


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

Webrev: http://cr.openjdk.java.net/~erikj/8170483/webrev.01/

/Erik

Re: RFR: JDK-8081694 Remove DISABLED_WARNINGS_gcc for libsctp

[Chris Hegarty]

I’m not sure of the latest status of warnings in the build, but
just to say, libstcp was always built with 0 warnings being
emitted ( the JNI code has unused this/class parameters 
that cannot be removed ). If you remove this suppression
won’t the compilation of code from libsctp now produce a
warning for these cannot-be-removed unused parameters?
Misleading development engineers trying to clean up
warnings.

-Chris.

> On 26 Jan 2017, at 13:54, Magnus Ihse Bursie  
> wrote:
> 
> When fixing JDK-8081616 , 
> it turned out that
> DISABLED_WARNINGS_gcc := unused-parameter
> seemed to be needed for libsctp in make/lib/Lib-jdk.sctp.gmk.
> 
> This is not be needed anymore (and possibly never was).
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8081694
> Patch inline:
> diff --git a/make/lib/Lib-jdk.sctp.gmk b/make/lib/Lib-jdk.sctp.gmk
> --- a/make/lib/Lib-jdk.sctp.gmk
> +++ b/make/lib/Lib-jdk.sctp.gmk
> @@ -45,7 +45,6 @@
> $(LIBJAVA_HEADER_FLAGS) \
> -I$(SUPPORT_OUTPUTDIR)/headers/jdk.sctp \
> -I$(SUPPORT_OUTPUTDIR)/headers/java.base, \
> -DISABLED_WARNINGS_gcc := unused-parameter, \
> MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libsctp/mapfile-vers, \
> LDFLAGS := $(LDFLAGS_JDKLIB) \
> $(call SET_SHARED_LIBRARY_ORIGIN), \
> 

Re: RFR: JDK-8029942: Update VERSION_MAJOR for JDK 10

[Philip Race]

+1

-phil.

On 1/26/17, 5:56 AM, Erik Joelsson wrote:
The default major version for the jdk 10 repos needs to be updated 
from 9 to 10.


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

Patch:

diff -r 07f6f1f4140e common/autoconf/version-numbers
--- a/common/autoconf/version-numbers
+++ b/common/autoconf/version-numbers
@@ -25,7 +25,7 @@

 # Default version numbers to use unless overridden by configure

-DEFAULT_VERSION_MAJOR=9
+DEFAULT_VERSION_MAJOR=10
 DEFAULT_VERSION_MINOR=0
 DEFAULT_VERSION_SECURITY=0
 DEFAULT_VERSION_PATCH=0


/Erik

Re: RFR: JDK-8081694 Remove DISABLED_WARNINGS_gcc for libsctp

[Erik Joelsson]

Looks good.

/Erik


On 2017-01-26 14:54, Magnus Ihse Bursie wrote:
When fixing JDK-8081616 
, it turned out that

DISABLED_WARNINGS_gcc := unused-parameter
seemed to be needed for libsctp in make/lib/Lib-jdk.sctp.gmk.

This is not be needed anymore (and possibly never was).

Bug: https://bugs.openjdk.java.net/browse/JDK-8081694
Patch inline:
diff --git a/make/lib/Lib-jdk.sctp.gmk b/make/lib/Lib-jdk.sctp.gmk
--- a/make/lib/Lib-jdk.sctp.gmk
+++ b/make/lib/Lib-jdk.sctp.gmk
@@ -45,7 +45,6 @@
 $(LIBJAVA_HEADER_FLAGS) \
 -I$(SUPPORT_OUTPUTDIR)/headers/jdk.sctp \
 -I$(SUPPORT_OUTPUTDIR)/headers/java.base, \
-DISABLED_WARNINGS_gcc := unused-parameter, \
 MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libsctp/mapfile-vers, \
 LDFLAGS := $(LDFLAGS_JDKLIB) \
 $(call SET_SHARED_LIBRARY_ORIGIN), \

RFR: JDK-8029942: Update VERSION_MAJOR for JDK 10

[Erik Joelsson]

The default major version for the jdk 10 repos needs to be updated from 
9 to 10.


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

Patch:

diff -r 07f6f1f4140e common/autoconf/version-numbers
--- a/common/autoconf/version-numbers
+++ b/common/autoconf/version-numbers
@@ -25,7 +25,7 @@

 # Default version numbers to use unless overridden by configure

-DEFAULT_VERSION_MAJOR=9
+DEFAULT_VERSION_MAJOR=10
 DEFAULT_VERSION_MINOR=0
 DEFAULT_VERSION_SECURITY=0
 DEFAULT_VERSION_PATCH=0


/Erik

RFR: JDK-8081694 Remove DISABLED_WARNINGS_gcc for libsctp

[Magnus Ihse Bursie]

When fixing JDK-8081616 
, it turned out that

DISABLED_WARNINGS_gcc := unused-parameter
seemed to be needed for libsctp in make/lib/Lib-jdk.sctp.gmk.

This is not be needed anymore (and possibly never was).

Bug: https://bugs.openjdk.java.net/browse/JDK-8081694
Patch inline:
diff --git a/make/lib/Lib-jdk.sctp.gmk b/make/lib/Lib-jdk.sctp.gmk
--- a/make/lib/Lib-jdk.sctp.gmk
+++ b/make/lib/Lib-jdk.sctp.gmk
@@ -45,7 +45,6 @@
 $(LIBJAVA_HEADER_FLAGS) \
 -I$(SUPPORT_OUTPUTDIR)/headers/jdk.sctp \
 -I$(SUPPORT_OUTPUTDIR)/headers/java.base, \
-DISABLED_WARNINGS_gcc := unused-parameter, \
 MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libsctp/mapfile-vers, \
 LDFLAGS := $(LDFLAGS_JDKLIB) \
 $(call SET_SHARED_LIBRARY_ORIGIN), \

Re: RFR [9] Warning notice for types in Incubator Modules

[Magnus Ihse Bursie]

On 2017-01-25 13:51, Chris Hegarty wrote:

On 24 Jan 2017, at 16:44, Erik Joelsson  wrote:

Hello,

Build changes look good except for one thing. In Javadoc.gmk, the dependency on 
$(BUILD_TOOLS_JDK) needs to be set for $$($1_INDEX_FILE) (on line 317), where 
the actual recipes are created. Setting it on the phony docs-javadoc target 
will not help incremental builds.

Updated in place
   http://cr.openjdk.java.net/~chegar/incubator_taglet/


It's not ideal that a top-level target has dependencies from the JDK 
repo, but since we have no or few pre-existing top-level tools, I 
understand if you hesitate to add a new framework for such tools. If we 
ever do introduce more such tools, I think we should move this along.


I think the new -taglet options to the DEFAULT_JAVADOC_OPTIONS variable. 
As  the documentation says, the DEFAULT_JAVADOC_TAGS is there to specify 
the ordering of tags in the output. Unless the -taglet options 
implicitly generates one or more -tag options in it's place, that's the 
wrong place to put it. If it does, perhaps a comment indicating this 
hidden behavior would be in place.


In the line: "$$($1_INDEX_FILE): $(BUILD_TOOLS_JDK) $$($1_VARDEPS_FILE) 
$$($1_PACKAGE_DEPS) $$($1_DEPS)", please use a double $ ($$) for all 
variables. While technically not necessary in this particular case, it's 
misleading and we've had our share of bugs due to single $ in eval'd macros.


In the line: "docs-javadoc: $(BUILD_TOOLS_JDK) $(TARGETS)", please 
remove the reference to BUILD_TOOLS_JDK. It is not needed.


/Magnus




-Chris.


/Erik


On 2017-01-24 15:08, Chris Hegarty wrote:

As per the guidance in JEP 11 [1], the javadoc for types in
incubator modules should have a clear and explicit warning
notice. To that end, I’ve added a simple inline taglet that can
be used to effectively inject a standard notice, and applied it
to all public types in the HTTP module ( I’ll cleanup the line
width formatting before pushing ).

http://cr.openjdk.java.net/~chegar/incubator_taglet/

-Chris.

P.S. this work is, somewhat, in preparation for when we move
to a single documentation bundle [2].

[1] http://openjdk.java.net/jeps/11
[2] http://openjdk.java.net/jeps/299