Re: 8.2bet2 failed build on Solaris 10 / x86-64 / SUN Studio - Mailing list pgsql-bugs

From Tom Lane
Subject Re: 8.2bet2 failed build on Solaris 10 / x86-64 / SUN Studio
Date
Msg-id 2956.1162570335@sss.pgh.pa.us
Whole thread Raw
In response to Re: 8.2bet2 failed build on Solaris 10 / x86-64 / SUN Studio  (Andreas Lange <anlan@ida.liu.se>)
Responses Re: 8.2bet2 failed build on Solaris 10 / x86-64 / SUN Studio  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
List pgsql-bugs
Andreas Lange <anlan@ida.liu.se> writes:
> Tom Lane wrote:
>> I suppose there is something funny about pow() on your platform
>> causing that probe to fail.  What does config.log have at the
>> "checking for library containing pow" step?
>>
> configure:5168: checking for library containing pow
> configure:5198: /sw/sun-studio-11/SUNWspro/bin/cc -Xa -o conftest -fast
> -fns=no -fsimple=1 -xtarget=opteron -xarch=amd64a     conftest.c  >&5
> configure:5204: $? = 0
> configure:5208: test -z
>              || test ! -s conftest.err
> configure:5211: $? = 0
> configure:5214: test -s conftest
> configure:5217: $? = 0
> configure:5287: result: none required

Interesting.  Could pow() actually be in libc on your machine?
The other possible explanation is that it's a macro, but the
AC_SEARCH_LIBS code seems to go out of its way to fail if that's
the case.

Anyway this illustrates the dilemma we face in trying to do a real probe
for libm: the common functions (pow) are likely to be macro-ized, while
uncommon ones might not be there at all (cbrt).  Anyone have a better
idea than reverting to the unconditional AC_CHECK_LIB(m, main) call?

            regards, tom lane

pgsql-bugs by date:

Previous
From: Andreas Lange
Date:
Subject: Re: 8.2bet2 failed build on Solaris 10 / x86-64 / SUN Studio
Next
From: "Basil Evseenko"
Date:
Subject: BUG #2732: pg_get_serial_sequence error