Re: [OpenJDK 2D-Dev] RFR: Bug Pending: Build fails to compile jchuff.c

[Erik Joelsson]

Hello,

Oracle still builds JDK 10 and 11 using Xcode 6.3 using the Macosx10.9 
sdk. We are warning free there. Using newer versions of Xcode is known 
to produce warnings.


I'm currently in the process of updating the toolchain versions and 
platforms we use at Oracle so this should get fixed in the near future 
for JDK 11. Note though that it will deteriorate again with even newer 
versions of Xcode unless someone else provides fixes for it before we 
switch toolchain versions again.


/Erik



On 2018-02-01 09:57, Alan Snyder wrote:


On Feb 1, 2018, at 9:05 AM, Erik Joelsson > wrote:


Regarding warning chasing. I agree that we it's not feasible to chase 
down every warning in every version of GCC, or any other toolchain, 
but I also think that for platforms/configurations where people are 
actively developing changes for OpenJDK, it makes sense to try to 
keep it clean. This helps prevent new code from introducing warnings. 
For the configurations Oracle use, we keep a strict -Werror policy 
because we want the code to be clean


Is it not the case that building on macOS requires 
-disable-warnings-as-errors? Or is that only the case on more recent 
macOS releases that used by Oracle?


  Alan

Re: [OpenJDK 2D-Dev] RFR: Bug Pending: Build fails to compile jchuff.c

[Alan Snyder]

> On Feb 1, 2018, at 9:05 AM, Erik Joelsson  wrote:
> 
> Regarding warning chasing. I agree that we it's not feasible to chase down 
> every warning in every version of GCC, or any other toolchain, but I also 
> think that for platforms/configurations where people are actively developing 
> changes for OpenJDK, it makes sense to try to keep it clean. This helps 
> prevent new code from introducing warnings. For the configurations Oracle 
> use, we keep a strict -Werror policy because we want the code to be clean

Is it not the case that building on macOS requires -disable-warnings-as-errors? 
Or is that only the case on more recent macOS releases that used by Oracle?

  Alan

Re: Proposal: Make custom extension point additions

[Erik Joelsson]

Hello Andrew,

This looks good to me. I've created 
https://bugs.openjdk.java.net/browse/JDK-8196585 and will push it for you.


/Erik


On 2018-02-01 08:52, Andrew Leonard wrote:

Thanks Erik,
I have moved the "post" hooks after the ###'s as you mentioned and 
similarly to the end for GensrcVarHandles.gmk. Here is the new hg diff 
-g patch, I have built it with the latest jdk head and run the jtreg 
tests successfully.

Cheers
Andrew

diff --git a/make/common/SetupJavaCompilers.gmk 
b/make/common/SetupJavaCompilers.gmk

--- a/make/common/SetupJavaCompilers.gmk
+++ b/make/common/SetupJavaCompilers.gmk
@@ -26,13 +26,16 @@
 ifndef _SETUP_GMK
 _SETUP_GMK := 1

+# Include custom extension hook
+$(eval $(call IncludeCustomExtension, common/SetupJavaCompilers.gmk))
+
 include JavaCompilation.gmk

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


 # If warnings needs to be non-fatal for testing purposes use a 
command like:

 # make JAVAC_WARNINGS="-Xlint:all -Xmaxwarns 1"
-JAVAC_WARNINGS := -Xlint:all -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.
diff --git a/make/gensrc/GensrcVarHandles.gmk 
b/make/gensrc/GensrcVarHandles.gmk

--- a/make/gensrc/GensrcVarHandles.gmk
+++ b/make/gensrc/GensrcVarHandles.gmk
@@ -168,3 +168,7 @@
   $(eval $(call 
GenerateVarHandleByteArray,VAR_HANDLE_BYTE_ARRAY_$t,$t)))


 GENSRC_JAVA_BASE += $(GENSRC_VARHANDLES)
+
+# Include custom extension post hook
+$(eval $(call IncludeCustomExtension, gensrc/GensrcVarHandles-post.gmk))
+
diff --git a/make/lib/Lib-java.management.gmk 
b/make/lib/Lib-java.management.gmk

--- a/make/lib/Lib-java.management.gmk
+++ b/make/lib/Lib-java.management.gmk
@@ -70,3 +70,7 @@
 TARGETS += $(BUILD_LIBMANAGEMENT)

  


+
+# Include custom extension post hook
+$(eval $(call IncludeCustomExtension, lib/Lib-java.management-post.gmk))
+
diff --git a/make/lib/Lib-jdk.management.gmk 
b/make/lib/Lib-jdk.management.gmk

--- a/make/lib/Lib-jdk.management.gmk
+++ b/make/lib/Lib-jdk.management.gmk
@@ -80,3 +80,7 @@
 TARGETS += $(BUILD_LIBMANAGEMENT_EXT)

  


+
+# Include custom extension post hook
+$(eval $(call IncludeCustomExtension, lib/Lib-jdk.management-post.gmk))
+





Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leon...@uk.ibm.com




From: Erik Joelsson 
To: Andrew Leonard , 
build-dev@openjdk.java.net

Date: 31/01/2018 17:40
Subject: Re: Proposal: Make custom extension point additions




