Re: configure can't detect proper pthread flags

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Max Filippov <jcmvbkbc(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Peter Seiderer <ps(dot)report(at)gmx(dot)net>
Subject: Re: configure can't detect proper pthread flags
Date: 2015-03-20 13:23:51
Message-ID: 20150320132351.GS3636@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund wrote:
> Hi,
>
> On 2015-03-20 03:14:48 +0300, Max Filippov wrote:
> > and the toolchain emits the following warning at linking step:
> >
> > libcrypto.so: warning: gethostbyname is obsolescent, use
> > getnameinfo() instead.
>
> FWIW, I think emitting such errors at link time is utterly pointless and
> rather annoying. I can see a point of emitting them them when compiling
> code that uses deprecated functions. But we quite obviously can't do
> much about openssl using gethostbyname.

We don't seem have much leverage with the guys producing the linker. If
we do, then surely our best bet is to get them to be quiet, or at least
provide an --yes-i-know-your-crap-is-noisy-please-shut-it-up option.

If we don't have leverage, and we really care enough about that platform
to want to work around this problem, it seems that the latest suggestion
of comparing the output of the linker with and without the option we're
testing (rather than just assuming that the output without the option
must surely be empty) is the safest bet ... It seems bad (fragile
hack), but let's see a patch and then we can judge.

Another option is to say "uclibc is broken beyond belief" and consider
it unsupported.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dmitry Dolgov 2015-03-20 13:26:31 Re: GSoC 2015: Extra Jsonb functionality
Previous Message Alvaro Herrera 2015-03-20 13:16:06 Re: assessing parallel-safety