buildfarm build failure: icc7 + --enable-cassert

Darcy Buskermolen wrote:

It looks like --enable-cassert isn't handled properly under icc7

http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=herring&dt=2004-12-
07%2016:30:44

That is quite a superficial display of the issue. If you want to get to
the bottom of this, you need to, uh, dig deeper.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut <peter_e@gmx.net> writes:

Darcy Buskermolen wrote:

It looks like --enable-cassert isn't handled properly under icc7

http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=herring&amp;dt=2004-12-07%2016:30:44

That is quite a superficial display of the issue. If you want to get to
the bottom of this, you need to, uh, dig deeper.

This looks to me like a standard incompatible-version-of-shared-library
issue, specifically, the .so was built with --enable-cassert but the
backend trying to load it was not. Andrew claims he's designed the
buildfarm test sequence to prevent that sort of problem (by deleting the
previous installation before doing "make check") but I think he musta
missed something.

regards, tom lane

Tom Lane said:

Peter Eisentraut <peter_e@gmx.net> writes:

Darcy Buskermolen wrote:

It looks like --enable-cassert isn't handled properly under icc7

http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=herring&amp;dt=2004-12-07%2016:30:44&gt;

That is quite a superficial display of the issue. If you want to get
to the bottom of this, you need to, uh, dig deeper.

This looks to me like a standard incompatible-version-of-shared-library
issue, specifically, the .so was built with --enable-cassert but the
backend trying to load it was not. Andrew claims he's designed the
buildfarm test sequence to prevent that sort of problem (by deleting
the previous installation before doing "make check") but I think he
musta missed something.

*smile*

I've been fairly careful, even paranoid, about avoiding conflicts.

The perl code that runs before we even try to check out the code, much less
build or install anything, is this:

die "$buildroot/$branch has $pgsql or inst directories!"
if (-d $pgsql || -d "inst");

inst is the install target.

Far more likely is that we are getting a conflict with a *NON* buildfarm
install.

Maybe we need to look at some rpath settings?

cheers

andrew

"Andrew Dunstan" <andrew@dunslane.net> writes:

Darcy Buskermolen wrote:

It looks like --enable-cassert isn't handled properly under icc7
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=herring&amp;dt=2004-12-07%2016:30:44

Maybe we need to look at some rpath settings?

Or PATH. If I'm reading the direction of conflict correctly, the
out-of-date component is the postgres executable, not the .so file.

Why does the page appear to show /buildfarm/bin at the end of PATH?
Shouldn't it be at the beginning?

regards, tom lane

Tom Lane said:

"Andrew Dunstan" <andrew@dunslane.net> writes:

Darcy Buskermolen wrote:

It looks like --enable-cassert isn't handled properly under icc7

http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=herring&amp;dt=2004-12-07%2016:30:44&gt;

Maybe we need to look at some rpath settings?

Or PATH. If I'm reading the direction of conflict correctly, the
out-of-date component is the postgres executable, not the .so file.

Why does the page appear to show /buildfarm/bin at the end of PATH?
Shouldn't it be at the beginning?

I don't see why it's there at all - buildfarm didn't put it there unless
Darcy added something to the config file. The canonical member of buildfarm
is dog, which is an FC1 box run by me, and which runs with the path cron
gives it, namely /usr/bin:/bin - see
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=dog&amp;dt=2004-12-12%2019:06:01
In any case, I doubt it has anything but the script and config file. It
can't be the build installdir, because that always includes the cvs branch
name (e.g. HEAD).

cheers

andrew