AC_REPLACE_FUNCS([getaddrinfo]) in 8.1.3
Albert Chin
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 (ch...@thewrittenword.com)
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
Tom Lane
> 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
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majo...@postgresql.org so that your
message can get through to the mailing list cleanly
Albert Chin
> Albert Chin <pgsql-...@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 (ch...@thewrittenword.com)
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Tom Lane
> 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
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
Albert Chin
> Albert Chin <pgsql-...@mlists.thewrittenword.com> writes:
>
> > 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 (ch...@thewrittenword.com)
Tom Lane
> 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
---------------------------(end of broadcast)---------------------------
Martijn van Oosterhout
> 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 <kle...@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.
Tom Lane
> 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)---------------------------
Albert Chin
> Albert Chin <pgsql-...@mlists.thewrittenword.com> writes:
>
> > 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 (ch...@thewrittenword.com)
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
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
> 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
---------------------------(end of broadcast)---------------------------
Andrew Dunstan
Tom Lane wrote:
>Albert Chin <pgsql-...@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
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
Bruce Momjian
> Albert Chin <pgsql-...@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. +
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend