Thread: BUG #7816: test for compiler output produces bogus results
The following bug has been logged on the website: Bug reference: 7816 Logged by: Peter Seebach Email address: seebs@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...
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. Most developers would consider such a behavior broken,
and not without good reason.
> 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.
regards, tom lane
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
Seebs <seebs@seebs.net> writes:
> On 20 Jan 2013, at 23:02, Tom Lane wrote:
>> [ 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?
No, the problem as I recall it was that if we ignored the warnings,
we got executables that didn't work properly, at least on some
platforms/compilers, because we made the wrong choices of thread flags.
It's conceivable that the configure script could be made to test
threading functionality instead of just looking for warnings, but it
would be noticeably slower and wouldn't work in cross-compile cases.
So I'm disinclined to change it when we have only one complaint, and
that from a person who's using a quite nonstandard compiler.
> ... It just offends my
> dogmatic sensibilities; the compiler is allowed to offer a diagnostic
> for any reason whatsoever, whether or not anything is wrong.
I don't disagree, but the script has got to deal with the world as it
is, including a lot of non-especially-sane compilers. And frankly,
I'd have to include yours in that category. I certainly would refuse
to use a compiler that produced a warning on every single run --- how
are you going to find the real warnings amongst such noise?
regards, tom lane