From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | flconseil(at)yahoo(dot)fr |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #2162: Same as bug #1679 - finite() - unresolved symbol |
Date: | 2006-01-11 21:01:44 |
Message-ID: | 28086.1137013304@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
"F. Laupretre" <flconseil(at)yahoo(dot)fr> writes:
> In order for the check to be done correctly, we have to provide a
> program that the compiler cannot optimize, ie where it cannot detect
> that the call is useless, even if it is very very smart. Here is a
> patch with such a program.
I haven't got a lot of faith in your proposed patch --- with
sufficiently aggressive optimization, the compiler might inline
the is_f() function, no? After looking at the modern version of
AC_CHECK_FUNC, I'm thinking that the best answer is to make the
finite() result affect the program's exit status. Would you try
this version of the check and see if it works for you?
AC_TRY_LINK([#include <math.h>],
[return finite(1.0) ? 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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2006-01-11 21:03:04 | Re: BUG #2162: Same as bug #1679 - finite() - unresolved symbol |
Previous Message | Tom Lane | 2006-01-11 20:49:44 | Re: BUG #2162: Same as bug #1679 - finite() - unresolved symbol |