I said:
> I'm just about ready to start testing a fix that separately tests
> HAVE_STRUCT_ADDRINFO (the struct decl) and HAVE_GETADDRINFO (the
> function).
I've got this committed; it seems to work on HPUX and Linux, at least.
There is a residual bit of ugliness that should be cleaned up one way or
the other, and that's the dependency on hstrerror() in getaddrinfo.c.
The scorecard AFAICT is:
1. hstrerror() doesn't exist in HPUX 10.20.
2. But it does exist in libbind.a from BIND 9.2.2.
3. It exists but seems to be deprecated in Linux --- the RHL 8 man page
says
The (obsolete) hstrerror() function takes an error number (typically
h_errno) and returns the corresponding message string.
I set up code in getaddrinfo.c to do something reasonable (but, at the
moment, non-internationalized) if HAVE_HSTRERROR isn't defined. But it
blew up on me completely in the HPUX+libbind environment --- what
happens is that configure finds hstrerror in libbind.a, so it defines
HAVE_HSTRERROR, so getaddrinfo.c tries to use that (generating an
annoying "no previous prototype" warning), and then the link fails
anyhow! The reason it fails is that libpgport is linked after libbind,
and since the latter is a static library the necessary module doesn't
get pulled from it.
(This suggests that -lpgport ought to be stuck on the front of LIBS,
not the back, in Makefile.global. What do you think?)
What I've done for the moment is to not test for hstrerror in configure,
so that the non-HAVE_HSTRERROR path is always taken in getaddrinfo.c.
One way we could go from here is to institutionalize that approach.
I think that would require us to figure out how to do internationalization
of strings that appear in this file (which remember can be compiled in
multiple places). If there's a reasonably clean way to do that, I'm
leaning to that approach. The other possibility is to decide to rely on
hstrerror anyway, which will require fixing the link-order problem and
testing to see if we need to provide our own prototype for it.
Comments?
regards, tom lane