Hello Andrew,

This suggestion looks reasonable to me. Just a minor note on the
placement of the post hooks. Especially in the Lib-* files, each
individual library, or link entity, is put within ### separator lines.
In the two files you modified, since there is only one library declared,
this isn't as apparent. I would prefer if the post hook came after all
the declared library sections instead of inside one of them. The Gensrc
file is more of a snowflake so the placement is reasonable there.

/Erik


On 2018-01-31 03:21, Andrew Leonard wrote:
> Hi,
> I would like to find a sponsor for this change please?
> To support certain extension capabilities I would like to propose the
> following patch to the following make files, summary of changes:
>      M make/common/SetupJavaCompilers.gmk
>          ==> Add IncludeCustomExtension hook and allow custom 
override of

> DISABLE_WARNINGS and JAVAC_WARNINGS
>      M make/gensrc/GensrcVarHandles.gmk
>          ==> Add IncludeCustomExtension "post" hook
>      M make/lib/Lib-java.management.gmk
>          ==> Add IncludeCustomExtension "post" hook
>      M make/lib/Lib-jdk.management.gmk
>          ==> Add IncludeCustomExtension "post" hook
>
> Many thanks,
> Andrew
>
> hg diff -g output:
> diff --git a/make/common/SetupJavaCompilers.gmk
> b/make/common/SetupJavaCompilers.gmk
> --- a/make/common/SetupJavaCompilers.gmk
> +++ b/make/common/SetupJavaCompilers.gmk
> @@ -26,13 +26,16 @@
>   ifndef _SETUP_GMK
>   _SETUP_GMK := 1
>
> +# Include custom extension hook
> +$(eval $(call IncludeCustomExtension, common/SetupJavaCompilers.gmk))
> +
>   include JavaCompilation.gmk
>
> -DISABLE_WARNINGS :=
> 
-Xlint:all,-deprecation,-removal,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally

> +DISABLE_WARNINGS ?=
> 
-Xlint:all,-deprecation,-removal,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fa

Re: [OpenJDK 2D-Dev] RFR: Bug Pending: Build fails to compile jchuff.c

[Erik Joelsson]

Am I understanding this correctly that it's really not tied to a gcc 
version but a cpu architecture, so it's only really affecting s390x? Are 
you also saying that gcc 7.2.1 is also affected but with a different 
message? I'm fine with disabling this warning conditional on s390x, no 
need for specific gcc versions.


This discussion has already taken more time than it really warrants. :)

Regarding warning chasing. I agree that we it's not feasible to chase 
down every warning in every version of GCC, or any other toolchain, but 
I also think that for platforms/configurations where people are actively 
developing changes for OpenJDK, it makes sense to try to keep it clean. 
This helps prevent new code from introducing warnings. For the 
configurations Oracle use, we keep a strict -Werror policy because we 
want the code to be clean. I'm fine with other users trying to keep the 
same standards on their configurations, but knowing that it will be 
their responsibility to keep up to date. I also think we need to be 
reasonably fine grained in when we disable warnings. Specifying every 
affected version of a toolchain is too much, but if there are specific 
well defined limits to where the disabling relevant, then I think we 
should use them, within reason. This also helps with keeping track of 
why a particular warning is disabled in a future attempt to fix them.


On the other hand, if you are just building OpenJDK to produce binaries, 
without producing and up streaming new code changes, there really isn't 
much need for making the effort of trying to keep things clean, and 
trying to do so will likely just end up being more work than it's worth.


/Erik


On 2018-02-01 03:36, Adam Farley8 wrote:

Hi All,

After doing some experimenting, I've discovered the problem isn't 
limited to

SLES, or gcc 4.8.5, or zLinux.

Platforms affected: zLinux, ppcle Linux
Platforms not affected: x86 Linux

gcc versions affected: 4.8.5, 5.4.0
gcc versions unaffected: 7.2.1

linux variations affected: Ubuntu, SLES
E.g. when I told SLES 12 (zLinux) to install gcc, it installed 5.4.0.

All this tells me that, if we intent to encourage SLES 12 users to build
Java 11, we need this warning suppression hard coded. There are ways to
do "greater than"s and "first character in"s in make, but they require
either shell commands, or more dollar signs than you can shake a stick 
at.


I propose we hard code "array-bounds" into javajpeg's 
DISABLED_WARNINGS_gcc

for all java versions, and move on.

On the basis that gcc 7.2.1 produces a different error message when an
array-bounds problem occurs (e.g. frog[-1] produces the warning
"error: ‘frog[-7]’ is used uninitialized in this function"), I don't see
leaving array-bounds in DISABLED_WARNINGS_gcc as a problem.

Thoughts?

Best Regards

Adam Farley

