Re: BUG #7816: test for compiler output produces bogus results - Mailing list pgsql-bugs

From Seebs
Subject Re: BUG #7816: test for compiler output produces bogus results
Date
Msg-id F8B2EB3E-FF02-41BF-9C7C-CE4E835963D6@seebs.net
Whole thread Raw
In response to Re: BUG #7816: test for compiler output produces bogus results  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #7816: test for compiler output produces bogus results
List pgsql-bugs
On 20 Jan 2013, at 23:02, Tom Lane wrote:

> seebs@seebs.net writes:
>> Your modified acx_pthread.m4 tests for any compiler output to stderr
>> at all,
>> and considers it evidence that a flag is invalid.
>
> I believe the reason we do that is that we want to find flags that
> will
> not result in the compiler generating a warning during each and every
> source compile.

It might make sense to first check whether *any* flags can be used
without a warning from every compile. Because if they can't, rejecting a
flag because of something that is unrelated to it seems
counterproductive.

> Most developers would consider such a behavior broken,
> and not without good reason.

I guess it would depend (1) on the warning (2) on whether the compiler
can produce working output at all without the flag.

If my choices are "can't actually build anything, at all" or "get a
useless diagnostic from every build", I prefer the useless diagnostic.
:)

>> This test is not actually correct, although it usually works.

> [ shrug... ]  Given the lack of previous complaints, it works 99.999%
> of the time, which is about as much reliability as can be hoped for in
> most autoconf tests :-(.  I'm afraid we can't help you without
> breaking
> it worse for a larger number of other people.

I guess my question would be, what's the problem this is solving? Were
there actual cases of flags which were accepted (meaning, compiler
produced working output and exited with a successful status), but
produced diagnostics, but were not necessary and could be safely
omitted? Because I have usually been advised not to assume that messages
on stderr indicate an error, but to check exit status and/or creation of
output files.

For reference, out of a build of... I dunno, several hundred packages,
at least, across 4+ target architectures, this was the *only* thing
which failed or behaved discernably differently from the diagnostic
message. (Which is interesting, because when I ran into this about three
years ago, I think we had five or six packages affected.)

If there really are systems where there's flags which are accepted and
produce working output, but also produce diagnostics, and can be
omitted, I guess I can see the benefit of the test. It just offends my
dogmatic sensibilities; the compiler is allowed to offer a diagnostic
for any reason whatsoever, whether or not anything is wrong. ("WARNING:
Hydrogen is more common than iron.")

-s

pgsql-bugs by date:

Previous
From: "Giannis Mavropoulos"
Date:
Subject: error reading c:\Program Files\PostgreSQL\8.3\data\postgresql.conf during installation
Next
From: abrosich@ogs.trieste.it
Date:
Subject: BUG #7818: Foreign server not visible under normal users