AC_REPLACE_FUNCS([getaddrinfo]) in 8.1.3
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
#endif
The original code in 8.1.1 was:
AC_MSG_CHECKING([for getaddrinfo by including <netdb.h>])
AC_TRY_LINK([#include <sys/types.h>
#include <sys/socket.h>
#include <netdb.h>],
[getaddrinfo(NULL, NULL, NULL, NULL);],
[AC_MSG_RESULT([yes])
AC_DEFINE(HAVE_GETADDRINFO, 1,
[Define to 1 if you have the `getaddrinfo' function.])],
[AC_MSG_RESULT([no])
AC_LIBOBJ(getaddrinfo)])
So, what's the best way to merge the two? If getaddrinfo() is borked
on Windows, how about AC_TRY_RUN to test it out?
--
albert chin (china@thewrittenword.com)
Albert Chin <pgsql-hackers@mlists.thewrittenword.com> 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:
http://archives.postgresql.org/pgsql-hackers/2006-01/msg00511.php
Please explain why you think it's a regression.
regards, tom lane
On Sun, Feb 19, 2006 at 09:02:48PM -0500, Tom Lane wrote:
Albert Chin <pgsql-hackers@mlists.thewrittenword.com> 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:
http://archives.postgresql.org/pgsql-hackers/2006-01/msg00511.php
Please explain why you think it's a regression.
From my reading, no completed patch was posted in the thread.
AC_REPLACE_FUNCS([getaddrinfo]) will not detect getaddrinfo() on Tru64
UNIX because getaddrinfo is not in libc. Because of this, getaddrinfo
isn't detected and the compilation of src/port/thread.c fails:
cc -std -O2 -ieee -msym -readonly_strings -I../../src/port -DFRONTEND -I../../src/include -I/opt/TWWfsw/gettext014/include -I/opt/TWWfsw/libopenssl097/include -I/opt/TWWfsw/zlib11/include -I/opt/TWWfsw/tcl84/include -I/opt/TWWfsw/tk84/include -pthread --thread-safe -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -c thread.c
cc: Warning: thread.c, line 80: In this statement, "strerror_r(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
return strerror_r(errnum, strerrbuf, buflen);
---------------^
cc: Warning: thread.c, line 141: In this statement, the referenced type of the pointer value "buffer" is "char", which is not compatible with "struct hostent_data". (ptrmismatch)
*result = gethostbyname_r(name, resultbuf, buffer, buflen, herrno);
---------------------------------------------------^
cc: Error: thread.c, line 141: In this statement, "gethostbyname_r" expects 3 arguments, but 5 are supplied. (toomanyargs)
*result = gethostbyname_r(name, resultbuf, buffer, buflen, herrno);
------------------^
gmake[2]: *** [thread.o] Error 1
gethostbyname_r() on Tru64 UNIX accepts 3 arguments.
--
albert chin (china@thewrittenword.com)
Albert Chin <pgsql-hackers@mlists.thewrittenword.com> 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 in the thread.
Well, indeed the original reporter doesn't seem to have bothered to test
the applied patch :-(
AC_REPLACE_FUNCS([getaddrinfo]) will not detect getaddrinfo() on Tru64
UNIX because getaddrinfo is not in libc.
Hmm, where is it then?
regards, tom lane
On Sun, Feb 19, 2006 at 09:56:20PM -0500, Tom Lane wrote:
Albert Chin <pgsql-hackers@mlists.thewrittenword.com> 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 (_SOCKADDR_LEN) || defined (_XOPEN_SOURCE_EXTENDED)
#define getaddrinfo ngetaddrinfo
#else
#define getaddrinfo ogetaddrinfo
#endif
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.
$ nm /usr/shlib/libc.so | grep getaddrinfo
__ngetaddrinfo | 0004395900636352 | T | 0000000000000008
__ogetaddrinfo | 0004395900637184 | T | 0000000000000008
ngetaddrinfo | 0004395900636352 | T | 0000000000000008
ogetaddrinfo | 0004395900637184 | T | 0000000000000008
--
albert chin (china@thewrittenword.com)
Albert Chin <pgsql-hackers@mlists.thewrittenword.com> 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)
or check for ngetaddrinfo. The latter is a crude hack though.
Hm, I think both of us are confused: me because I thought we'd changed
the getaddrinfo test, which in fact has not happened, and you because
you think 8.1.1 is different from 8.1.3 on this point, which it is not.
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.
regards, tom lane
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 different, it checks that getaddrinfo has four args. I'm
not sure if it's important but if you just want to check the function
exists, just checking for:
[return getaddrinfo ? 0 : 1;],
Will check for existance.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
Show quoted text
Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
tool for doing 5% of the work and then sitting around waiting for someone
else to do the other 95% so you can sue them.
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
On Sun, Feb 19, 2006 at 11:32:53PM -0500, Tom Lane wrote:
Albert Chin <pgsql-hackers@mlists.thewrittenword.com> 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 we'd changed
the getaddrinfo test, which in fact has not happened, and you because
you think 8.1.1 is different from 8.1.3 on this point, which it is not.
Yep, my mistake.
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.
Works fine on Tru64 UNIX 4.0D and 5.1.
Thanks!
--
albert chin (china@thewrittenword.com)
Albert Chin <pgsql-hackers@mlists.thewrittenword.com> 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 concern though after
re-reading the comment attached to the test:
# (Note: the AC_TRY_LINK probe fails on Windows, where the available
# versions of getaddrinfo don't follow normal C call protocol. This is OK
# because we want to use our own getaddrinfo.c on Windows anyway.)
It seems likely that the new coding will allow the test to *succeed* on
Windows. Does that happen, and if so is it bad? We can put in a hack
to suppress the test on Windows if necessary. Someone please check it
out on Windows ...
regards, tom lane
Tom Lane wrote:
Albert Chin <pgsql-hackers@mlists.thewrittenword.com> 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.phpWorks fine on Tru64 UNIX 4.0D and 5.1.
OK, applied to HEAD and 8.1. I'm feeling a bit of concern though after
re-reading the comment attached to the test:# (Note: the AC_TRY_LINK probe fails on Windows, where the available
# versions of getaddrinfo don't follow normal C call protocol. This is OK
# because we want to use our own getaddrinfo.c on Windows anyway.)It seems likely that the new coding will allow the test to *succeed* on
Windows. Does that happen, and if so is it bad? We can put in a hack
to suppress the test on Windows if necessary. Someone please check it
out on Windows ...
It would be bad - the whole thing is that on Windows we need to search
for some functions dynamically, so we have to use our own code to do that.
But it appears not to find it either with ipv6 installed or not. So I
think we're good (fingers crossed).
cheers
andrew
Tom Lane wrote:
Albert Chin <pgsql-hackers@mlists.thewrittenword.com> 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)
or check for ngetaddrinfo. The latter is a crude hack though.Hm, I think both of us are confused: me because I thought we'd changed
the getaddrinfo test, which in fact has not happened, and you because
you think 8.1.1 is different from 8.1.3 on this point, which it is not.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.
Correct, the patch was still my personal patch directory awaiting
feedback.
--
Bruce Momjian http://candle.pha.pa.us
SRA OSS, Inc. http://www.sraoss.com
+ If your life is a hard drive, Christ can be your backup. +