The following bug has been logged online:

Bug reference: 2162
Logged by: Francois Laupretre
Email address: flconseil (AT) yahoo (DOT) fr
PostgreSQL version: 8.1.1
Operating system: HP-UX 11.11
Description: Same as bug #1679 - finite() - unresolved symbol
Details:

Same problem as described in bug report #1679 of 24-MAY-2005.

Same kind of workaround (comment out HAVE_FINITE in
src/include/pg_config.h).

As bug #1679 is more than 6 months old, I'd like to get a status. If it can
help, I confirm that, without modifications, the current stable release of
PostgreSQL does not compile on HP-UX 11.11.

Thanks in advance

François

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

"Francois Laupretre" <flconseil (AT) yahoo (DOT) fr> writes:
It works fine for me anytime I try it on HP's testdrive systems.

If you are building with gcc, one possible theory is that your gcc
installation is broken. A common way for this to happen is to copy
a gcc installation created on one HPUX version to a machine running
a slightly different HPUX version. gcc's internal copies of system
header files then fail to match the running system, leading to all
sorts of hard-to-debug problems :-(

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

"F. Laupretre" <flconseil (AT) yahoo (DOT) fr> writes:
Argh! gcc couldn't do that in general, of course --- it must be using
some built-in knowledge that finite() doesn't have side-effects.
I'll have to look at how AC_CHECK_FUNC() avoids that. Obviously we
are getting bit because our homegrown check for finite() isn't smart
enough.

I'd actually argue that this is a gcc bug: when there is no declaration
of finite() in the system headers (there isn't is there?) it's wrong to
conclude just on the name of the function that it is side-effect-free.
But I don't suppose a fix will be forthcoming quickly, so we'll have to
work around it.

Thanks for taking the trouble to chase this down.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

"F. Laupretre" <flconseil (AT) yahoo (DOT) fr> writes:
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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Tom Lane wrote:
Could any other configure tests fail in this way?

--
Bruce Momjian | http://candle.pha.pa.us
pgman (AT) candle (DOT) 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 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Bruce Momjian <pgman (AT) candle (DOT) pha.pa.us> writes:
Good point. The isinf() test probably has the same failure mode.

There is also the sigsetjmp() test, but since that has side-effects,
it doesn't seem very much at risk of being aggressively optimized.
I don't see any other cases where we're avoiding AC_CHECK_FUNC.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

"F. Laupretre" <flconseil (AT) yahoo (DOT) fr> writes:
If the compiler is able to compute the result without using the external
function, that's fine. That's equivalent to having a macro-based
implementation, which is exactly what we're going out of our way to
allow here. All that we have to do is ensure that the compiler can't
discard the expression un-evaluated, so making the exit value depend
on it seems pretty bulletproof to me.

I suppose though that there's some chance of the constant-argument case
being treated differently from not-constant, so your idea has some merit.
We couldn't use argc/argv however because the autoconf skeleton for
main() doesn't declare 'em.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

Am Mittwoch, 11. Januar 2006 22:33 schrieb Tom Lane:
Use a global rather than a local variable.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Peter Eisentraut <peter_e (AT) gmx (DOT) net> writes:
In principle an aggressive compiler could still determine that the
global variable is modified nowhere else in the executable. In practice
that will probably get the job done ... this year anyway ...

I did like François' idea of using argc, but the present autoconf
infrastructure doesn't seem to allow it :-(

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Or maybe, if it is really too smart (able to compute the result at compile =
time), we could have not to use a constant argument. Something like 'return=
finite((double)argv) ? 0 : 1'.


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly