BUG #8271: Configure warning: sys/ucred.h: present but cannot be compiled

On 2013-06-30 10:43:49 +0000, emre@hasegeli.com wrote:

checking sys/ucred.h usability... no
checking sys/ucred.h presence... yes
configure: WARNING: sys/ucred.h: present but cannot be compiled
configure: WARNING: sys/ucred.h: check for missing prerequisite
headers?
configure: WARNING: sys/ucred.h: see the Autoconf documentation
configure: WARNING: sys/ucred.h: section "Present But Cannot Be
Compiled"
configure: WARNING: sys/ucred.h: proceeding with the preprocessor's result
configure: WARNING: sys/ucred.h: in the future, the compiler will take
precedence
configure: WARNING: ## ---------------------------------------- ##
configure: WARNING: ## Report this to pgsql-bugs@postgresql.org ##
configure: WARNING: ## ---------------------------------------- ##
checking for sys/ucred.h... yes

Could you attach config.log?

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

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

2013/6/30 Andres Freund <andres@2ndquadrant.com>:

On 2013-06-30 10:43:49 +0000, emre@hasegeli.com wrote:
Could you attach config.log?

Attached.

On 2013-06-30 15:11:24 +0300, Emre Hasegeli wrote:

2013/6/30 Andres Freund <andres@2ndquadrant.com>:

On 2013-06-30 10:43:49 +0000, emre@hasegeli.com wrote:
Could you attach config.log?

Attached.

This seems to be caused by be4585b1c27ac5dbdd0d61740d18f7ad9a00e268. The
fault imo lies with openbsd which doesn't include the prerequisite
sys/param.h header which defines NGROUPS:
http://fxr.watson.org/fxr/source/sys/ucred.h?v=OPENBSD
The other BSD flavors seems to get that right.

Before that commit the checks for cmsgcred which includes sys/ucred.h
happened to include params.h... Patch attached, missing the configure
update since I don't have a compatible autoconf on my laptop, to produce
a minimal diff.

It's a bit sad that we didn't notice this despite having spoonbill
reporting it, presumably for a good while:
http://pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=spoonbill&amp;dt=2013-06-29%2011%3A00%3A04&amp;stg=configure

The reason we presumably missed it is that getpeereid is properly
present.

Andrew: Could we perhaps check for the "Report this to" bit in the
buildfarm?

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

On 2013-06-30 15:17:20 +0200, Andres Freund wrote:

Andrew: Could we perhaps check for the "Report this to" bit in the
buildfarm?

FWIW: I checked that there are no other reports on HEAD atm.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

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

On 06/30/2013 09:20 AM, Andres Freund wrote:

On 2013-06-30 15:17:20 +0200, Andres Freund wrote:

Andrew: Could we perhaps check for the "Report this to" bit in the
buildfarm?

FWIW: I checked that there are no other reports on HEAD atm.

I'm not sure what you're asking here. Where exactly do you thing
buildfarm failures should be reported? There are four mailing lists that
get buildfarm status reports:

* <http://lists.pgfoundry.org/mailman/listinfo/pgbuildfarm-status-all&gt;
gets a summary of every single reported build
* <http://lists.pgfoundry.org/mailman/listinfo/pgbuildfarm-status-fail&gt; gets
a summary of every build that fails
* <http://lists.pgfoundry.org/mailman/listinfo/pgbuildfarm-status-chngs&gt;
gets a summary of every build that results in a status change
* <http://lists.pgfoundry.org/mailman/listinfo/pgbuildfarm-status-green&gt;
gets a summary of every build that results in a status change to or
from green (a.k.a. OK)

These are available in digest form.

What we could possibly add is a feature to email a committer about a
commit included in the changeset of a failing build. The main trick
would be to avoid flooding the committers, so that a commit would only
be notified once. Magnus has suggested something like this previously,
but I haven't looked at it much - I can again. It might not be too hard.

cheers

andrew

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

Andrew Dunstan <andrew@dunslane.net> writes:

On 2013-06-30 15:17:20 +0200, Andres Freund wrote:

Andrew: Could we perhaps check for the "Report this to" bit in the
buildfarm?

I'm not sure what you're asking here.

I think he's wishing that if configure prints something like

configure: WARNING: sys/ucred.h: present but cannot be compiled
configure: WARNING: sys/ucred.h: check for missing prerequisite headers?
configure: WARNING: sys/ucred.h: see the Autoconf documentation
configure: WARNING: sys/ucred.h: section "Present But Cannot Be Compiled"
configure: WARNING: sys/ucred.h: proceeding with the preprocessor's result
configure: WARNING: sys/ucred.h: in the future, the compiler will take precedence
configure: WARNING: ## ---------------------------------------- ##
configure: WARNING: ## Report this to pgsql-bugs@postgresql.org ##
configure: WARNING: ## ---------------------------------------- ##

that that ought to be treated as a failure not a success. I'm not
entirely sure that I agree, but it's an arguable position.

regards, tom lane

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

On 06/30/2013 09:49 AM, Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

On 2013-06-30 15:17:20 +0200, Andres Freund wrote:

Andrew: Could we perhaps check for the "Report this to" bit in the
buildfarm?

I'm not sure what you're asking here.

I think he's wishing that if configure prints something like

configure: WARNING: sys/ucred.h: present but cannot be compiled
configure: WARNING: sys/ucred.h: check for missing prerequisite headers?
configure: WARNING: sys/ucred.h: see the Autoconf documentation
configure: WARNING: sys/ucred.h: section "Present But Cannot Be Compiled"
configure: WARNING: sys/ucred.h: proceeding with the preprocessor's result
configure: WARNING: sys/ucred.h: in the future, the compiler will take precedence
configure: WARNING: ## ---------------------------------------- ##
configure: WARNING: ## Report this to pgsql-bugs@postgresql.org ##
configure: WARNING: ## ---------------------------------------- ##

that that ought to be treated as a failure not a success. I'm not
entirely sure that I agree, but it's an arguable position.

Oh. Well, if that's a failure then it's up to configure to treat it as
one. The buildfarm doesn't second-guess the exit status of the various
steps, and it doesn't report warnings - if it did we'd be flooded.

cheers

andrew

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

On 2013-06-30 10:17:50 -0400, Andrew Dunstan wrote:

On 06/30/2013 09:49 AM, Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

On 2013-06-30 15:17:20 +0200, Andres Freund wrote:

Andrew: Could we perhaps check for the "Report this to" bit in the
buildfarm?

I'm not sure what you're asking here.

I think he's wishing that if configure prints something like

configure: WARNING: sys/ucred.h: present but cannot be compiled
configure: WARNING: sys/ucred.h: check for missing prerequisite headers?
configure: WARNING: sys/ucred.h: see the Autoconf documentation
configure: WARNING: sys/ucred.h: section "Present But Cannot Be Compiled"
configure: WARNING: sys/ucred.h: proceeding with the preprocessor's result
configure: WARNING: sys/ucred.h: in the future, the compiler will take precedence
configure: WARNING: ## ---------------------------------------- ##
configure: WARNING: ## Report this to pgsql-bugs@postgresql.org ##
configure: WARNING: ## ---------------------------------------- ##

that that ought to be treated as a failure not a success. I'm not
entirely sure that I agree, but it's an arguable position.

Exactly. That we presumably had this warning showing up for more than 2
years seems to indicate we should think about doing something different.

Oh. Well, if that's a failure then it's up to configure to treat it as one.
The buildfarm doesn't second-guess the exit status of the various steps, and
it doesn't report warnings - if it did we'd be flooded.

I guess we don't want to do that because it would probably hurt people
building in unusual environments where some variants of this very well
can show up without stopping pg from being built. Many people on such
problems will have no difficulties fixing a minor compilation error, but
fixing configure.in + installing the correct autoconf version is a
higher barrier.
We could add a --strict-mode or so to configure, but afair the handling
of that warning is burried in autoconf itself making this harder. So
I thought adding some grep like thing to the buildfarm might be the
easiest solution.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

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

On 06/30/2013 11:07 AM, Andres Freund wrote:

On 2013-06-30 10:17:50 -0400, Andrew Dunstan wrote:

On 06/30/2013 09:49 AM, Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

On 2013-06-30 15:17:20 +0200, Andres Freund wrote:

Andrew: Could we perhaps check for the "Report this to" bit in the
buildfarm?

I'm not sure what you're asking here.

I think he's wishing that if configure prints something like

configure: WARNING: sys/ucred.h: present but cannot be compiled
configure: WARNING: sys/ucred.h: check for missing prerequisite headers?
configure: WARNING: sys/ucred.h: see the Autoconf documentation
configure: WARNING: sys/ucred.h: section "Present But Cannot Be Compiled"
configure: WARNING: sys/ucred.h: proceeding with the preprocessor's result
configure: WARNING: sys/ucred.h: in the future, the compiler will take precedence
configure: WARNING: ## ---------------------------------------- ##
configure: WARNING: ## Report this to pgsql-bugs@postgresql.org ##
configure: WARNING: ## ---------------------------------------- ##

that that ought to be treated as a failure not a success. I'm not
entirely sure that I agree, but it's an arguable position.

Exactly. That we presumably had this warning showing up for more than 2
years seems to indicate we should think about doing something different.

Oh. Well, if that's a failure then it's up to configure to treat it as one.
The buildfarm doesn't second-guess the exit status of the various steps, and
it doesn't report warnings - if it did we'd be flooded.

I guess we don't want to do that because it would probably hurt people
building in unusual environments where some variants of this very well
can show up without stopping pg from being built. Many people on such
problems will have no difficulties fixing a minor compilation error, but
fixing configure.in + installing the correct autoconf version is a
higher barrier.
We could add a --strict-mode or so to configure, but afair the handling
of that warning is burried in autoconf itself making this harder. So
I thought adding some grep like thing to the buildfarm might be the
easiest solution.

But that *would* be second-guessing configure's exit status.

I don't understand the reference to autoconf - nobody building Postgres,
including buildfarm members, needs autoconf installed at all. Only
developers and committers need to, and then only when configure.in is
changed.

cheers

andrew

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

On 2013-06-30 11:19:50 -0400, Andrew Dunstan wrote:

Oh. Well, if that's a failure then it's up to configure to treat it as one.
The buildfarm doesn't second-guess the exit status of the various steps, and
it doesn't report warnings - if it did we'd be flooded.

I guess we don't want to do that because it would probably hurt people
building in unusual environments where some variants of this very well
can show up without stopping pg from being built. Many people on such
problems will have no difficulties fixing a minor compilation error, but
fixing configure.in + installing the correct autoconf version is a
higher barrier.
We could add a --strict-mode or so to configure, but afair the handling
of that warning is burried in autoconf itself making this harder. So
I thought adding some grep like thing to the buildfarm might be the
easiest solution.

But that *would* be second-guessing configure's exit status.

Yes. I think that's the easiest thing in this case.

I don't understand the reference to autoconf - nobody building Postgres,
including buildfarm members, needs autoconf installed at all. Only
developers and committers need to, and then only when configure.in is
changed.

If we would treat that warning as an error unconditionally - and I am
not sure how easy that is given the way it's emitted - users
encountering them, which usually will be on less common platforms, will
have to patch configure.in to make things work for them. Which is a high
bar.
Given that many of those warnings will *NOT* completely prohibit them
from building postgres that might be overreaching.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

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

On 6/30/13 11:26 AM, Andres Freund wrote:

If we would treat that warning as an error unconditionally - and I am
not sure how easy that is given the way it's emitted - users
encountering them, which usually will be on less common platforms, will
have to patch configure.in to make things work for them. Which is a high
bar.
Given that many of those warnings will *NOT* completely prohibit them
from building postgres that might be overreaching.

We could also look into updating Autoconf. Newer versions proceed with
the compiler's result. At that point, you can essentially ignore the
warning.

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

Peter Eisentraut <peter_e@gmx.net> writes:

On 6/30/13 11:26 AM, Andres Freund wrote:

If we would treat that warning as an error unconditionally - and I am
not sure how easy that is given the way it's emitted - users
encountering them, which usually will be on less common platforms, will
have to patch configure.in to make things work for them. Which is a high
bar.

We could also look into updating Autoconf. Newer versions proceed with
the compiler's result. At that point, you can essentially ignore the
warning.

AFAICT, the result in this case would be that the script comes to the
wrong conclusion about whether ucred.h is available. Wouldn't that
result in a build failure, or at least missing features? IOW, don't
we need to fix this test anyway?

However, if newer autoconf versions make only one test per header file
and not two, then +1 for updating. Should help a bit with configure's
speed problem.

regards, tom lane

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

On 2013-07-01 09:19:23 -0400, Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

On 6/30/13 11:26 AM, Andres Freund wrote:

If we would treat that warning as an error unconditionally - and I am
not sure how easy that is given the way it's emitted - users
encountering them, which usually will be on less common platforms, will
have to patch configure.in to make things work for them. Which is a high
bar.

