[BUGS] BUG #7816: test for compiler output produces bogus results

2013-01-19 Thread seebs
The following bug has been logged on the website:

Bug reference:  7816
Logged by:  Peter Seebach
Email address:  se...@seebs.net
PostgreSQL version: 9.1.4
Operating system:   Linux
Description:

Your modified acx_pthread.m4 tests for any compiler output to stderr at all,
and considers it evidence that a flag is invalid.

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

The reason this bit me is that I have cause to build stuff with a patched
gcc which has a check for possible licensing-related stuff (not for gcc
itself, but because gcc's in the usage path; long story), and if that fails
or can't be run, it prints a diagnostic to stderr. This is not an error, and
it does not prevent successful compilation.

But if it happens during the postgresql configure, it results in configure
deciding that -lpthread isn't available, and dying.

In general, it is Bad Mojo to assume that all messages on stderr indicate
failures. If there is an error, the compiler is expected to exit with a
non-zero exit status. If it doesn't exit non-zero, you should assume that it
worked. This is why configure doesn't normally fail tests just because there
is some message on stderr...



-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs


Re: [BUGS] BUG #7816: test for compiler output produces bogus results

2013-01-21 Thread Seebs

On 20 Jan 2013, at 23:02, Tom Lane wrote:


se...@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


--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs