Re: RFR: JDK-8196998: Create devkit for Linux with gcc 7.3

2018-02-08 Thread Magnus Ihse Bursie
Looks good to me. 

/Magnus

> 8 feb. 2018 kl. 20:59 skrev Erik Joelsson :
> 
> Thanks, updated in place.
> 
> /Erik
> 
> 
>> On 2018-02-08 11:55, Tim Bell wrote:
>> Erik:
>> 
>> make/devkit/Tools.gmk
>> 
>> line 553: one typo - 'too the' should be 'to the'
>> 
>> Looks good otherwise.
>> 
>> Tim
>> 
>>> On 02/08/18 11:42, Erik Joelsson wrote:
>>> Here is a new webrev with dtrace included. I have verified that it
>>> builds open linux-x64 successfully with dtrace enabled both on my Ubuntu
>>> without any dtrace installed as well as in mach5.
>>> 
>>> http://cr.openjdk.java.net/~erikj/8196998/webrev.02/
>>> 
>>> /Erik
>>> 
>>> 
 On 2018-02-08 02:37, Magnus Ihse Bursie wrote:
 Erik,
 
 Is it possible that you could address
 https://bugs.openjdk.java.net/browse/JDK-8193016 at this time as well?
 
 Apart from that, it looks good to me.
 
 /Magnus
 
 8 feb. 2018 kl. 02:49 skrev Tim Bell >:
 
> Erik:
> 
>> For oracle internal builds, we need to construct a portable devkit based
>> on GCC 7.3. This change contains the updated makefile logic used to
>> create this. The changes adds gdb and the gold linker. It also adds
>> dynamic downloading of the sysroot rpms. Several long standing bugs were
>> also fixed.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196998
>> 
>> Webrev: http://cr.openjdk.java.net/~erikj/8196998/webrev.01/
>> 
> 
> 
> Looks good.
> 
> /Tim
> 
>>> 
>> 
> 



Re: RFR: JDK-8196998: Create devkit for Linux with gcc 7.3

2018-02-08 Thread Erik Joelsson

Thanks, updated in place.

/Erik


On 2018-02-08 11:55, Tim Bell wrote:

Erik:

make/devkit/Tools.gmk

line 553: one typo - 'too the' should be 'to the'

Looks good otherwise.

Tim

On 02/08/18 11:42, Erik Joelsson wrote:

Here is a new webrev with dtrace included. I have verified that it
builds open linux-x64 successfully with dtrace enabled both on my Ubuntu
without any dtrace installed as well as in mach5.

http://cr.openjdk.java.net/~erikj/8196998/webrev.02/

/Erik


On 2018-02-08 02:37, Magnus Ihse Bursie wrote:

Erik,

Is it possible that you could address
https://bugs.openjdk.java.net/browse/JDK-8193016 at this time as well?

Apart from that, it looks good to me.

/Magnus

8 feb. 2018 kl. 02:49 skrev Tim Bell >:


Erik:

For oracle internal builds, we need to construct a portable devkit 
based

on GCC 7.3. This change contains the updated makefile logic used to
create this. The changes adds gdb and the gold linker. It also adds
dynamic downloading of the sysroot rpms. Several long standing 
bugs were

also fixed.

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

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




Looks good.

/Tim









Re: RFR: JDK-8196998: Create devkit for Linux with gcc 7.3

2018-02-08 Thread Tim Bell

Erik:

make/devkit/Tools.gmk

line 553: one typo - 'too the' should be 'to the'

Looks good otherwise.

Tim

On 02/08/18 11:42, Erik Joelsson wrote:

Here is a new webrev with dtrace included. I have verified that it
builds open linux-x64 successfully with dtrace enabled both on my Ubuntu
without any dtrace installed as well as in mach5.

http://cr.openjdk.java.net/~erikj/8196998/webrev.02/

/Erik


On 2018-02-08 02:37, Magnus Ihse Bursie wrote:

Erik,

Is it possible that you could address
https://bugs.openjdk.java.net/browse/JDK-8193016 at this time as well?

Apart from that, it looks good to me.

/Magnus

8 feb. 2018 kl. 02:49 skrev Tim Bell >:


Erik:


