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

["Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>]

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