We could also look into updating Autoconf. Newer versions proceed with
the compiler's result. At that point, you can essentially ignore the
warning.

While it has other benefits, changing whether autoconf believes the
precompiler or the compiler doesn't seem to fix the issue of tests that
fail silently (as in, don't abort autoconf) because we missed to include
prerequisite headers.
And it doesn't seem to make it neither easier, nor harder for users to
fix configure.in, so unconditionally throwing an hard error even if we
could manage it would still not a good solution.

AFAICT, the result in this case would be that the script comes to the
wrong conclusion about whether ucred.h is available. Wouldn't that
result in a build failure, or at least missing features? IOW, don't
we need to fix this test anyway?

Yes, we need to. I vote for applying something similar to what I
proposed upthread. If we can get rid of some redundancy by using a newer
autoconf we need to touch far more than this tiny bit...

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

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

On 7/1/13 9:19 AM, Tom Lane wrote:

AFAICT, the result in this case would be that the script comes to the
wrong conclusion about whether ucred.h is available. Wouldn't that
result in a build failure, or at least missing features? IOW, don't
we need to fix this test anyway?

The test needs to be fixed, but with a newer Autoconf version we would
(probably) have been alerted about that by a build failure rather than
someone scanning build logs.

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

On 07/01/2013 05:35 PM, Peter Eisentraut wrote:

On 7/1/13 9:19 AM, Tom Lane wrote:

AFAICT, the result in this case would be that the script comes to the
wrong conclusion about whether ucred.h is available. Wouldn't that
result in a build failure, or at least missing features? IOW, don't
we need to fix this test anyway?

The test needs to be fixed, but with a newer Autoconf version we would
(probably) have been alerted about that by a build failure rather than
someone scanning build logs.

I take it you mean a configure failure would occur with a later Autoconf.

cheers

andrew

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

Peter Eisentraut <peter_e@gmx.net> writes:

On 7/1/13 9:19 AM, Tom Lane wrote:

AFAICT, the result in this case would be that the script comes to the
wrong conclusion about whether ucred.h is available. Wouldn't that
result in a build failure, or at least missing features? IOW, don't
we need to fix this test anyway?

The test needs to be fixed, but with a newer Autoconf version we would
(probably) have been alerted about that by a build failure rather than
someone scanning build logs.

I think probably we'd have just not compiled the dependent code, and
would have found out about it only when somebody complained that peer
auth didn't work on OpenBSD. Not sure that's really a more attractive
behavior :-(

regards, tom lane

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

On Mon, 2013-07-01 at 19:27 -0400, Tom Lane wrote:

I think probably we'd have just not compiled the dependent code, and
would have found out about it only when somebody complained that peer
auth didn't work on OpenBSD. Not sure that's really a more attractive
behavior :-(

That might be the case, but that's more a problem of how this particular
feature is implemented, not how the configure test works.

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

Hi,

On 2013-06-30 15:17:20 +0200, Andres Freund wrote:

On 2013-06-30 15:11:24 +0300, Emre Hasegeli wrote:

2013/6/30 Andres Freund <andres@2ndquadrant.com>:

On 2013-06-30 10:43:49 +0000, emre@hasegeli.com wrote:
Could you attach config.log?

Attached.

This seems to be caused by be4585b1c27ac5dbdd0d61740d18f7ad9a00e268. The
fault imo lies with openbsd which doesn't include the prerequisite
sys/param.h header which defines NGROUPS:
http://fxr.watson.org/fxr/source/sys/ucred.h?v=OPENBSD
The other BSD flavors seems to get that right.

Before that commit the checks for cmsgcred which includes sys/ucred.h
happened to include params.h... Patch attached, missing the configure
update since I don't have a compatible autoconf on my laptop, to produce
a minimal diff.

Could somebody apply the fix (including regenerating /configure)?

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

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

Andres Freund <andres@2ndquadrant.com> writes:

Before that commit the checks for cmsgcred which includes sys/ucred.h
happened to include params.h... Patch attached, missing the configure
update since I don't have a compatible autoconf on my laptop, to produce
a minimal diff.

Could somebody apply the fix (including regenerating /configure)?

The proposed patch seems a bit overcomplicated --- isn't the real
problem that I changed the ordering of the header probes in
be4585b1c27ac5dbdd0d61740d18f7ad9a00e268? I think I just alphabetized
them in a fit of neatnik-ism, not realizing that there were order
dependencies on some platforms.

regards, tom lane

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