For oracle internal builds, we need to construct a portable devkit based
on GCC 7.3. This change contains the updated makefile logic used to
create this. The changes adds gdb and the gold linker. It also adds
dynamic downloading of the sysroot rpms. Several long standing bugs were
also fixed.

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

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




Looks good.

/Tim







Re: RFR: JDK-8196998: Create devkit for Linux with gcc 7.3

2018-02-08 Thread Erik Joelsson
Here is a new webrev with dtrace included. I have verified that it 
builds open linux-x64 successfully with dtrace enabled both on my Ubuntu 
without any dtrace installed as well as in mach5.


http://cr.openjdk.java.net/~erikj/8196998/webrev.02/

/Erik


On 2018-02-08 02:37, Magnus Ihse Bursie wrote:

Erik,

Is it possible that you could address 
https://bugs.openjdk.java.net/browse/JDK-8193016 at this time as well?


Apart from that, it looks good to me.

/Magnus

8 feb. 2018 kl. 02:49 skrev Tim Bell >:



Erik:


For oracle internal builds, we need to construct a portable devkit based
on GCC 7.3. This change contains the updated makefile logic used to
create this. The changes adds gdb and the gold linker. It also adds
dynamic downloading of the sysroot rpms. Several long standing bugs were
also fixed.

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

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




Looks good.

/Tim





Re: RFR: JDK-8196356: Changes to m4 files don't trigger autoconf execution at build time

2018-02-08 Thread Tim Bell

Erik:


The check for when to generate the generated configure script is not
working quite as expected. It currently only compares timestamps if the
local repository has any local changes in the make/autoconf directory.
This used to make sense when we had a committed generated script, but
now we actually do need to regenerate any time an input file is newer
than the generated script.

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

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


Yes, that makes sense.  Looks good to me.

/Tim



Re: RFR: JDK-8196998: Create devkit for Linux with gcc 7.3

2018-02-08 Thread Erik Joelsson

Good point, I will look into it.

/Erik


On 2018-02-08 02:37, Magnus Ihse Bursie wrote:

Erik,

Is it possible that you could address 
https://bugs.openjdk.java.net/browse/JDK-8193016 at this time as well?


Apart from that, it looks good to me.

/Magnus

8 feb. 2018 kl. 02:49 skrev Tim Bell >:



Erik:


For oracle internal builds, we need to construct a portable devkit based
on GCC 7.3. This change contains the updated makefile logic used to
create this. The changes adds gdb and the gold linker. It also adds
dynamic downloading of the sysroot rpms. Several long standing bugs were
also fixed.

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

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




Looks good.

/Tim





RFR: JDK-8196356: Changes to m4 files don't trigger autoconf execution at build time

2018-02-08 Thread Erik Joelsson
The check for when to generate the generated configure script is not 
working quite as expected. It currently only compares timestamps if the 
local repository has any local changes in the make/autoconf directory. 
This used to make sense when we had a committed generated script, but 
now we actually do need to regenerate any time an input file is newer 
than the generated script.


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

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

/Erik



Re: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build

2018-02-08 Thread Thomas Stüfe
Thanks!

On Thu, Feb 8, 2018 at 3:49 PM, Lindenmaier, Goetz <
goetz.lindenma...@sap.com> wrote:

> HI Thomas,
>
> looks good, thanks!
>
> Best regards,
>   Goetz.
>
> > -Original Message-
> > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-
> > boun...@openjdk.java.net] On Behalf Of Thomas Stüfe
> > Sent: Donnerstag, 8. Februar 2018 15:42
> > To: ppc-aix-port-...@openjdk.java.net; build-dev  > d...@openjdk.java.net>
> > Subject: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in
> > fastdebug build
> >
> > Hi,
> >
> > may I please have reviews for this tiny fix:
> >
> > Bug:  https://bugs.openjdk.java.net/browse/JDK-8196488
> > webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8196488-aix-toc-
> > overflow-in-fastdebug/webrev.00/webrev/
> >
> > Thanks and Kind Regards, Thomas
>


Re: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build

2018-02-08 Thread Thomas Stüfe
Thanks Matthias!

On Thu, Feb 8, 2018 at 3:58 PM, Baesken, Matthias 
wrote:

> Hi Thomas , looks good to me( not a Reviever however).
>
>
>
> Best Regards, Matthias
>
>
>
> *From:* ppc-aix-port-dev [mailto:ppc-aix-port-dev-boun...@openjdk.java.net]
> *On Behalf Of *Thomas Stüfe
> *Sent:* Donnerstag, 8. Februar 2018 15:42
> *To:* ppc-aix-port-...@openjdk.java.net; build-dev <
> build-dev@openjdk.java.net>
> *Subject:* RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so
> in fastdebug build
>
>
>
> Hi,
>
>
>
> may I please have reviews for this tiny fix:
>
>
>
> Bug:  https://bugs.openjdk.java.net/browse/JDK-8196488
>
> webrev: http://cr.openjdk.java.net/~stuefe/webrevs/
> 8196488-aix-toc-overflow-in-fastdebug/webrev.00/webrev/
>
>
>
> Thanks and Kind Regards, Thomas
>


Re: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build

2018-02-08 Thread Thomas Stüfe
Hi Eric,

On Thu, Feb 8, 2018 at 6:09 PM, Erik Joelsson 
wrote:

> Looks good, happy pushing without a sponsor!
>
> /Erik
>
>
Yes please, that would be nice!

..Thomas


>
>
> On 2018-02-08 06:42, Thomas Stüfe wrote:
>
>> Hi,
>>
>> may I please have reviews for this tiny fix:
>>
>> Bug:  https://bugs.openjdk.java.net/browse/JDK-8196488
>> webrev:
>> http://cr.openjdk.java.net/~stuefe/webrevs/8196488-aix-toc-
>> overflow-in-fastdebug/webrev.00/webrev/
>>
>> Thanks and Kind Regards, Thomas
>>
>
>


Re: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build

2018-02-08 Thread Erik Joelsson

Looks good, happy pushing without a sponsor!

/Erik


On 2018-02-08 06:42, Thomas Stüfe wrote:

Hi,

may I please have reviews for this tiny fix:

Bug:  https://bugs.openjdk.java.net/browse/JDK-8196488
webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8196488-aix-toc-overflow-in-fastdebug/webrev.00/webrev/

Thanks and Kind Regards, Thomas




RE: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build

2018-02-08 Thread Baesken, Matthias
Hi Thomas , looks good to me( not a Reviever however).

Best Regards, Matthias

From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-boun...@openjdk.java.net] On 
Behalf Of Thomas Stüfe
Sent: Donnerstag, 8. Februar 2018 15:42
To: ppc-aix-port-...@openjdk.java.net; build-dev 
Subject: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in 
fastdebug build

Hi,

may I please have reviews for this tiny fix:

Bug:  https://bugs.openjdk.java.net/browse/JDK-8196488
webrev: 
http://cr.openjdk.java.net/~stuefe/webrevs/8196488-aix-toc-overflow-in-fastdebug/webrev.00/webrev/

Thanks and Kind Regards, Thomas


RE: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build

2018-02-08 Thread Lindenmaier, Goetz
HI Thomas, 

looks good, thanks!

Best regards,
  Goetz.

> -Original Message-
> From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-
> boun...@openjdk.java.net] On Behalf Of Thomas Stüfe
> Sent: Donnerstag, 8. Februar 2018 15:42
> To: ppc-aix-port-...@openjdk.java.net; build-dev  d...@openjdk.java.net>
> Subject: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in
> fastdebug build
> 
> Hi,
> 
> may I please have reviews for this tiny fix:
> 
> Bug:  https://bugs.openjdk.java.net/browse/JDK-8196488
> webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8196488-aix-toc-
> overflow-in-fastdebug/webrev.00/webrev/
> 
> Thanks and Kind Regards, Thomas


RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build

2018-02-08 Thread Thomas Stüfe
Hi,

may I please have reviews for this tiny fix:

Bug:  https://bugs.openjdk.java.net/browse/JDK-8196488
webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8196488-aix-toc-overflow-in-fastdebug/webrev.00/webrev/

Thanks and Kind Regards, Thomas


Re: RFR 8190378: Java EE and CORBA modules removal

2018-02-08 Thread Lance Andersen

