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

[Langer, Christoph]

Hi Gary,

ok, I would agree that a change like globally moving from dbgSysInetAddr to 
something like dbgsysPToN should at least be handled by a different change.

Best regards
Christoph

From: Gary Adams [mailto:gary.ad...@oracle.com]
Sent: Montag, 5. Februar 2018 20:15
To: gary.ad...@oracle.com
Cc: 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()

One more to fix to cover the remaining test failures I was seeing.

Previously, using inet_addr, there was a single -1 return that needed to be 
checked.
Now that we're using inet_pton, there is a -1 and a 0 error return to be 
considered.

My preference would be to leave the dbgSysInetAddr name unchanged and have the 
low level
check for inet_pton errors to simply return the -1 that was previously checked.

This specific issue is about the deprecation of library functions on windows. 
I'd recommend not
upgrading the other platforms at this time until a complete update is done for 
ipv6 support.

I'll post a new webrev when I've retested using the updated inet_pton error 
checking.

...


Hi Gary,





> 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.



The fix looks good. I would think we should rename dbgsysInetAddr to dbgsysPToN 
and use inet_pton also for the Unix/Linux platforms. It would be the better 
choice there as well, though we still only support IPv4 in libdt_socket.



>

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

> freeaddrinfo.



Thanks for spotting/fixing that.



Best regards

Christoph

Re: RFR: 8173401: Update VERSION_FEATURE for JDK 11

[David Holmes]

Thanks Joe!

David

On 6/02/2018 11:32 AM, Joseph D. Darcy wrote:

Ship it :-)

-Joe

On 2/5/2018 5:25 PM, David Holmes wrote:

It's time to increment the actual version to 11 for JDK 11.

Joe Darcy and I have worked through numerous test issues that delayed 
the update and I've been addressing a number of issues in hotspot 
related to obsolete/expired flag warnings. I have tested the update 
with JDK tiers 1-3, and hotspot tiers 1-4. So we should not see any CI 
failures for either JDK or HS pipelines.


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

Change:

--- a/make/autoconf/version-numbers
+++ b/make/autoconf/version-numbers
@@ -25,7 +25,7 @@

 # Default version numbers to use unless overridden by configure

-DEFAULT_VERSION_FEATURE=10
+DEFAULT_VERSION_FEATURE=11
 DEFAULT_VERSION_INTERIM=0
 DEFAULT_VERSION_UPDATE=0
 DEFAULT_VERSION_PATCH=0

Thanks,
David

Re: RFR: 8173401: Update VERSION_FEATURE for JDK 11

[David Holmes]

Thanks Mandy!

David

On 6/02/2018 11:46 AM, mandy chung wrote:

+1 Mandy


On 2/5/18 5:25 PM, David Holmes wrote:

It's time to increment the actual version to 11 for JDK 11.

Joe Darcy and I have worked through numerous test issues that delayed 
the update and I've been addressing a number of issues in hotspot 
related to obsolete/expired flag warnings. I have tested the update 
with JDK tiers 1-3, and hotspot tiers 1-4. So we should not see any CI 
failures for either JDK or HS pipelines.


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

Change:

--- a/make/autoconf/version-numbers
+++ b/make/autoconf/version-numbers
@@ -25,7 +25,7 @@

 # Default version numbers to use unless overridden by configure

-DEFAULT_VERSION_FEATURE=10
+DEFAULT_VERSION_FEATURE=11
 DEFAULT_VERSION_INTERIM=0
 DEFAULT_VERSION_UPDATE=0
 DEFAULT_VERSION_PATCH=0

Thanks,
David

Re: RFR: 8173401: Update VERSION_FEATURE for JDK 11

[mandy chung]

+1 Mandy


On 2/5/18 5:25 PM, David Holmes wrote:

It's time to increment the actual version to 11 for JDK 11.

Joe Darcy and I have worked through numerous test issues that delayed 
the update and I've been addressing a number of issues in hotspot 
related to obsolete/expired flag warnings. I have tested the update 
with JDK tiers 1-3, and hotspot tiers 1-4. So we should not see any CI 
failures for either JDK or HS pipelines.


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

Change:

--- a/make/autoconf/version-numbers
+++ b/make/autoconf/version-numbers
@@ -25,7 +25,7 @@

 # Default version numbers to use unless overridden by configure

-DEFAULT_VERSION_FEATURE=10
+DEFAULT_VERSION_FEATURE=11
 DEFAULT_VERSION_INTERIM=0
 DEFAULT_VERSION_UPDATE=0
 DEFAULT_VERSION_PATCH=0

Thanks,
David

