Re: configure can't detect proper pthread flags

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Max Filippov <jcmvbkbc(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, "pgsql-hackers(at)postgresql(dot)org" <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 12:13:16
Message-ID: 20150320121316.GG6317@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 20, 2015 at 08:05:48AM -0400, Robert Haas wrote:
> On Fri, Mar 20, 2015 at 7:01 AM, Max Filippov <jcmvbkbc(at)gmail(dot)com> wrote:
> > On Fri, Mar 20, 2015 at 6:08 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> We don't want every link step producing a useless warning.
> >> Ideally, "make -s" would print nothing whatsoever; to the extent that
> >> tools produce unsuppressable routine chatter, that's evil because it
> >> makes it harder to notice actually-useful warnings.
> >
> > Then maybe stderr tests should grep output for a specific option, the
> > one we're currently testing, not just any noise?
>
> That sounds awfully fragile to me. It can't really be safe to assume
> we know precisely what the warning messages will look like. But it
> seems to me that compiling every test program with every library we
> might need is not a great plan.
>
> (I don't know enough about autoconf to know whether changing that is realistic.)

It was our only plan, and it has worked fine in the past. Someone is
going to have to do a lot of portability research to improve it.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2015-03-20 12:31:24 Re: Incorrect comment in tablecmds.c
Previous Message Thom Brown 2015-03-20 12:09:00 Re: assessing parallel-safety