Re: [HACKERS] [GENERAL] [PATCH] Better way to check for getaddrinfo
Bruce Momjian writes: > I have the answer. Tru64 netdb.h has: > #if defined (_SOCKADDR_LEN) || defined (_XOPEN_SOURCE_EXTENDED) > #define getaddrinfo ngetaddrinfo > #else > #define getaddrinfo ogetaddrinfo > #endif Seems like the same method we use for testing finite() and other possible-macros would handle this, then. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [GENERAL] [PATCH] Better way to check for getaddrinfo
Tom Lane wrote: > Bruce Momjian writes: > > I am not sure what to do on this. Right now we have a one-line test: > > AC_REPLACE_FUNCS([getaddrinfo]) > > To test for a macro we are going to need to add include netdb.h, and the > > LINK test below is overkill. I am thinking we should just hard-code in > > HAVE_GETADDRINFO for the True64 platform; anything more is going to be > > just a Tru64 hack anyway. > > I still want to understand why any change is needed at all. There must > be something very peculiar about getaddrinfo on Tru64 if the original > coding doesn't work. Why is it different from every other function we > test for? I have the answer. Tru64 netdb.h has: #if defined (_SOCKADDR_LEN) || defined (_XOPEN_SOURCE_EXTENDED) #define getaddrinfo ngetaddrinfo #else #define getaddrinfo ogetaddrinfo #endif so it is a macro, and configure produces this line: #undef $ac_func meaning that even if we added #include , our configure test still would not work. Perhaps we should just test for ngetaddrinfo on that platform, and define HAVE_GETADDRINFO. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(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
Re: [HACKERS] [GENERAL] [PATCH] Better way to check for getaddrinfo
Bruce Momjian writes: > I am not sure what to do on this. Right now we have a one-line test: > AC_REPLACE_FUNCS([getaddrinfo]) > To test for a macro we are going to need to add include netdb.h, and the > LINK test below is overkill. I am thinking we should just hard-code in > HAVE_GETADDRINFO for the True64 platform; anything more is going to be > just a Tru64 hack anyway. I still want to understand why any change is needed at all. There must be something very peculiar about getaddrinfo on Tru64 if the original coding doesn't work. Why is it different from every other function we test for? regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [GENERAL] [PATCH] Better way to check for getaddrinfo
I am not sure what to do on this. Right now we have a one-line test: AC_REPLACE_FUNCS([getaddrinfo]) To test for a macro we are going to need to add include netdb.h, and the LINK test below is overkill. I am thinking we should just hard-code in HAVE_GETADDRINFO for the True64 platform; anything more is going to be just a Tru64 hack anyway. --- R, Rajesh (STSD) wrote: > sorry. It is a macro. > > so, would it be better to check for the macro > as suggested by Tom or go with this patch > > $ diff -r configure.in configure.in.new > 918a919 > > AC_MSG_CHECKING([for getaddrinfo]) > 920c921,926 > < AC_REPLACE_FUNCS([getaddrinfo]) > --- > > AC_TRY_LINK([#include #include ], > > [char (*f)();f=getaddrinfo;], > > ac_cv_func_getaddrinfo=yes, ac_cv_func_getaddrinfo=no) > > if test x"$ac_cv_func_getaddrinfo" = xyes; then > > AC_DEFINE(HAVE_GETADDRINFO,1,[Define if you have the getaddrinfo > function]) > > fi > 923a930 > > AC_MSG_RESULT([$ac_cv_func_getaddrinfo]) > > > I guess, instead of adding seperate code for macro checking as suggested > by Tom, this might serve dual purpose. > > Thanks, > Rajesh R > -- > This space intentionally left non-blank. > > -Original Message- > From: Martijn van Oosterhout [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 24, 2006 2:46 PM > To: R, Rajesh (STSD) > Cc: Tom Lane; pgsql-hackers@postgresql.org; pgsql-general@postgresql.org > Subject: Re: [HACKERS] [GENERAL] [PATCH] Better way to check for > getaddrinfo function. > > On Tue, Jan 24, 2006 at 02:33:13PM +0530, R, Rajesh (STSD) wrote: > > Its not a macro. > > I meant that the code generated by AC_REPLACE_FUNCS([getaddrinfo]) by > > configure.in for "configure" > > does not have "#include ". Hence function is not > > detected(unresolved getaddrinfo). > > Hence I thought AC_TRY_LINK could give test program instead of > > AC_REPLACE_FUNCS taking one. > > But if it isn't a macro, why do you need the header file? In C it's > perfectly legal to declare the symbol yourself and try to link and it > should work *unless* it's normally a macro. > > We're still missing some necessary understanding here... > > Have a nice day, > -- > Martijn van Oosterhout 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. > > -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(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
Re: [HACKERS] [GENERAL] [PATCH] Better way to check for getaddrinfo function.
sorry. It is a macro.so, would it be better to check for the macroas suggested by Tom or go with this patch$ diff -r configure.in configure.in.new918a919> AC_MSG_CHECKING([for getaddrinfo])920c921,926< AC_REPLACE_FUNCS([getaddrinfo])---> AC_TRY_LINK([#include #include ],> [char (*f)();f=getaddrinfo;],> ac_cv_func_getaddrinfo=yes, ac_cv_func_getaddrinfo=no)> if test x"$ac_cv_func_getaddrinfo" = xyes; then> AC_DEFINE(HAVE_GETADDRINFO,1,[Define if you have the getaddrinfo function])> fi923a930> AC_MSG_RESULT([$ac_cv_func_getaddrinfo]) I guess, instead of adding seperate code for macro checking as suggested by Tom, this might serve dual purpose.Thanks,Rajesh R--This space intentionally left non-blank.-Original Message-From: Martijn van Oosterhout [mailto:kleptog@svana.org]Sent: Tuesday, January 24, 2006 2:46 PMTo: R, Rajesh (STSD)Cc: Tom Lane; pgsql-hackers@postgresql.org; pgsql-general@postgresql.orgSubject: Re: [HACKERS] [GENERAL] [PATCH] Better way to check for getaddrinfo function.On Tue, Jan 24, 2006 at 02:33:13PM +0530, R, Rajesh (STSD) wrote:> Its not a macro.> I meant that the code generated by AC_REPLACE_FUNCS([getaddrinfo]) by> configure.in for "configure"> does not have "#include ". Hence function is not> detected(unresolved getaddrinfo).> Hence I thought AC_TRY_LINK could give test program instead of> AC_REPLACE_FUNCS taking one.But if it isn't a macro, why do you need the header file? In C it's perfectly legal to declare the symbol yourself and try to link and it should work *unless* it's normally a macro.We're still missing some necessary understanding here...Have a nice day,--Martijn van Oosterhout 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.
Re: [HACKERS] [GENERAL] [PATCH] Better way to check for getaddrinfo function.
On Tue, Jan 24, 2006 at 02:33:13PM +0530, R, Rajesh (STSD) wrote: > Its not a macro. > I meant that the code generated by AC_REPLACE_FUNCS([getaddrinfo]) by > configure.in for "configure" > does not have "#include ". Hence function is not > detected(unresolved getaddrinfo). > Hence I thought AC_TRY_LINK could give test program instead of > AC_REPLACE_FUNCS taking one. But if it isn't a macro, why do you need the header file? In C it's perfectly legal to declare the symbol yourself and try to link and it should work *unless* it's normally a macro. We're still missing some necessary understanding here... Have a nice day, -- Martijn van Oosterhout 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. signature.asc Description: Digital signature
Re: [HACKERS] [GENERAL] [PATCH] Better way to check for getaddrinfo function.
Its not a macro.I meant that the code generated by AC_REPLACE_FUNCS([getaddrinfo]) by configure.in for "configure"does not have "#include ". Hence function is not detected(unresolved getaddrinfo).Hence I thought AC_TRY_LINK could give test program instead of AC_REPLACE_FUNCS taking one.$ diff -r configure.in configure.in.new918a919> AC_MSG_CHECKING([for getaddrinfo])920c921,926< AC_REPLACE_FUNCS([getaddrinfo])---> AC_TRY_LINK([#include #include ],> [char (*f)();f=getaddrinfo;],> ac_cv_func_getaddrinfo=yes, ac_cv_func_getaddrinfo=no)> if test x"$ac_cv_func_getaddrinfo" = xyes; then> AC_DEFINE(HAVE_GETADDRINFO,1,[Define if you have the getaddrinfo function])> fi923a930> AC_MSG_RESULT([$ac_cv_func_getaddrinfo])Regards, Rajesh R--This space intentionally left non-blank.-Original Message-From: Tom Lane [mailto:[EMAIL PROTECTED]]Sent: Tuesday, January 17, 2006 8:34 PMTo: R, Rajesh (STSD)Cc: pgsql-hackers@postgresql.orgSubject: Re: [HACKERS] [GENERAL] [PATCH] Better way to check for getaddrinfo function."R, Rajesh (STSD)" <[EMAIL PROTECTED]> writes:> But the bottomline is the default test does not include in> the test code.That's odd. Is getaddrinfo a macro on Tru64? If so, the appropriate patch would probably make the test look more like the tests for finite() and friends:dnl Cannot use AC_CHECK_FUNC because finite may be a macro AC_MSG_CHECKING(for finite) AC_TRY_LINK([ #include double glob_double; ], [return finite(glob_double) ? 0 : 1;], [AC_DEFINE(HAVE_FINITE, 1, [Define to 1 if you have finite().]) AC_MSG_RESULT(yes)], [AC_MSG_RESULT(no)]) regards, tom lane
Re: [HACKERS] [GENERAL] [PATCH] Better way to check for getaddrinfo function.
Where are we on this? Rajesh, I think we are waiting for more information from you. --- R, Rajesh (STSD) wrote: > > That was very much situation specific. > But the bottomline is the default test does not include in the > test code. > So, pg uses getaddrinfo.c.And the getaddrinfo.c does not work for me. > Ipv6 client authenciation fails. > > I have modified the patch. > > $ diff -r configure.in configure.in.new > 918a919 > > AC_MSG_CHECKING([for getaddrinfo]) > 920c921,926 > < AC_REPLACE_FUNCS([getaddrinfo]) > --- > > AC_TRY_LINK([#include #include ], > > [char (*f)();f=getaddrinfo;], > > ac_cv_func_getaddrinfo=yes, ac_cv_func_getaddrinfo=no) > > if test x"$ac_cv_func_getaddrinfo" = xyes; then > > AC_DEFINE(HAVE_GETADDRINFO,1,[Define if you have the getaddrinfo > function]) > > fi > 923a930 > > AC_MSG_RESULT([$ac_cv_func_getaddrinfo]) > > > Rajesh R > -- > This space intentionally left non-blank. > > -Original Message- > From: Tom Lane [mailto:[EMAIL PROTECTED] > Sent: Monday, January 16, 2006 11:28 PM > To: R, Rajesh (STSD) > Cc: pgsql-hackers@postgresql.org; pgsql-general@postgresql.org > Subject: Re: [GENERAL] [PATCH] Better way to check for getaddrinfo > function. > > "R, Rajesh (STSD)" <[EMAIL PROTECTED]> writes: > > Just thought that the following patch might improve checking for > > getaddrinfo function (in configure.in) > > Since AC_TRY_RUN tests cannot work in cross-compilation scenarios, you > need an *extremely* good reason to put one in. "I thought this might > improve things" doesn't qualify. Exactly what problem are you trying to > solve and why is a run-time test necessary? Why doesn't the existing > coding work for you? > > regards, tom lane <> Content-Description: configure-in.patch [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 5: don't forget to increase your free space map settings -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] [PATCH] Better way to check for getaddrinfo function.
"R, Rajesh (STSD)" <[EMAIL PROTECTED]> writes: > But the bottomline is the default test does not include in the > test code. That's odd. Is getaddrinfo a macro on Tru64? If so, the appropriate patch would probably make the test look more like the tests for finite() and friends: dnl Cannot use AC_CHECK_FUNC because finite may be a macro AC_MSG_CHECKING(for finite) AC_TRY_LINK([ #include double glob_double; ], [return finite(glob_double) ? 0 : 1;], [AC_DEFINE(HAVE_FINITE, 1, [Define to 1 if you have finite().]) AC_MSG_RESULT(yes)], [AC_MSG_RESULT(no)]) regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] [PATCH] Better way to check for getaddrinfo function.
Title: RE: [GENERAL] [PATCH] Better way to check for getaddrinfo function. That was very much situation specific. But the bottomline is the default test does not include in the test code. So, pg uses getaddrinfo.c.And the getaddrinfo.c does not work for me. Ipv6 client authenciation fails. I have modified the patch. $ diff -r configure.in configure.in.new 918a919 > AC_MSG_CHECKING([for getaddrinfo]) 920c921,926 < AC_REPLACE_FUNCS([getaddrinfo]) --- > AC_TRY_LINK([#include #include ], > [char (*f)();f=getaddrinfo;], > ac_cv_func_getaddrinfo=yes, ac_cv_func_getaddrinfo=no) > if test x"$ac_cv_func_getaddrinfo" = xyes; then > AC_DEFINE(HAVE_GETADDRINFO,1,[Define if you have the getaddrinfo function]) > fi 923a930 > AC_MSG_RESULT([$ac_cv_func_getaddrinfo]) Rajesh R -- This space intentionally left non-blank. -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED]] Sent: Monday, January 16, 2006 11:28 PM To: R, Rajesh (STSD) Cc: pgsql-hackers@postgresql.org; pgsql-general@postgresql.org Subject: Re: [GENERAL] [PATCH] Better way to check for getaddrinfo function. "R, Rajesh (STSD)" <[EMAIL PROTECTED]> writes: > Just thought that the following patch might improve checking for > getaddrinfo function (in configure.in) Since AC_TRY_RUN tests cannot work in cross-compilation scenarios, you need an *extremely* good reason to put one in. "I thought this might improve things" doesn't qualify. Exactly what problem are you trying to solve and why is a run-time test necessary? Why doesn't the existing coding work for you? regards, tom lane <> configure-in.patch Description: configure-in.patch ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [GENERAL] [PATCH] Better way to check for getaddrinfo function.
"R, Rajesh (STSD)" <[EMAIL PROTECTED]> writes: > Just thought that the following patch might improve checking for > getaddrinfo function (in configure.in) Since AC_TRY_RUN tests cannot work in cross-compilation scenarios, you need an *extremely* good reason to put one in. "I thought this might improve things" doesn't qualify. Exactly what problem are you trying to solve and why is a run-time test necessary? Why doesn't the existing coding work for you? regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