Re: "no tests selected" running tests in the test/jdk directory

[Martin Buchholz]

OK, I did some reading up in doc/testing.md.  I noticed

 TEST_MODE
The test mode (`-agentvm`, `-samevm` or `-othervm`).

but TEST_MODE=-agentvm is rejected - it must be TEST_MODE=agentvm.

I suggest removing the dashes in the doc and perhaps changing the code to
accept and ignore initial dashes.

On Mon, Feb 5, 2018 at 12:22 PM, Martin Buchholz 
wrote:

> Ahh, I had forgotten we are in the middle of a transition to "run-test".
> I need to read doc/testing.md.
>
> On Mon, Feb 5, 2018 at 11:22 AM, Magnus Ihse Bursie <
> magnus.ihse.bur...@oracle.com> wrote:
>
>> Use make run-test TEST="test/jdk" instead.
>>
>> /Magnus
>>
>> > 5 feb. 2018 kl. 19:39 skrev Martin Buchholz :
>> >
>> > if I
>> > cd test/jdk && make all ...
>> > I get
>> >
>> > Test results: no tests selected
>> > ...
>> > Summary: jdk_default
>> > TEST STATS: name=jdk_default  run=0  pass=0  fail=0
>> >
>> > ---
>> >
>> > Also I find I have to define PRODUCT_HOME and JT_HOME as environment
>> > variables - make variables are insufficient
>>
>
>

Re: RFR: 8173401: Update VERSION_FEATURE for JDK 11

[Joseph D. Darcy]

Ship it :-)

-Joe

On 2/5/2018 5:25 PM, David Holmes wrote:

It's time to increment the actual version to 11 for JDK 11.

Joe Darcy and I have worked through numerous test issues that delayed 
the update and I've been addressing a number of issues in hotspot 
related to obsolete/expired flag warnings. I have tested the update 
with JDK tiers 1-3, and hotspot tiers 1-4. So we should not see any CI 
failures for either JDK or HS pipelines.


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

Change:

--- a/make/autoconf/version-numbers
+++ b/make/autoconf/version-numbers
@@ -25,7 +25,7 @@

 # Default version numbers to use unless overridden by configure

-DEFAULT_VERSION_FEATURE=10
+DEFAULT_VERSION_FEATURE=11
 DEFAULT_VERSION_INTERIM=0
 DEFAULT_VERSION_UPDATE=0
 DEFAULT_VERSION_PATCH=0

Thanks,
David

RFR: 8173401: Update VERSION_FEATURE for JDK 11

[David Holmes]

It's time to increment the actual version to 11 for JDK 11.

Joe Darcy and I have worked through numerous test issues that delayed 
the update and I've been addressing a number of issues in hotspot 
related to obsolete/expired flag warnings. I have tested the update with 
JDK tiers 1-3, and hotspot tiers 1-4. So we should not see any CI 
failures for either JDK or HS pipelines.


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

Change:

--- a/make/autoconf/version-numbers
+++ b/make/autoconf/version-numbers
@@ -25,7 +25,7 @@

 # Default version numbers to use unless overridden by configure

-DEFAULT_VERSION_FEATURE=10
+DEFAULT_VERSION_FEATURE=11
 DEFAULT_VERSION_INTERIM=0
 DEFAULT_VERSION_UPDATE=0
 DEFAULT_VERSION_PATCH=0

Thanks,
David

Re: RFR: JDK-8196803: Fix build warnings in jdk libraries with Xcode 9

[Tim Bell]

Erik:



Webrev: http://cr.openjdk.java.net/~erikj/8196803/webrev.01/index.html

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


Looks good.

/Tim

RFR: JDK-8196803: Fix build warnings in jdk libraries with Xcode 9

[Erik Joelsson]

When building with Xcode 9, we get some warnings triggered in jdk 
libraries. This patch tries to fix them. See bug description for more 
details on each of them. In short the following things are addressed:


In src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m, remove 
the check on MAC_OS_X_VERSION_MAX_ALLOWED. I don't think that's 
relevant. The source needs to compile against the headers that are 
present. This was touched on earlier in this thread: 
http://mail.openjdk.java.net/pipermail/build-dev/2017-July/019486.html 
and when going back, it's quite clear to me that the fix done there was 
incorrect.


In src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c, we 
can't modify the source file itself, so here I've added a wrapper for 
zlib.h that rewrites the ZLIB_VERNUM macro to a version that matches 
what's available on the Macosx version we are building for. This type of 
override can be brittle but seems to work OK in this case. While doing 
this, I also refactored the handling of libz cflags and libs. They are 
better set and exported from configure to be globally available in the 
build.


We also get warnings when linking static libraries. These are easily 
fixed by adding the -mmacosx-version-min= arguments on these command 
lines just like we do for linking shared libraries and executables. I 
solved this by setting ARFLAGS and actually use that variable.


Webrev: http://cr.openjdk.java.net/~erikj/8196803/webrev.01/index.html

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

/Erik

Re: The generated-configure.sh script is dead, long live autoconf!

[Erik Joelsson]

Hello,

In that change I bumped the number from 2.61 to 2.67. The original 2.61 
was put there by Fredrik very early in the build-infra conversion and I 
don't know where that came from. The main reason for us to pick just one 
version was because we wanted to avoid large differences in the 
committed generated file. Since we are no longer committing the file, I 
don't see a good reason to enforce a particular version, but we also 
should not change this number until someone has verified that a 
particular version works reasonably well.


It should also be noted that installing autoconf from src is trivially 
simple. The build has very few prerequisites and takes seconds to 
complete. I've never failed on any of the platforms I've tried it on 
over the years.


/Erik


On 2018-02-05 12:14, Magnus Ihse Bursie wrote:

On 2018-02-05 21:05, Magnus Ihse Bursie wrote:

Let's move this discussion to build-dev instead of jdk-dev.

On 2018-02-05 17:30, Thomas Stüfe wrote:

Hi Magnus,

On Mon, Feb 5, 2018 at 9:21 AM, Magnus Ihse Bursie 
> wrote:


     With the new solution, the exact version of autoconf does
    not matter. 


It seems to matter. I now get:

Using autoconf at /usr/bin/autoconf [autoconf (GNU Autoconf) 2.63]
stdin:33: error: Autoconf version 2.69 or higher is required
stdin:33: the top level
autom4te: /usr/bin/m4 failed with exit status: 63

Do we actually need this strict check for the autoconf version? Is 
there a way to disable the check and retry with my old version?


The check is enforced by
AC_PREREQ([2.69])

in the top of make/autoconf/configure.ac.

You could try removing it and see what happens. In the "best" case 
you'll get an error message when autoconf tries to generate the file, 
then we know for certain that it does not work. :-) Otherwise, you'll 
have to test the generated configure file more thoroughly to ensure 
that it really works.


I'm quite certain that older versions (and believe me, everything 
prior to 2.69 is *ancient*) did not work at all, and that was the 
reason we added that requirement.
Some code archeology gave me this: 
https://bugs.openjdk.java.net/browse/JDK-8023957


It seems that we at least supported 2.67 at the time, but we 
executable was not commonly (?) named "autoconf" so we couldn't 
autodetect it. Still can't say about 2.63 though.




/Magnus



I would dislike for this to be a frequent error now - unfortunately, 
we have some build environments where getting the latest GNU tools 
is more work than just running an installer.


Thanks, Thomas


    The build documentation has been updated to reflect this change.

    /Magnus

Re: "no tests selected" running tests in the test/jdk directory

[Martin Buchholz]

Ahh, I had forgotten we are in the middle of a transition to "run-test".
I need to read doc/testing.md.

On Mon, Feb 5, 2018 at 11:22 AM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:

> Use make run-test TEST="test/jdk" instead.
>
> /Magnus
>
> > 5 feb. 2018 kl. 19:39 skrev Martin Buchholz :
> >
> > if I
> > cd test/jdk && make all ...
> > I get
> >
> > Test results: no tests selected
> > ...
> > Summary: jdk_default
> > TEST STATS: name=jdk_default  run=0  pass=0  fail=0
> >
> > ---
> >
> > Also I find I have to define PRODUCT_HOME and JT_HOME as environment
> > variables - make variables are insufficient
>

Re: The generated-configure.sh script is dead, long live autoconf!

[Magnus Ihse Bursie]

On 2018-02-05 21:05, Magnus Ihse Bursie wrote:

Let's move this discussion to build-dev instead of jdk-dev.

On 2018-02-05 17:30, Thomas Stüfe wrote:

Hi Magnus,

On Mon, Feb 5, 2018 at 9:21 AM, Magnus Ihse Bursie 
> wrote:


     With the new solution, the exact version of autoconf does
    not matter. 


It seems to matter. I now get:

Using autoconf at /usr/bin/autoconf [autoconf (GNU Autoconf) 2.63]
stdin:33: error: Autoconf version 2.69 or higher is required
stdin:33: the top level
autom4te: /usr/bin/m4 failed with exit status: 63

Do we actually need this strict check for the autoconf version? Is 
there a way to disable the check and retry with my old version?


