Обсуждение: 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 #definegetaddrinfo 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 referencedtype 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" expects3 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 getaddrinfongetaddrinfo #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/ > 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.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 ... > > > > 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. +