> The claim on the wiki was made by Volker on July 13 2017. It was done on
> SuSE linux while the reported problem is on zLinux. Maybe they have
> different vendor specific patches in their respective gcc builds? Is SAP
> still able to build without --disable-warnings-as-errors? This wiki is
> supposed to be a community effort.
>
> /Erik
>
>
>On 2018-01-24 16:37, David Holmes wrote:
>> Hi Magnus,
>>
>> On 25/01/2018 9:55 AM, Magnus Ihse Bursie wrote:
>>> I'm not sure I'm able to follow where this discussion is heading, but
>>> at the very least I'd like to chime in on the patch below:
>>>
>>> I don't like how the entire DISABLED_WARNINGS_gcc line is lifted out.
>>> A better solution is something like this:
>>>
>>> ifeq ($(CC_VERSION_NUMBER), 4.8.5)
>>>   #Turn off array-bounds warnings for libjava compilation because
>>> jchuff.c
>>>   #fails to compile on gcc 4.8.5 with a warning that an array is
>>> potentially
>>>   #out of bounds. This kills a warnings=errors build.
>>>   LIBJAVAJPEG_DISABLED_WARNINGS_gcc485 := array-bounds
>>> endif
>>> ...
>>> DISABLED_WARNINGS_gcc := clobbered
>>> $(LIBJAVAJPEG_DISABLED_WARNINGS_gcc485), \
>>>
>>> I also can't see this going into anything else than the current
>>> mainline, jdk/jdk i.e. JDK 11. Since the issue is trivially avoided
>>> by using --disable-warnings-as-errors, I hardly see that it warrants
>>> a backport.
>>
>> It's pointless in JDK 11 as we're not going to claim support for gcc
>> 4.8.5.
>>
>> The issue is that out-of-the-box if you are building 8u or 9 and use
>> gcc 4.8.5, which is supposed to be a valid compiler to use based on
>> the wiki, then it fails because of this gcc bug, unless you disable
>> warnings-as-errors. So either we put in a workaround for the bug or we
>> update to the build docs (and/or the wiki) to make it very clear that
>> you may need to disable warnings-as-errors (something there is no
>> mention of in the build doc in 9).
>>
>> David
>> -
>>
>>> /Magnus
>>>
>>> On 2018-01-23 14:44, Adam Farley8 wrote:
 Hi All,

 All: I think I responded to everyone below. Please could a committer or
 author raise a bug and, if people are happy with this ch

Re: Proposal: Make custom extension point additions

[Andrew Leonard]

Thanks Erik,
I have moved the "post" hooks after the ###'s as you mentioned and 
similarly to the end for GensrcVarHandles.gmk. Here is the new hg diff -g 
patch, I have built it with the latest jdk head and run the jtreg tests 
successfully.
Cheers
Andrew

diff --git a/make/common/SetupJavaCompilers.gmk 
b/make/common/SetupJavaCompilers.gmk
--- a/make/common/SetupJavaCompilers.gmk
+++ b/make/common/SetupJavaCompilers.gmk
@@ -26,13 +26,16 @@
 ifndef _SETUP_GMK
 _SETUP_GMK := 1
 
+# Include custom extension hook
+$(eval $(call IncludeCustomExtension, common/SetupJavaCompilers.gmk))
+
 include JavaCompilation.gmk
 
-DISABLE_WARNINGS := 
-Xlint:all,-deprecation,-removal,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally
+DISABLE_WARNINGS ?= 
-Xlint:all,-deprecation,-removal,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally
 
 # If warnings needs to be non-fatal for testing purposes use a command 
like:
 # make JAVAC_WARNINGS="-Xlint:all -Xmaxwarns 1"
-JAVAC_WARNINGS := -Xlint:all -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.
diff --git a/make/gensrc/GensrcVarHandles.gmk 
b/make/gensrc/GensrcVarHandles.gmk
--- a/make/gensrc/GensrcVarHandles.gmk
+++ b/make/gensrc/GensrcVarHandles.gmk
@@ -168,3 +168,7 @@
   $(eval $(call GenerateVarHandleByteArray,VAR_HANDLE_BYTE_ARRAY_$t,$t)))
 
 GENSRC_JAVA_BASE += $(GENSRC_VARHANDLES)
+
+# Include custom extension post hook
+$(eval $(call IncludeCustomExtension, gensrc/GensrcVarHandles-post.gmk))
+
diff --git a/make/lib/Lib-java.management.gmk 
b/make/lib/Lib-java.management.gmk
--- a/make/lib/Lib-java.management.gmk
+++ b/make/lib/Lib-java.management.gmk
@@ -70,3 +70,7 @@
 TARGETS += $(BUILD_LIBMANAGEMENT)
 
 

+
+# Include custom extension post hook
+$(eval $(call IncludeCustomExtension, lib/Lib-java.management-post.gmk))
+
diff --git a/make/lib/Lib-jdk.management.gmk 
b/make/lib/Lib-jdk.management.gmk
--- a/make/lib/Lib-jdk.management.gmk
+++ b/make/lib/Lib-jdk.management.gmk
@@ -80,3 +80,7 @@
 TARGETS += $(BUILD_LIBMANAGEMENT_EXT)
 
 

+
+# Include custom extension post hook
+$(eval $(call IncludeCustomExtension, lib/Lib-jdk.management-post.gmk))
+





Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leon...@uk.ibm.com 




From:   Erik Joelsson 
To: Andrew Leonard , 
build-dev@openjdk.java.net
Date:   31/01/2018 17:40
Subject:Re: Proposal: Make custom extension point additions



