Re: [HACKERS] AC_REPLACE_FUNCS([getaddrinfo]) in 8.1.3

2006-02-24 Thread Andrew Dunstan
Tom Lane wrote: Albert Chin [EMAIL PROTECTED] writes: On Sun, Feb 19, 2006 at 11:32:53PM -0500, Tom Lane wrote: Would you try the patch proposed at http://archives.postgresql.org/pgsql-patches/2006-01/msg00299.php Works fine on Tru64 UNIX 4.0D and 5.1. OK,

Re: [HACKERS] AC_REPLACE_FUNCS([getaddrinfo]) in 8.1.3

2006-02-24 Thread Bruce Momjian
Tom Lane wrote: Albert Chin [EMAIL PROTECTED] writes: On Sun, Feb 19, 2006 at 09:56:20PM -0500, Tom Lane wrote: Hmm, where is it then? getaddrinfo is a macro in netdb.h: Yes, we know that. The question was where does the macro point. The solution is to either revert to the 8.1.1

Re: [HACKERS] AC_REPLACE_FUNCS([getaddrinfo]) in 8.1.3

2006-02-20 Thread Tom Lane
Martijn van Oosterhout kleptog@svana.org writes: This test is different, it checks that getaddrinfo has four args. If it doesn't, we don't wanna use it anyway ... regards, tom lane ---(end of broadcast)--- TIP 1: if

Re: [HACKERS] AC_REPLACE_FUNCS([getaddrinfo]) in 8.1.3

2006-02-20 Thread Albert Chin
On Sun, Feb 19, 2006 at 11:32:53PM -0500, Tom Lane wrote: Albert Chin [EMAIL PROTECTED] writes: The solution is to either revert to the 8.1.1 code (my recommendation) or check for ngetaddrinfo. The latter is a crude hack though. Hm, I think both of us are confused: me because I thought

Re: [HACKERS] AC_REPLACE_FUNCS([getaddrinfo]) in 8.1.3

2006-02-20 Thread Tom Lane
Albert Chin [EMAIL PROTECTED] writes: On Sun, Feb 19, 2006 at 11:32:53PM -0500, Tom Lane wrote: Would you try the patch proposed at http://archives.postgresql.org/pgsql-patches/2006-01/msg00299.php Works fine on Tru64 UNIX 4.0D and 5.1. OK, applied to HEAD and 8.1. I'm feeling a bit of

[HACKERS] AC_REPLACE_FUNCS([getaddrinfo]) in 8.1.3

2006-02-19 Thread Albert Chin
AC_REPLACE_FUNCS([getaddrinfo]) won't correctly detect getaddrinfo on Tru64 UNIX because the function doesn't exist under that name in libc. From netdb.h: #if defined (_SOCKADDR_LEN) || defined (_XOPEN_SOURCE_EXTENDED) #define getaddrinfo ngetaddrinfo #else #define getaddrinfo ogetaddrinfo

Re: [HACKERS] AC_REPLACE_FUNCS([getaddrinfo]) in 8.1.3

2006-02-19 Thread Tom Lane
Albert Chin [EMAIL PROTECTED] writes: AC_REPLACE_FUNCS([getaddrinfo]) won't correctly detect getaddrinfo on Tru64 UNIX because the function doesn't exist under that name in libc. We changed that code specifically so it *would* work on Tru64 --- see this thread:

Re: [HACKERS] AC_REPLACE_FUNCS([getaddrinfo]) in 8.1.3

2006-02-19 Thread Albert Chin
On Sun, Feb 19, 2006 at 09:02:48PM -0500, Tom Lane wrote: Albert Chin [EMAIL PROTECTED] writes: AC_REPLACE_FUNCS([getaddrinfo]) won't correctly detect getaddrinfo on Tru64 UNIX because the function doesn't exist under that name in libc. We changed that code specifically so it *would* work

Re: [HACKERS] AC_REPLACE_FUNCS([getaddrinfo]) in 8.1.3

2006-02-19 Thread Tom Lane
Albert Chin [EMAIL PROTECTED] writes: On Sun, Feb 19, 2006 at 09:02:48PM -0500, Tom Lane wrote: We changed that code specifically so it *would* work on Tru64 --- see this thread: http://archives.postgresql.org/pgsql-hackers/2006-01/msg00511.php From my reading, no completed patch was posted

Re: [HACKERS] AC_REPLACE_FUNCS([getaddrinfo]) in 8.1.3

2006-02-19 Thread Albert Chin
On Sun, Feb 19, 2006 at 09:56:20PM -0500, Tom Lane wrote: Albert Chin [EMAIL PROTECTED] writes: AC_REPLACE_FUNCS([getaddrinfo]) will not detect getaddrinfo() on Tru64 UNIX because getaddrinfo is not in libc. Hmm, where is it then? getaddrinfo is a macro in netdb.h: #if defined

Re: [HACKERS] AC_REPLACE_FUNCS([getaddrinfo]) in 8.1.3

2006-02-19 Thread Tom Lane
Albert Chin [EMAIL PROTECTED] writes: On Sun, Feb 19, 2006 at 09:56:20PM -0500, Tom Lane wrote: Hmm, where is it then? getaddrinfo is a macro in netdb.h: Yes, we know that. The question was where does the macro point. The solution is to either revert to the 8.1.1 code (my recommendation)

Re: [HACKERS] AC_REPLACE_FUNCS([getaddrinfo]) in 8.1.3

2006-02-19 Thread Martijn van Oosterhout
On Sun, Feb 19, 2006 at 11:32:53PM -0500, Tom Lane wrote: Would you try the patch proposed at http://archives.postgresql.org/pgsql-patches/2006-01/msg00299.php and see if it fixes the problem? That patch has *not* gotten applied, probably because no one confirmed that it worked. This test is