Tom Lane wrote:
> 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?
>
Main problem is -fast switch. It modifies behavior of floating point
operation (it is reason why It is not good option for postgres) and use
another floating point libraries and some function are inlined. It is
reason why pow test passed with -fast switch without -lm switch.
Detail description of -fast you can found on
http://docs.sun.com/source/819-3688/cc_ops.app.html
Zdenek