> On Feb 8, 2018, at 3:04 AM, Alan Bateman  wrote:
> 
> On 07/02/2018 16:57, Lance Andersen wrote:
>> Hi all,
>> 
>> I think we are at a point where we are ready to start reviewing  the changes 
>> to remove the Java EE and CORBA modules as JEP 320, JDK-8189188,  has been  
>> targeted to JDK 11.
>> The CSR for removing the modules has been approved: 
>> https://bugs.openjdk.java.net/browse/JDK-8193757 
>> 
>> 
>>  The open webrev can be found at:  
>> http://cr.openjdk.java.net/~lancea/8190378/open_changes/ 
>> 
>> 
> 800 KLOC deleted, wonderful!
> 
> The update to technology-summary.html page means its html title no longer 
> matches the contents. We should probably change it to "JCP Technologies in 
> JDK 11" for now.

I updated the webrev. Thanks for catching that (btw we missed this for JDK 10)
> 
> The removal of test cases from the tests in tools/launcher/modules removes 
> most of the test coverage for the upgrade module path. We'll need to replace 
> these sub-tests. Can you create an issue to track that?

I can do that 
> 
> Everything else looks good and it's okay to track residual issues with other 
> JIRA issues. I think the important thing is to get this monster patch into 
> JDK builds soon so that libraries and the eco system can start to adjust.

Thank you Alan for the review

Best
Lance
> 
> -Alan

 
  

 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: [PATCH] (Title Corrected) Build fails to compile jchuff.c using gcc 4.8.5 on zLinux

2018-02-08 Thread Magnus Ihse Bursie

On 2018-01-17 15:07, Adam Farley8 wrote:

If this is the consensus, then perhaps we should consider setting
--disable-warnings-as-errors by default (in the code), rather than
depending on the user using an option which is not part of the formal
build instructions.

I'm not sure why.

Because the default build instructions don't work in this scenario, and
if all the effort to impliment a clone-config-make model was intended to
encourage more users to attempt a local build (in order to try their hand
at a fixing a bug themselves or something) it makes sense to me to try
to maintain a scenario where OpenJDK can build to completion across a wide
variety of toolchains.


I'm not sure what you mean by that the "default build instrictions don't 
work". When the build fails due to a warning and you have not disabled 
warnings as error, the build output looks like this:


ERROR: Build failed for target 'jdk' in configuration 'linux-x64' (exit 
code 2)


=== Output from failing command(s) repeated here ===
* For target support_native_jdk.management_libmanagement_ext_Flag.o:
/localhome/hg/jdk-ALT/open/src/jdk.management/share/native/libmanagement_ext/Flag.c: 
In function 'heh':
/localhome/hg/jdk-ALT/open/src/jdk.management/share/native/libmanagement_ext/Flag.c:37:10: 
error: comparison of unsigned expression < 0 is always false 
[-Werror=type-limits]

 if (hest < 0) {
  ^
cc1: all warnings being treated as errors

* All command lines available in 
/localhome/hg/jdk-ALT/build/linux-x64/make-support/failure-logs.

=== End of repeated output ===

=== Make failed targets repeated here ===
Lib-jdk.management.gmk:56: recipe for target 
'/localhome/hg/jdk-ALT/build/linux-x64/support/native/jdk.management/libmanagement_ext/Flag.o' 
failed

make/Main.gmk:226: recipe for target 'jdk.management-libs' failed
=== End of repeated output ===

Hint: Try searching the build log for the name of the first failed target.
Hint: See doc/building.html#troubleshooting for assistance.

I don't think it requires much of an effort or capacity as a programmer 
to figure out that this is a warning, which was turned into an error. At 
the very last line before your prompt, you are also given a very good 
suggestion. And very much so, the troubleshooting chapter does indeed 
have a section on "Fixing Unexpected Build Failures" where 
--disable-warnings-as-errors are suggested.


If by "default" you mean that you only read like the top part of the 
document:

"TL;DR (Instructions for the Impatient)

If you are eager to try out building OpenJDK, these simple steps works 
most of the time."
but missed out the "most of the time" or the "If any of these steps 
failed, or if you want to know more about build requirements or build 
functionality, please continue reading this document." following after 
the just 5 numbered items, then I don't know what will help you.


We try really hard to make the build experience easy, pleasant and 
simple, but there is no way that everything is ever going to work 
perfectly straight out of the box for anyone. Especially not if they are 
using exotic or unusal hardware or software. In those cases, reading the 
documentation is necessary, as for all software projects.


/Magnus






Building OpenJDK from source isn't exactly something
that is done by normal users. If someone is willing to hack on the

OpenJDK

code base, I would assume they know about -Werror and similar options and
how to control them.

I don't agree. Someone should not have to be familiar with gcc options in
order to fix a typo, or change some Java code. And besides, we have a
clear
and simple four-step build process (clone, get source, configure, make).
Why would we want people to have to fail their build and experiment with
different options, when we can fix the problem right here and now.


I mean, yes, you can change that to have -Werror turned off by default,
but having the compiler complain less is usually a bad idea.

In general, yes. In this one compile it's breaking the build.

David suggested disabling this warning. The simplest way I see to do this
is to change Awt2dLibraries.gmk.

The code is here:

$(eval $(call SetupNativeCompilation,BUILD_LIBJAVAJPEG, \
 LIBRARY := javajpeg, \
 OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \
 SRC := $(LIBJAVAJPEG_SRC), \
 INCLUDE_FILES := $(BUILD_LIBJAVAJPEG_INCLUDE_FILES), \
 OPTIMIZATION := HIGHEST, \

Switching the OPTIMIZATION to LOW will solve this at a stroke.

Best Regards

Adam farley

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU




Re: RFR: JDK-8196985: Disable new warnings from GCC 7.3 in jdk libraries

2018-02-08 Thread Magnus Ihse Bursie
Looks good to me. 

/Magnus

> 7 feb. 2018 kl. 23:33 skrev Erik Joelsson :
> 
> When building the jdk with GCC 7.3, a bunch of new warnings are triggered. 
> These include:
> 
> * implicit-fallthrough
> * shift-negative-value
> * misleading-indentation
> * maybe-uninitialized
> 
> I won't attempt to fix any of these at this point, but rather just disable 
> the warnings. I have created followup issues (or added to existing ones where 
> applicable) for each library/executable where warnings need to be evaluated.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8196985
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8196985/webrev.01/
> 
> /Erik
> 



Re: RFR: JDK-8196998: Create devkit for Linux with gcc 7.3

2018-02-08 Thread Magnus Ihse Bursie
Erik,

Is it possible that you could address 
https://bugs.openjdk.java.net/browse/JDK-8193016 at this time as well?

Apart from that, it looks good to me. 

/Magnus

> 8 feb. 2018 kl. 02:49 skrev Tim Bell :
> 
> Erik:
> 
>> For oracle internal builds, we need to construct a portable devkit based
>> on GCC 7.3. This change contains the updated makefile logic used to
>> create this. The changes adds gdb and the gold linker. It also adds
>> dynamic downloading of the sysroot rpms. Several long standing bugs were
>> also fixed.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196998
>> 
>> Webrev: http://cr.openjdk.java.net/~erikj/8196998/webrev.01/
> 
> 
> Looks good.
> 
> /Tim
> 


Re: RFR 8190378: Java EE and CORBA modules removal

2018-02-08 Thread Alan Bateman

On 07/02/2018 16:57, Lance Andersen wrote:

Hi all,

I think we are at a point where we are ready to start reviewing  the changes to 
remove the Java EE and CORBA modules as JEP 320, JDK-8189188,  has been  
targeted to JDK 11.
The CSR for removing the modules has been approved: 
https://bugs.openjdk.java.net/browse/JDK-8193757 


  The open webrev can be found at:  
http://cr.openjdk.java.net/~lancea/8190378/open_changes/ 



800 KLOC deleted, wonderful!

The update to technology-summary.html page means its html title no 
longer matches the contents. We should probably change it to "JCP 
Technologies in JDK 11" for now.


The removal of test cases from the tests in tools/launcher/modules 
removes most of the test coverage for the upgrade module path. We'll 
need to replace these sub-tests. Can you create an issue to track that?


Everything else looks good and it's okay to track residual issues with 
other JIRA issues. I think the important thing is to get this monster 
patch into JDK builds soon so that libraries and the eco system can 
start to adjust.


-Alan