pgsql: Use better comment marker in Autoconf input
Use better comment marker in Autoconf input
The comment marker "#" is copied to the output, so it's only
appropriate for comments that make sense in the shell output. For
comments about the Autoconf language, "dnl" should be used.
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/4446565d36ac4482282146a9ab35068f18dff4fd
Modified Files
--------------
config/llvm.m4 | 2 +-
config/programs.m4 | 2 +-
configure | 9 +--------
configure.in | 12 ++++++------
4 files changed, 9 insertions(+), 16 deletions(-)
Hi,
On 2019-02-09 14:57:27 +0000, Peter Eisentraut wrote:
Use better comment marker in Autoconf input
The comment marker "#" is copied to the output, so it's only
appropriate for comments that make sense in the shell output. For
comments about the Autoconf language, "dnl" should be used.
Weirdly enough this might have had some sideeffects. According to
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=elver&dt=2019-02-09%2014%3A58%3A09
this is where elver started to fail. I'd for a minute just put this down
to an independent upgrade on the animal, but the other branches still
build fine. I'm somewhat confused.
Greetings,
Andres Freund
Andres Freund <andres@anarazel.de> writes:
On 2019-02-09 14:57:27 +0000, Peter Eisentraut wrote:
Use better comment marker in Autoconf input
Weirdly enough this might have had some sideeffects. According to
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=elver&dt=2019-02-09%2014%3A58%3A09
this is where elver started to fail.
Yeah, I noticed that coincidence too.
I'd for a minute just put this down
to an independent upgrade on the animal, but the other branches still
build fine.
The error seems to be a library version mismatch, which sure looks
like a busted software upgrade. But you have a darn good point:
if that's the problem, why didn't v11 break too?
I'm somewhat confused.
Me too, now. I stared closely at the configure shell script
changes, and they certainly seem to be innocuous.
regards, tom lane
Hi,
On 2019-02-10 01:45:58 -0500, Tom Lane wrote:
Andres Freund <andres@anarazel.de> writes:
On 2019-02-09 14:57:27 +0000, Peter Eisentraut wrote:
I'd for a minute just put this down
to an independent upgrade on the animal, but the other branches still
build fine.The error seems to be a library version mismatch, which sure looks
like a busted software upgrade. But you have a darn good point:
if that's the problem, why didn't v11 break too?
After a few coffees it's clear why: In v11, we have jit=0. As LLVM is
loaded on-demand, we'll not see errors in v11.
Greetings,
Andres Freund
On Sun, 10 Feb 2019 at 19:22, Andres Freund <andres@anarazel.de> wrote:
On 2019-02-10 01:45:58 -0500, Tom Lane wrote:
Andres Freund <andres@anarazel.de> writes:
On 2019-02-09 14:57:27 +0000, Peter Eisentraut wrote:
I'd for a minute just put this down
to an independent upgrade on the animal, but the other branches still
build fine.The error seems to be a library version mismatch, which sure looks
like a busted software upgrade. But you have a darn good point:
if that's the problem, why didn't v11 break too?After a few coffees it's clear why: In v11, we have jit=0. As LLVM is
loaded on-demand, we'll not see errors in v11.
It was using CC="ccache cc" for C, but no explicit CXX. Somehow our
configure script flipped from finding c++ (the system C++ compiler,
which is Clang) to finding g++ (an old GCC port I had installed) after
that commit, and the resulting .so didn't work too well. I did not
upgrade or change anything at that time. I must admit that commit of
Peter's looks fairly innocent though. Is it possible that an earlier
change caused it, but this change caused the "accache" to be cleared?
That accache seems a bit flimsy, I've had to rm it before. Anyway,
now that I've explicitly set CXX="ccache c++" and nuked the accache,
elver is green again.
Thomas Munro <munro@ip9.org> writes:
It was using CC="ccache cc" for C, but no explicit CXX. Somehow our
configure script flipped from finding c++ (the system C++ compiler,
which is Clang) to finding g++ (an old GCC port I had installed) after
that commit, and the resulting .so didn't work too well. I did not
upgrade or change anything at that time. I must admit that commit of
Peter's looks fairly innocent though. Is it possible that an earlier
change caused it, but this change caused the "accache" to be cleared?
Yeah, I think you're on the right track. Had you made any changes in
that animal's configuration file between 21 Jan (the previous touch
of "configure" was in ee27584c4) and 9 Feb? Or updated the platform's
compilers?
That accache seems a bit flimsy, I've had to rm it before.
Yup, the buildfarm script only knows to nuke it if "configure" changes.
If you change the critter's buildfarm parameters, or the build
environment, that might require revisiting configure tests, but it won't
happen automatically. I can't think of any really easy way to improve
that.
regards, tom lane
On Tue, Feb 12, 2019 at 3:46 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Thomas Munro <munro@ip9.org> writes:
It was using CC="ccache cc" for C, but no explicit CXX. Somehow our
configure script flipped from finding c++ (the system C++ compiler,
which is Clang) to finding g++ (an old GCC port I had installed) after
that commit, and the resulting .so didn't work too well. I did not
upgrade or change anything at that time. I must admit that commit of
Peter's looks fairly innocent though. Is it possible that an earlier
change caused it, but this change caused the "accache" to be cleared?Yeah, I think you're on the right track. Had you made any changes in
that animal's configuration file between 21 Jan (the previous touch
of "configure" was in ee27584c4) and 9 Feb? Or updated the platform's
compilers?
Oh, yeah, I remember now that I installed an old GCC a few weeks back
when testing some theory or other. I am slightly surprised that we
prefer g++ to c++, so that merely installing it has this effect.
Anyway, I've now set the compiler explicitly. Sorry for the noise.
--
Thomas Munro
http://www.enterprisedb.com
On Mon, Feb 11, 2019 at 11:46 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Yup, the buildfarm script only knows to nuke it if "configure" changes.
If you change the critter's buildfarm parameters, or the build
environment, that might require revisiting configure tests, but it won't
happen automatically. I can't think of any really easy way to improve
that.
Could stash a checksum of the config settings and obsolete the cache
if there was a mismatch. The danger is that we could get some false
positives, but the only downside to that is a one time extra amount of
time spent in configure.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services