The check is enforced by
AC_PREREQ([2.69])

in the top of make/autoconf/configure.ac.

You could try removing it and see what happens. In the "best" case 
you'll get an error message when autoconf tries to generate the file, 
then we know for certain that it does not work. :-) Otherwise, you'll 
have to test the generated configure file more thoroughly to ensure 
that it really works.


I'm quite certain that older versions (and believe me, everything 
prior to 2.69 is *ancient*) did not work at all, and that was the 
reason we added that requirement.
Some code archeology gave me this: 
https://bugs.openjdk.java.net/browse/JDK-8023957


It seems that we at least supported 2.67 at the time, but we executable 
was not commonly (?) named "autoconf" so we couldn't autodetect it. 
Still can't say about 2.63 though.




/Magnus



I would dislike for this to be a frequent error now - unfortunately, 
we have some build environments where getting the latest GNU tools is 
more work than just running an installer.


Thanks, Thomas


    The build documentation has been updated to reflect this change.

    /Magnus

Re: The generated-configure.sh script is dead, long live autoconf!

[Magnus Ihse Bursie]

Let's move this discussion to build-dev instead of jdk-dev.

On 2018-02-05 17:30, Thomas Stüfe wrote:

Hi Magnus,

On Mon, Feb 5, 2018 at 9:21 AM, Magnus Ihse Bursie 
> 
wrote:


 With the new solution, the exact version of autoconf does
not matter. 


It seems to matter. I now get:

Using autoconf at /usr/bin/autoconf [autoconf (GNU Autoconf) 2.63]
stdin:33: error: Autoconf version 2.69 or higher is required
stdin:33: the top level
autom4te: /usr/bin/m4 failed with exit status: 63

Do we actually need this strict check for the autoconf version? Is 
there a way to disable the check and retry with my old version?


The check is enforced by
AC_PREREQ([2.69])

in the top of make/autoconf/configure.ac.

You could try removing it and see what happens. In the "best" case 
you'll get an error message when autoconf tries to generate the file, 
then we know for certain that it does not work. :-) Otherwise, you'll 
have to test the generated configure file more thoroughly to ensure that 
it really works.


I'm quite certain that older versions (and believe me, everything prior 
to 2.69 is *ancient*) did not work at all, and that was the reason we 
added that requirement.


/Magnus



I would dislike for this to be a frequent error now - unfortunately, 
we have some build environments where getting the latest GNU tools is 
more work than just running an installer.


Thanks, Thomas


The build documentation has been updated to reflect this change.

/Magnus

Re: "no tests selected" running tests in the test/jdk directory

[Magnus Ihse Bursie]

Use make run-test TEST="test/jdk" instead. 

/Magnus

> 5 feb. 2018 kl. 19:39 skrev Martin Buchholz :
> 
> if I
> cd test/jdk && make all ...
> I get
> 
> Test results: no tests selected
> ...
> Summary: jdk_default
> TEST STATS: name=jdk_default  run=0  pass=0  fail=0
> 
> ---
> 
> Also I find I have to define PRODUCT_HOME and JT_HOME as environment
> variables - make variables are insufficient

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

[Gary Adams]

One more to fix to cover the remaining test failures I was seeing.

Previously, using inet_addr, there was a single -1 return that needed to 
be checked.
Now that we're using inet_pton, there is a -1 and a 0 error return to be 
considered.


My preference would be to leave the dbgSysInetAddr name unchanged and 
have the low level
check for inet_pton errors to simply return the -1 that was previously 
checked.


This specific issue is about the deprecation of library functions on 
windows. I'd recommend not
upgrading the other platforms at this time until a complete update is 
done for ipv6 support.


I'll post a new webrev when I've retested using the updated inet_pton 
error checking.


...

Hi Gary,


>/  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.
/
The fix looks good. I would think we should rename dbgsysInetAddr to dbgsysPToN 
and use inet_pton also for the Unix/Linux platforms. It would be the better 
choice there as well, though we still only support IPv4 in libdt_socket.

>/
/>/  I also noticed prior use of getaddrinfo for "localhost" was not calling
/>/  freeaddrinfo.
/
Thanks for spotting/fixing that.

Best regards
Christoph

"no tests selected" running tests in the test/jdk directory

[Martin Buchholz]

if I
cd test/jdk && make all ...
I get

Test results: no tests selected
...
Summary: jdk_default
TEST STATS: name=jdk_default  run=0  pass=0  fail=0

---

Also I find I have to define PRODUCT_HOME and JT_HOME as environment
variables - make variables are insufficient