Re: 8.2bet2 failed build on Solaris 10 / x86-64 / SUN Studio
| От | Tom Lane |
|---|---|
| Тема | Re: 8.2bet2 failed build on Solaris 10 / x86-64 / SUN Studio |
| Дата | |
| Msg-id | 2956.1162570335@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: 8.2bet2 failed build on Solaris 10 / x86-64 / SUN Studio (Andreas Lange <anlan@ida.liu.se>) |
| Ответы |
Re: 8.2bet2 failed build on Solaris 10 / x86-64 / SUN Studio
|
| Список | 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 по дате отправления: