Re: libjava/net/natInetAddress.cc uses inet_pton, not declared on irix6.2

Re: libjava/net/natInetAddress.cc uses inet_pton, not declared on irix6.2

[Kaveh R. Ghazi]

 > From: Bryce McKinlay <bryce@waitaki.otago.ac.nz>
 > 
 > On Wednesday, April 25, 2001, at 01:44  PM, Kaveh R. Ghazi wrote:
 > 
 > > Actually, I tried Bryce's suggestion to check HAVE_INET6 (which is
 > > undefined since sockaddr_in6 isn't there) and that was enough to allow
 > > the build to continue so I'm happy with it.  It crashed later on in
 > > the libjava build process but that's a separate issue for which I'll
 > > send a separate report.  We're making progress.
 > 
 > Yeah, it still dies in the final link on older Irix machines due to the 
 > command line length problem. We've almost almost fixed this using the 
 > libtool incremental linking and objectlist passing, but there is still a 
 > problem since the "echo" command used when making the objectlist file is 
 > too long.
 > 
 > For all the gory details, you can look at:
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1736&database=gcc

Yes that was gory. :-)

Unfortunately, my problem was an abort in rtlanal.c:2692, totally
unrelated to the above issue.  I'm going to poke at it a bit to make
sure it wasn't spurious and then file a report.

--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions

Re: libjava/net/natInetAddress.cc uses inet_pton, not declared on irix6.2

[Bryce McKinlay]

On Wednesday, April 25, 2001, at 01:44  PM, Kaveh R. Ghazi wrote:

> Actually, I tried Bryce's suggestion to check HAVE_INET6 (which is
> undefined since sockaddr_in6 isn't there) and that was enough to allow
> the build to continue so I'm happy with it.  It crashed later on in
> the libjava build process but that's a separate issue for which I'll
> send a separate report.  We're making progress.

Yeah, it still dies in the final link on older Irix machines due to the 
command line length problem. We've almost almost fixed this using the 
libtool incremental linking and objectlist passing, but there is still a 
problem since the "echo" command used when making the objectlist file is 
too long.

For all the gory details, you can look at:
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1736&database=gcc

regards

   [ bryce ]

Re: libjava/net/natInetAddress.cc uses inet_pton, not declared on irix6.2

[Tom Tromey]

>>>>> "Kaveh" == Kaveh R Ghazi <ghazi@caip.rutgers.edu> writes:

Kaveh> Anyway, Ok to install the following on the trunk and branch?

Kaveh> 2001-04-23  Kaveh R. Ghazi  <ghazi@caip.rutgers.edu>
Kaveh> 	* java/net/natInetAddress.cc (java::net::InetAddress::aton):
Kaveh> 	Wrap use of inet_pton in HAVE_INET6.

Kaveh> -#ifdef HAVE_INET_PTON
Kaveh> +#if defined(HAVE_INET_PTON) && defined (HAVE_INET6)

This is missing a space before the first '('.
Other than that pedantic nit, this is great.  Thanks!

Tom

Re: libjava/net/natInetAddress.cc uses inet_pton, not declared on irix6.2

[Kaveh R. Ghazi]

 > From: Tom Tromey <tromey@redhat.com>
 > 
 > >>>>> "Bryce" == Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:
 > 
 > Kaveh> On irix6.2, inet_pton is provided by libc, but is not declared
 > Kaveh> anywhere.
 > 
 > Bryce> inet_pton is the IPv6 counterpart/successor to inet_aton. Its
 > Bryce> use is already protected with an "#ifdef HAVE_INET_PTON" so I'm
 > Bryce> not sure why you get the undefined function error.
 > 
 > The function check in configure finds it because it is a link check.
 > However g++ gives an error because the function is not declared
 > anywhere.

Right.


 > Kaveh, I think the fix depends on your goals.  If you think we'll ever
 > want to use the IPv6 code on Irix 6.2 (I don't know whether the IPv6
 > code in libgcj actually works; I have never tried it or for that
 > matter ever seen a machine using IPv6), then the right fix is to look
 > for the function decl and have a backup decl ready.

I think the IPv6 implementation in irix6.2 is incomplete because
e.g. sockaddr_in6 isn't available, and of course inet_pton isn't
declared.


 > How does the DECL checking infrastructure in gcc compare to what is in
 > the next version of autoconf?  Eventually I imagine we would want to
 > use that.

I think it has a similar result in what cpp macros get defined, (but
uses entirely different internal logic.)


 > Meanwhile, I'm not overly concerned about the shape of the
 > current fix.  Your egrep code is fine by me.
 > Tom

Actually, I tried Bryce's suggestion to check HAVE_INET6 (which is
undefined since sockaddr_in6 isn't there) and that was enough to allow
the build to continue so I'm happy with it.  It crashed later on in
the libjava build process but that's a separate issue for which I'll
send a separate report.  We're making progress.

Anyway, Ok to install the following on the trunk and branch?

		Thanks,
		--Kaveh


2001-04-23  Kaveh R. Ghazi  <ghazi@caip.rutgers.edu>

	* java/net/natInetAddress.cc (java::net::InetAddress::aton):
	Wrap use of inet_pton in HAVE_INET6.

