Re: configure can't detect proper pthread flags

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: configure can't detect proper pthread flags
Дата
Msg-id 32766.1426812610@sss.pgh.pa.us
обсуждение исходный текст
Ответ на configure can't detect proper pthread flags  (Max Filippov <jcmvbkbc@gmail.com>)
Ответы Re: configure can't detect proper pthread flags  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Re: configure can't detect proper pthread flags  (Max Filippov <jcmvbkbc@gmail.com>)
Список pgsql-hackers
Max Filippov <jcmvbkbc@gmail.com> writes:
> when PostgreSQL is cross-compiled in the Buildroot with uClibc toolchain
> it may not correctly detect compiler/linker flags for threading. [1]
> The reason is that config/acx_pthread.m4:146 uses compiler and linker
> stdout and stderr to make decision if acx_pthread_ok should be yes or no:

>   if test "`(eval $ac_link 2>&1 1>&5)`" = "" && test "`(eval
> $ac_compile 2>&1 1>&5)`" = ""; then

> and the toolchain emits the following warning at linking step:

>   libcrypto.so: warning: gethostbyname is obsolescent, use
> getnameinfo() instead.

> git log doesn't tell much why it is done that way. Does anybody know?

The short answer is that the linker you're using is written by pedantic
idiots.  Notice that the gethostbyname call it's complaining about is
somewhere inside libcrypto; it's *not* in Postgres, much less the test
program being built here.  As such, we have no options whatever for
suppressing the complaint, which means that the complaint is being
delivered inappropriately, and it shouldn't be there.  The linker is a
silly choice for a place to impose this sort of value judgment anyway;
it has absolutely no way to know whether the use of gethostbyname in
a particular program is unsafe.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: "cancelling statement due to user request error" occurs but the transaction has committed.
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: "cancelling statement due to user request error" occurs but the transaction has committed.