Re: 8.2bet2 failed build on Solaris 10 / x86-64 / SUN Studio

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andreas Lange <anlan(at)ida(dot)liu(dot)se>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: 8.2bet2 failed build on Solaris 10 / x86-64 / SUN Studio
Date: 2006-11-03 16:12:15
Message-ID: 2956.1162570335@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Andreas Lange <anlan(at)ida(dot)liu(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Dennis Bjorklund 2006-11-03 18:29:57 Re: COPY fails on 8.1 with invalid byte sequences in text
Previous Message Andreas Lange 2006-11-03 16:00:23 Re: 8.2bet2 failed build on Solaris 10 / x86-64 / SUN Studio