Hello Andrew,

This suggestion looks reasonable to me. Just a minor note on the 
placement of the post hooks. Especially in the Lib-* files, each 
individual library, or link entity, is put within ### separator lines. 
In the two files you modified, since there is only one library declared, 
this isn't as apparent. I would prefer if the post hook came after all 
the declared library sections instead of inside one of them. The Gensrc 
file is more of a snowflake so the placement is reasonable there.

/Erik


On 2018-01-31 03:21, Andrew Leonard wrote:
> Hi,
> I would like to find a sponsor for this change please?
> To support certain extension capabilities I would like to propose the
> following patch to the following make files, summary of changes:
>  M make/common/SetupJavaCompilers.gmk
>  ==> Add IncludeCustomExtension hook and allow custom override 
of
> DISABLE_WARNINGS and JAVAC_WARNINGS
>  M make/gensrc/GensrcVarHandles.gmk
>  ==> Add IncludeCustomExtension "post" hook
>  M make/lib/Lib-java.management.gmk
>  ==> Add IncludeCustomExtension "post" hook
>  M make/lib/Lib-jdk.management.gmk
>  ==> Add IncludeCustomExtension "post" hook
>
> Many thanks,
> Andrew
>
> hg diff -g output:
> diff --git a/make/common/SetupJavaCompilers.gmk
> b/make/common/SetupJavaCompilers.gmk
> --- a/make/common/SetupJavaCompilers.gmk
> +++ b/make/common/SetupJavaCompilers.gmk
> @@ -26,13 +26,16 @@
>   ifndef _SETUP_GMK
>   _SETUP_GMK := 1
> 
> +# Include custom extension hook
> +$(eval $(call IncludeCustomExtension, common/SetupJavaCompilers.gmk))
> +
>   include JavaCompilation.gmk
> 
> -DISABLE_WARNINGS :=
> 
-Xlint:all,-deprecation,-removal,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally
> +DISABLE_WARNINGS ?=
> 
-Xlint:all,-deprecation,-removal,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally
> 
>   # If warnings needs to be non-fatal for testing purposes use a command
> like:
>   # make JAVAC_WARNINGS="-Xlint:all -Xmaxwarns 1"
> -JAVAC_WARNINGS := -Xlint:all -Werror
> +JAVAC_WARNINGS 

Re: RFR: JDK-8195689 Remove generated-configure.sh and instead use autoconf

[Erik Joelsson]

This version looks good to me.

/Erik


On 2018-01-25 13:33, Magnus Ihse Bursie wrote:

On 2018-01-18 19:37, Erik Joelsson wrote:

Hello Magnus,

Nice to see this finally happening!

Thanks!



In building.md, when getting autoconf for Cygwin, I believe you also 
need the autoconf wrapper scripts package. 
Hm, well, no, it's the other way around. "autoconf" is the name of the 
cygwin "autoconf wrapper scripts" package. It depends on "m4", 
"autoconf2.69" (or whatever), etc. I have verified that just 
installing "autoconf" will be enough, and will pull in all needed 
dependencies.


Perhaps it's also worth mentioning that you can download the autoconf 
src and build/install from there?
Well, I'm already giving a link to 
http://www.gnu.org/software/autoconf in the build readme. I'm not sure 
if it's helpful for anyone to download the autoconf source by 
themselves. Most users will have it available prebuilt. And if not, 
you'll also most likely need to pull down and build m4, and that's 
trickier. The reason why we used to download autoconf and build it 
from source was to make sure that we got the exactly right version, 
but that only made sense when we checked in the 
generated-configure.sh. (And this worked fine for us, since we had m4...)


In jib-profiles.js, you need to use build_platform instead of 
target_platform when creating the module name for the dependency. 

Good point. Fixed.

I would also like if you added the dependency on the other main 
profiles as well. At least linux-x86, linux-arm64 and windows-x86 are 
still possible to build and should work fine with this. For 
solaris-x64 you would need to generate the package for it to work.

Sure.


The TMPDIR logic looks weird. Are you unconditionally setting it to 
/cygdrive/t/...? That's a valid dir in our build farm, but not on my 
local windows box:


mkdir: cannot create directory ‘/cygdrive/t’: No such file or directory
autom4te: cannot create 
/cygdrive/t/workspace/.build/tmpdir/am4t7009.7040: No such file or 
directory
 at 
/cygdrive/c/cygwin64/var/tmp/jib-erik/install/jpg/infra/builddeps/autoconf-windows_x64/2.69+1.0.1/autoconf-windows_x64-2.69+1.0.1.tar.gz/usr/bin/autom4te 
line 954.

Error: Failed to generate runnable configure script

Yeah, that was broken by design. :-(

Some offline discussion later, it turned out that the reason for the 
trouble was mismatch between cygwin-32 and cygwin-64. I've solved this 
by generating two different packages, for cygwin-32 and cygwin-64. 
I've also made some other minor fixes to the build script, e.g. using 
perl instead of sed due to the braindead sed being available on 
solaris. :(


Updated webrev:
http://cr.openjdk.java.net/~ihse/JDK-8195689-remove-generated-configure/webrev.02/ 



/Magnus




/Erik


On 2018-01-18 05:28, Magnus Ihse Bursie wrote:
Currently, we require all developers who modify the configure script 
to run autoconf locally, to update the generated-configure.sh 
script, which is then checked in. This is the only instance of 
checked in "compiled" code in OpenJDK, and this has brought along 
several problems:


* Only a specific version of autoconf, 2.69, can be used, to avoid 
large code changes in the generated file. Unfortunately, Ubuntu 
ships a version of autoconf that claims to be 2.69 but is actually 
heavily patched. This requires all Ubuntu users to compiler their 
own autoconf from source.


* The Oracle JDK closed sources has a closed version that needs to 
be updated. In practice, this has meant that all non-Oracle 
developers, need an Oracle sponsor for patches modifying the 
configure script.


* If the configure script is not properly updated, the build will 
fail. The same happens on the Oracle side if the closed version is 
not in sync with the open version. It is easy to miss re-generating 
the script after the last fix of a typo in the comments in an .m4 
file...


* Merging between two changes containing configure modifications is 
almost impossible. In practice, the entire generated-configure.sh 
needs to be thrown away and regenerated.


The entire benefit of having the file in the repo is to save 
first-time developers the hassle of installing autoconf. On most 
platforms, this is a no-brainer (like "apt install autoconf"), and 
the requirement is similar to other open source projects using 
autoconf and "./configure". It's just not worth it.


Bug: https://bugs.openjdk.java.net/browse/JDK-8195689
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8195689-remove-generated-configure/webrev.01


/Magnus

Re: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW()

[Gary Adams]

Here's a revised webrev

  http://cr.openjdk.java.net/~gadams/8080990/webrev.01/index.html

Still testing ...

Using shutdown() fixed problems reported by the 
java/nio/channelSocketChannel tests.


I also noticed prior use of getaddrinfo for "localhost" was not calling 
freeaddrinfo.


...

On 2/1/18, 6:16 AM, gary.ad...@oracle.com wrote:

First pass over the code I disabled the compilation flag and then
did quick substitution for the easier functions. I commented out the
WSASendDisconnect calls so I could see what tests would fail if
the function was just removed. I have a replacement now that uses
"shutdown(fd,SD_SEND)", but I still have a few more test failures to
investigate.

I updated the error message text for "getaddrinfo".

I'll post a revised webrev after the 4 jshell errors are corrected.


On 2/1/18 3:11 AM, Langer, Christoph wrote:

Hi Gary,

I was having a look at your changes.

I'm wondering what the reason is behind uncommenting 
WSASendDisconnect in Java_sun_nio_ch_SocketDispatcher_preClose0 of 
file SocketDispatcher.c? And in dbgsysSocketClose?


In socketTransport.c, line:
 331 setLastError(0, "gethostbyname: unknown host");
you should change the description text of the error to getaddrinfo 
instead of gethostbyname.


Best regards
Christoph



-Original Message-
From: build-dev [mailto:build-dev-boun...@openjdk.java.net] On Behalf 
Of Gary Adams

Sent: Donnerstag, 25. Januar 2018 19:47
To: OpenJDK Serviceability ; 
OpenJDK Build ; OpenJDK Networking 

Subject: RFR: JDK-8080990: libdt_socket/socket_md.c(202) : warning 
C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW()


Here's a first pass attempt to remove the 
-D_WINSOCK_DEPRECATED_NO_WARNINGS

build flag and update the winsock deprecated functions.

Issue: https://bugs.openjdk.java.net/browse/JDK-8080990
Webrev: http://cr.openjdk.java.net/~gadams/8080990/

These are the initial deprecated functions updated:
 gethostbyname -> getaddrinfo
 inet_addr -> inet_pton
 inet_ntoa -> inet_ntop

I'm not sure how to replace the existing WSASendDisconnect calls.
It's not clear that it actually provides a graceful disconnect.

Re: RFR: JDK-8196524: Align MaxRAMPercentage settings between open and closed

[Tim Bell]

Erik:

Looks good to me as well.  Thanks.

/Tim


Looks fine.

Thanks,
David

On 1/02/2018 10:29 AM, Erik Joelsson wrote:

New webrev addressing concerns from both Tim and David.

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

/Erik

On 2018-01-31 15:52, Erik Joelsson wrote:

An internal test at Oracle is failing because of a faulty shell
expression in a makefile for calculating the value for
MaxRAMPercentage. We already have such a calculation in
TestCommon.gmk so we should just use that, but it needs to be
exported in a separate variable to be able to do so.

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

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

/Erik

Re: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW()

[Gary Adams]

On 2/1/18, 6:59 AM, Langer, Christoph wrote:

But WSASendDisconnect isn't deprecated, right? So you wanted to get rid of it? 
I still don't see the reason...

vs2013 include/um/winsock2.h has WSASendDisconnect deprecated.

.../src/jdk.jdwp.agent/windows/native/libdt_socket/socket_md.c(230) : 
error C2220: warning treated as error - no 'object' file generated
.../src/jdk.jdwp.agent/windows/native/libdt_socket/socket_md.c(230) : 
warning C4996: 'WSASendDisconnect': Use WSASend() instead or define 
_WINSOCK_DEPRECATED_NO_WARNINGS to disable deprecated API warnings

Re: [OpenJDK 2D-Dev] RFR: Bug Pending: Build fails to compile jchuff.c

[Adam Farley8]

> On 02/01/2018 12:36 PM, Adam Farley8 wrote:
>> After doing some experimenting, I've discovered the problem isn't 
limited to
>> SLES, or gcc 4.8.5, or zLinux.
>> 
>> (...) 
>> Thoughts?
> I think the problem is more that if you are trying to silence warnings,
> you will end up being busy for a very long time since there are simply
> too many possible configurations out there  [1].

Unfortunately it's not just a warning, it's a build-killer.

Across those platforms, in those configurations, this is the only warning 
which causes the build to fail. Adding array-bounds to 
DISABLED_WARNINGS_gcc
suppresses this warning-turned-error, and the builds then run and pass.

>
> For this reason, both Debian and openSUSE/SLE [2] build OpenJDK with the
> configure parameter "--disable-warnings-as-errors".

--disable-warnings-as-errors (in the configure step) can work around this 
problem, 
but then we need to add it to the relevant documentation, and it 
complicates the 
build process a little bit more from the user's POV. In my world, "bash 
./configure"
should be enough.

I like to keep things simple. :)

- Adam

>
> Adrian
>
>> [1] 
https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_hotspot-2Ddev_2018-2DJanuary_029754.html&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=DL2no3G3wg34U0Tl9cbhAcWOQVVU4mv-0EiiF2QNh5U&s=0uzfk9CUqR2GtWgwtbQFBs7zFHnAs6hwM-LGYDMdeHs&e=
>> [2] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__build.opensuse.org_package_view-5Ffile_openSUSE-3AFactory_java-2D10-2Dopenjdk_java-2D10-2Dopenjdk.spec-3Fexpand-3D1&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=DL2no3G3wg34U0Tl9cbhAcWOQVVU4mv-0EiiF2QNh5U&s=9NoPxdwrV4dfjgB4SpDpLgLApTLCTURy6xwVUU5LS6k&e=
>

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: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW()

[Langer, Christoph]

But WSASendDisconnect isn't deprecated, right? So you wanted to get rid of it? 
I still don't see the reason...

-Original Message-
From: gary.ad...@oracle.com [mailto:gary.ad...@oracle.com] 
Sent: Donnerstag, 1. Februar 2018 12:17
To: Langer, Christoph ; OpenJDK Serviceability 
; OpenJDK Build 
; OpenJDK Networking 
Subject: Re: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 
'gethostbyname': Use getaddrinfo() or GetAddrInfoW()

First pass over the code I disabled the compilation flag and then
did quick substitution for the easier functions. I commented out the
WSASendDisconnect calls so I could see what tests would fail if
the function was just removed. I have a replacement now that uses
"shutdown(fd,SD_SEND)", but I still have a few more test failures to
investigate.

I updated the error message text for "getaddrinfo".

I'll post a revised webrev after the 4 jshell errors are corrected.


On 2/1/18 3:11 AM, Langer, Christoph wrote:
> Hi Gary,
>
> I was having a look at your changes.
>
> I'm wondering what the reason is behind uncommenting WSASendDisconnect in 
> Java_sun_nio_ch_SocketDispatcher_preClose0 of file SocketDispatcher.c? And in 
> dbgsysSocketClose?
>
> In socketTransport.c, line:
>  331 setLastError(0, "gethostbyname: unknown host");
> you should change the description text of the error to getaddrinfo instead of 
> gethostbyname.
>
> Best regards
> Christoph
>
>
>
> -Original Message-
> From: build-dev [mailto:build-dev-boun...@openjdk.java.net] On Behalf Of Gary 
> Adams
> Sent: Donnerstag, 25. Januar 2018 19:47
> To: OpenJDK Serviceability ; OpenJDK 
> Build ; OpenJDK Networking 
> 
> Subject: RFR: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 
> 'gethostbyname': Use getaddrinfo() or GetAddrInfoW()
>
> Here's a first pass attempt to remove the -D_WINSOCK_DEPRECATED_NO_WARNINGS
> build flag and update the winsock deprecated functions.
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8080990
> Webrev: http://cr.openjdk.java.net/~gadams/8080990/
>
> These are the initial deprecated functions updated:
>  gethostbyname -> getaddrinfo
>  inet_addr -> inet_pton
>  inet_ntoa -> inet_ntop
>
> I'm not sure how to replace the existing WSASendDisconnect calls.
> It's not clear that it actually provides a graceful disconnect.
>
>

Re: [OpenJDK 2D-Dev] RFR: Bug Pending: Build fails to compile jchuff.c

[John Paul Adrian Glaubitz]

On 02/01/2018 12:36 PM, Adam Farley8 wrote:

After doing some experimenting, I've discovered the problem isn't limited to
SLES, or gcc 4.8.5, or zLinux.

(...) 
Thoughts?

I think the problem is more that if you are trying to silence warnings,
you will end up being busy for a very long time since there are simply
too many possible configurations out there  [1].

For this reason, both Debian and openSUSE/SLE [2] build OpenJDK with the
configure parameter "--disable-warnings-as-errors".

Adrian


[1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-January/029754.html
[2] 
https://build.opensuse.org/package/view_file/openSUSE:Factory/java-10-openjdk/java-10-openjdk.spec?expand=1


--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [OpenJDK 2D-Dev] RFR: Bug Pending: Build fails to compile jchuff.c

[Adam Farley8]

Hi All,

After doing some experimenting, I've discovered the problem isn't limited 
to 
SLES, or gcc 4.8.5, or zLinux.

Platforms affected: zLinux, ppcle Linux
Platforms not affected: x86 Linux

gcc versions affected: 4.8.5, 5.4.0
gcc versions unaffected: 7.2.1

linux variations affected: Ubuntu, SLES
E.g. when I told SLES 12 (zLinux) to install gcc, it installed 5.4.0.

All this tells me that, if we intent to encourage SLES 12 users to build
Java 11, we need this warning suppression hard coded. There are ways to
do "greater than"s and "first character in"s in make, but they require 
either shell commands, or more dollar signs than you can shake a stick at.

I propose we hard code "array-bounds" into javajpeg's 
DISABLED_WARNINGS_gcc
for all java versions, and move on. 

On the basis that gcc 7.2.1 produces a different error message when an
array-bounds problem occurs (e.g. frog[-1] produces the warning
"error: ‘frog[-7]’ is used uninitialized in this function"), I don't see
leaving array-bounds in DISABLED_WARNINGS_gcc as a problem.

Thoughts?

Best Regards

Adam Farley

> The claim on the wiki was made by Volker on July 13 2017. It was done on 

> SuSE linux while the reported problem is on zLinux. Maybe they have 
> different vendor specific patches in their respective gcc builds? Is SAP 

> still able to build without --disable-warnings-as-errors? This wiki is 
> supposed to be a community effort.
>
> /Erik
>
>
>On 2018-01-24 16:37, David Holmes wrote:
>> Hi Magnus,
>>
>> On 25/01/2018 9:55 AM, Magnus Ihse Bursie wrote:
>>> I'm not sure I'm able to follow where this discussion is heading, but 
>>> at the very least I'd like to chime in on the patch below:
>>>
>>> I don't like how the entire DISABLED_WARNINGS_gcc line is lifted out. 
>>> A better solution is something like this:
>>>
>>> ifeq ($(CC_VERSION_NUMBER), 4.8.5)
>>>   #Turn off array-bounds warnings for libjava compilation because 
>>> jchuff.c
>>>   #fails to compile on gcc 4.8.5 with a warning that an array is 
>>> potentially
>>>   #out of bounds. This kills a warnings=errors build.
>>>   LIBJAVAJPEG_DISABLED_WARNINGS_gcc485 := array-bounds
>>> endif
>>> ...
>>>  DISABLED_WARNINGS_gcc := clobbered 
>>> $(LIBJAVAJPEG_DISABLED_WARNINGS_gcc485), \
>>>
>>> I also can't see this going into anything else than the current 
>>> mainline, jdk/jdk i.e. JDK 11. Since the issue is trivially avoided 
>>> by using --disable-warnings-as-errors, I hardly see that it warrants 
>>> a backport.
>>
>> It's pointless in JDK 11 as we're not going to claim support for gcc 
>> 4.8.5.
>>
>> The issue is that out-of-the-box if you are building 8u or 9 and use 
>> gcc 4.8.5, which is supposed to be a valid compiler to use based on 
>> the wiki, then it fails because of this gcc bug, unless you disable 
>> warnings-as-errors. So either we put in a workaround for the bug or we 
>> update to the build docs (and/or the wiki) to make it very clear that 
>> you may need to disable warnings-as-errors (something there is no 
>> mention of in the build doc in 9).
>>
>> David
>> -
>>
>>> /Magnus
>>>
>>> On 2018-01-23 14:44, Adam Farley8 wrote:
 Hi All,

 All: I think I responded to everyone below. Please could a committer 
or
 author raise a bug and, if people are happy with this change, line 
 it up
 for contribution to JDKs 8-11 (assuming 4.8.5 is still the 
 recommended gcc
 for JDK10 and 11 on SUSE sles)?

 Erik: One toolchain-specific change, as requested. This was tested 
 on JDK9,
 so please apply an offset of -1 to the line numbers before applying 
 to JDK10.

 --- Start of Diff ---

 diff --git a/make/lib/Awt2dLibraries.gmk 
b/make/lib/Awt2dLibraries.gmk
 --- a/make/lib/Awt2dLibraries.gmk
 +++ b/make/lib/Awt2dLibraries.gmk
 @@ -482,6 +482,14 @@
BUILD_LIBJAVAJPEG_HEADERS := $(addprefix -I, $(LIBJAVAJPEG_SRC))
  endif

 +LIBJAVAJPEG_DISABLED_WARNINGS_gcc := clobbered
 +ifeq ($(CC_VERSION_NUMBER), 4.8.5)
 +  #Turn off array-bounds warnings for libjava compilation because 
 jchuff.c
 +  #fails to compile on gcc 4.8.5 with a warning that an array is 
 potentially
 +  #out of bounds. This kills a warnings=errors build.
 +  LIBJAVAJPEG_DISABLED_WARNINGS_gcc := clobbered array-bounds
 +endif
 +
  $(eval $(call SetupNativeCompilation,BUILD_LIBJAVAJPEG, \
  LIBRARY := javajpeg, \
  OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \
 @@ -491,7 +499,7 @@
  CFLAGS := $(CFLAGS_JDKLIB) $(BUILD_LIBJAVAJPEG_HEADERS) \
  $(LIBJAVA_HEADER_FLAGS) \
  -I$(SUPPORT_OUTPUTDIR)/headers/java.desktop, \
 -DISABLED_WARNINGS_gcc := clobbered, \
 +DISABLED_WARNINGS_gcc := $(LIBJAVAJPEG_DISABLED_WARNINGS_gcc), \
  MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libjpeg/mapfile-vers, \
  LDFLAGS := $(LDFLAGS_JDKLIB) \
  $(call SET_SHARED_LIBRARY_

Re: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW()

[gary.ad...@oracle.com]

First pass over the code I disabled the compilation flag and then
did quick substitution for the easier functions. I commented out the
WSASendDisconnect calls so I could see what tests would fail if
the function was just removed. I have a replacement now that uses
"shutdown(fd,SD_SEND)", but I still have a few more test failures to
investigate.

I updated the error message text for "getaddrinfo".

I'll post a revised webrev after the 4 jshell errors are corrected.


On 2/1/18 3:11 AM, Langer, Christoph wrote:

Hi Gary,

I was having a look at your changes.

I'm wondering what the reason is behind uncommenting WSASendDisconnect in 
Java_sun_nio_ch_SocketDispatcher_preClose0 of file SocketDispatcher.c? And in 
dbgsysSocketClose?

In socketTransport.c, line:
 331 setLastError(0, "gethostbyname: unknown host");
you should change the description text of the error to getaddrinfo instead of 
gethostbyname.

Best regards
Christoph



-Original Message-
From: build-dev [mailto:build-dev-boun...@openjdk.java.net] On Behalf Of Gary 
Adams
Sent: Donnerstag, 25. Januar 2018 19:47
To: OpenJDK Serviceability ; OpenJDK Build 
; OpenJDK Networking 
Subject: RFR: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 
'gethostbyname': Use getaddrinfo() or GetAddrInfoW()

Here's a first pass attempt to remove the -D_WINSOCK_DEPRECATED_NO_WARNINGS
build flag and update the winsock deprecated functions.

Issue: https://bugs.openjdk.java.net/browse/JDK-8080990
Webrev: http://cr.openjdk.java.net/~gadams/8080990/

These are the initial deprecated functions updated:
 gethostbyname -> getaddrinfo
 inet_addr -> inet_pton
 inet_ntoa -> inet_ntop

I'm not sure how to replace the existing WSASendDisconnect calls.
It's not clear that it actually provides a graceful disconnect.

RE: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW()

[Langer, Christoph]

Hi Gary,

I was having a look at your changes.

I'm wondering what the reason is behind uncommenting WSASendDisconnect in 
Java_sun_nio_ch_SocketDispatcher_preClose0 of file SocketDispatcher.c? And in 
dbgsysSocketClose?

In socketTransport.c, line:
331 setLastError(0, "gethostbyname: unknown host");
you should change the description text of the error to getaddrinfo instead of 
gethostbyname.

Best regards
Christoph



-Original Message-
From: build-dev [mailto:build-dev-boun...@openjdk.java.net] On Behalf Of Gary 
Adams
Sent: Donnerstag, 25. Januar 2018 19:47
To: OpenJDK Serviceability ; OpenJDK Build 
; OpenJDK Networking 
Subject: RFR: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 
'gethostbyname': Use getaddrinfo() or GetAddrInfoW()

Here's a first pass attempt to remove the -D_WINSOCK_DEPRECATED_NO_WARNINGS
build flag and update the winsock deprecated functions.

   Issue: https://bugs.openjdk.java.net/browse/JDK-8080990
   Webrev: http://cr.openjdk.java.net/~gadams/8080990/

These are the initial deprecated functions updated:
gethostbyname -> getaddrinfo
inet_addr -> inet_pton
inet_ntoa -> inet_ntop

I'm not sure how to replace the existing WSASendDisconnect calls.
It's not clear that it actually provides a graceful disconnect.

Re: RFR: JDK-8196524: Align MaxRAMPercentage settings between open and closed

[David Holmes]

Looks fine.

Thanks,
David

On 1/02/2018 10:29 AM, Erik Joelsson wrote:

New webrev addressing concerns from both Tim and David.

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

/Erik

On 2018-01-31 15:52, Erik Joelsson wrote:
An internal test at Oracle is failing because of a faulty shell 
expression in a makefile for calculating the value for 
MaxRAMPercentage. We already have such a calculation in TestCommon.gmk 
so we should just use that, but it needs to be exported in a separate 
variable to be able to do so.


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

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

/Erik