diff -rup ../egcs-CVS20010423/libjava/java/net/natInetAddress.cc egcs-CVS20010423/libjava/java/net/natInetAddress.cc
--- ../egcs-CVS20010423/libjava/java/net/natInetAddress.cc	Fri Nov  3 02:43:06 2000
+++ egcs-CVS20010423/libjava/java/net/natInetAddress.cc	Mon Apr 23 23:07:51 2001
@@ -118,7 +118,7 @@ java::net::InetAddress::aton (jstring ho
       blen = 4;
     }
 #endif
-#ifdef HAVE_INET_PTON
+#if defined(HAVE_INET_PTON) && defined (HAVE_INET6)
   char inet6_addr[16];
   if (len == 0 && inet_pton (AF_INET6, hostname, inet6_addr) > 0)
     {

Re: libjava/net/natInetAddress.cc uses inet_pton, not declared on irix6.2

[Tom Tromey]

>>>>> "Bryce" == Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:

Kaveh> On irix6.2, inet_pton is provided by libc, but is not declared
Kaveh> anywhere.

Bryce> inet_pton is the IPv6 counterpart/successor to inet_aton. Its
Bryce> use is already protected with an "#ifdef HAVE_INET_PTON" so I'm
Bryce> not sure why you get the undefined function error.

The function check in configure finds it because it is a link check.
However g++ gives an error because the function is not declared
anywhere.

Kaveh, I think the fix depends on your goals.  If you think we'll ever
want to use the IPv6 code on Irix 6.2 (I don't know whether the IPv6
code in libgcj actually works; I have never tried it or for that
matter ever seen a machine using IPv6), then the right fix is to look
for the function decl and have a backup decl ready.

How does the DECL checking infrastructure in gcc compare to what is in
the next version of autoconf?  Eventually I imagine we would want to
use that.

Meanwhile, I'm not overly concerned about the shape of the
current fix.  Your egrep code is fine by me.

Tom

Re: libjava/net/natInetAddress.cc uses inet_pton, not declared on irix6.2

[Bryce McKinlay]

"Kaveh R. Ghazi" wrote:

> On irix6.2, inet_pton is provided by libc, but is not declared
> anywhere.  (I don't think this afflicts the primary mips eval
> platform, irix6.5, since no one has reported it, but its possible
> other secondary or tertiary platforms have this problem too.)
>
> Anyway, I'd like to solicit comments on how to approach this.
> E.g. provide a backup decl if one isn't found or nuke inet_pton
> altogether?  (I don't think its a standard function.)  Also, I don't
> know exactly what inet_pton does to consider how to avoid its use.
> (E.g. can't find a man page on x86-linux-gnu.)

inet_pton is the IPv6 counterpart/successor to inet_aton. Its use is already
protected with an "#ifdef HAVE_INET_PTON" so I'm not sure why you get the
undefined function error. Since we currently only call it as a backup when
inet_aton fails, it is quite safe to #ifdef it out on platforms without
complete v6 support. I would say that the proper fix is to fix the
HAVE_INET_PTON configure test? Failing that, if HAVE_INET6 is not defined on
this Irix version you could just protect the call with an #ifdef test for
that as well.

From the glibc docs:

Function: int inet_pton (int af, const char *cp, void *buf)
     This function converts an Internet address (either IPv4 or IPv6) from
presentation (textual) to network (binary) format. af should be either
AF_INET or AF_INET6, as appropriate for the type of address being converted.
cp is a pointer to the input string, and buf is a pointer to a buffer for
the result. It is the caller's responsibility to make sure the buffer is
large enough.

regards

  [ bryce ]

libjava/net/natInetAddress.cc uses inet_pton, not declared on irix6.2

[Kaveh R. Ghazi]

Bootstrapping the trunk on mips-sgi-irix6.2 I get the following error
after the 3-stage when building libjava:

 > libjava/java/net/natInetAddress.cc: In static member function
 >    `static JArray<jbyte>* 
 >    java::net::InetAddress::aton(java::lang::String*)':
 > libjava/java/net/natInetAddress.cc:123: `inet_pton' undeclared (first
 >    use this function)
 > libjava/java/net/natInetAddress.cc:123: (Each undeclared identifier is
 >    reported only once for each function it appears in.)

On irix6.2, inet_pton is provided by libc, but is not declared
anywhere.  (I don't think this afflicts the primary mips eval
platform, irix6.5, since no one has reported it, but its possible
other secondary or tertiary platforms have this problem too.)

Anyway, I'd like to solicit comments on how to approach this.
E.g. provide a backup decl if one isn't found or nuke inet_pton
altogether?  (I don't think its a standard function.)  Also, I don't
know exactly what inet_pton does to consider how to avoid its use.
(E.g. can't find a man page on x86-linux-gnu.)

On the other hand, if we elect to provide the backup decl, there is
currently no infrastructure in libjava to detect missing decls except
for an egrep kludge used for gethostname.  I can replicate that for
inet_pton by egrep'ing in arpa/inet.h or port over the entire DECL
checking infrastructure from the gcc dir.  That's probably overkill.
Its also brittle when you don't have a centralized system.h to ensure
the headers you look in at configure-time are exactly the ones you
include at compile-time.

This is an untested snippet copied from the gethostname fragment in
libjava/configure.in that shows what I'm considering as of now:

   AC_CHECK_FUNCS(inet_pton, [
     AC_DEFINE(HAVE_INET_PTON)
     AC_EGREP_HEADER(inet_pton, arpa/inet.h, [
       AC_DEFINE(HAVE_INET_PTON_DECL)])])

Whatever we come up with will probably have to go on the branch as
well.

Anyway, please opine. :-)

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions